Scaling with MapPrinterLayer

[Steven1]

Hi guys,

This is a two part question:
I create a print preview map using PrinterInteractiveOverlay with MapPrinterLayer, then add ScaleBarPrinterLayer and ScaleTextPrinterLayer. The resize mode of the map is Resizeable.

1. If I select the MapPrinterLayer and resize vertically the scale change is not indicated by the ScaleTextPrinterLayer or the ScaleBarPrinterLayer, even though the scale is changing. However, if I resize the map horizontally, the scale change is reflected in both the ScaleTextPrinterLayer and the ScaleBarPrinterLayer. Should it not work both ways?
2. Before ThinkGeo made a ScaleTextPrinterLayer available, I created my own. But when I compare the ThinkGeo ScaleTextPrinterLayer with my custom ScaleTextPrinterLayer it appears that the ThinkGeo version is slightly inaccurate. Am I correct?

I have attached a sample project that demonstrates this behavior. In the sample, the ThinkGeo ScaleTextPrinter layer appears in the upper left of the map and the one I wrote is in the upper right. When you click the button it will set the scale to 1 inch = 1320 feet (1:15840). The ThinkGeo ScaleText reads 1 inch = 1,138 feet and mine says 1 in = 1,320 ft.

Thanks very much!

Steve

ScaleBarTest.zip (1.0 MB)

[Frank4]

Thanks Steven,
The Scalebar value is calculated by the width of the map. You can set
moPageLayoutMap.ResizeMode = PrinterResizeMode.MaintainAspectRatio
to keep AspectRatio during the resize procss.

For the #2 issue. We can re-produce this one. We are looking into more details. We will let you know once we get any progress.

Thanks

Frank

[Steven1]

Frank,

Thanks very much for your reply!

There are many times when we cannot use PrinterResizeMode.MaintainAspectRatio. We need to be able to correct the scale when the MapPrinterLayer is resized in only the vertical direction. Is there a way to do this? I cannot see a way to detect when that happens in code.

Thanks!

Steve

[Frank4]

Thanks Steven,
A quick update. For the #1. The scale is based on the X direction. So we won’t be able to see the changes if resized in only the vertical direction. For the #2. We found the one in the ScaleTextPrinterLayer is correct. The one in the ExtentHelper is not correct. it will get the correct value at equatorial. That mean the one in ExtentHelper didn’t consider the latitude. We are trying to add a overload method for the ExtentHelper. We will let you know once we get it ready.

Thanks

Frank

[Steven1]

Frank,

Thanks for the reply.

For the #2 issue I am confused. The square shape in my example is exactly one mile (5280) feet on each side. After setting the scale at 1320 feet/inch if I print the map and then measure, the shape is just about exactly 4 inches on a side, which is correct. But the ScaleTextPrinterlayer reads 1138 feet/inch, which appears to be incorrect. If it was correct, each side would measure about 4.6 inches.

Thanks!

Steve

[Frank4]

Thanks Steven,
A quick update. We are still reviewing the code. We will update you once we get any progress.

Thanks

Frank

[Frank4]

Thanks Steven,
We did some test too. look like you are correct. The one in ExtentHelper is correct. And a lot of places use this one in the mapsuite. So we adjusted the one in the ScaleTextPrinterLayer. We have the changes checked in. Could you try with the latest mapsuite 10 beta Nugget package.

Thanks

Frank

[Steven1]

Hi Frank,

I tested with the beta package and now the ScaleTextPrinterLayer works well. However, the ScaleBarPrinterLayer and ScaleLinePrinterLayer do not appear to be working correctly.

Thanks!

Steve

[Frank4]

Thanks Steven,
A quick update. We have make the changes. But still need some test and verification. We will update you once we have the changes ready for the Nugget beta release.

Thanks

Frank

[Frank4]

Thanks Steven,
We have pushed the changes. The daily build process will upload the package to Nugget. Could you please try with the latest V11 beta release tomorrow.

Thanks

Frank

[Steven1]

Frank,

Thanks for all the work on this. I tested with the latest Beta (11.0.0-beta045) and the ScaleTextPrinter layer is working fine. Also the ScaleLinePrinterLayer appears to be working well. However, the ScaleBarPrinter layer is still incorrect. In my sample project the total length of the ScaleBarPrinterLayer represents 1/2 mile, so it should measure 2 inches on the page (for 1 inch = 1320 feet), but its actual length is 2 3/16 inches.

Thanks!

Steve

[Johnny]

Steve,

I just take over this issue from Frank, and now am working on it, it’s a big change and may need some time, any updates I will paste in the thread.

Thanks,
Johnny

[Jonathan3]

Hi,

I was referred to this thread from a support ticket recently, but I am not sure it is about quite the same thing. In the ticket I mentioned (as a secondary issue) that text on the scale bar was showing as very large on prints. This is something that I thought was fixed after raising on an earlier ticket (or maybe thread in the forum).

If this thread does not cover that problem then important that I know as I will need to raise it as a separate problem.

Regards,
Jonathan

[Kyle_Day]

Hey @Jonathan3,

I referred you to this forum thread because you mentioned issues with the scale bar, which I realize that this isn’t exactly the same issue. Can you create a new thread or ticket that shows and describes the problem so that we can address it?

Thanks,
Kyle

[Jonathan3]

Hi Kyle,

OK, thanks. I will do that.

Regards,
Jonathan

[Johnny]

Hi Steve,

Sorry that it has been a bit long time on this issue, we have been working on this change for several days, but still not get it fixed. The reason why it takes so long is that we reviewed all codes of printer related stuffs, and found the algorithm of calculating the scale is incorrect. Here are the details:

1. In ThinkGeo products, it should have 2 scale systems, one is for drawing the map, it should not change for a specific zoom level, when pan the map from left to right or up to down, as we need a fixed scale to convert the world coordinates to screen coordinates, so that keep the continuity of the geometry. In another scale system, the scale value will change according to the coordinate, even for a specific zoom level. Take Mercator Map as example, see image below:
   
   

A square around the equator has the different scale when it’s near to “North pole” on Y axis. While, in existing SDK, it has following issues:

1. We take first scale system to get the scale value for printer related layers, such as MapPrinterLayer ,ScaleTextPrinterLayer and ExtentHelper.ZoomToScale. However, use second scale system in ScaleBarPrinterLayer, ScaleLinePrinterLayer. The correct should be use second scale system (changing according to the coordinate)

2. Use the center point of MapPrinterLayer to calculate the scale value, instead of using the width of the boundingbox.

3. Some issues of calculating the screen length of the ScaleBarPrinterLayer.

Since the real scale will change based on the coordinate, the printed length of each side of a square (1 mile of each side in shape file, for example) may not equal to 4 inches when the square is at the different locations on the earth. The real distance on the earth should be different as well.

Sorry for the delay, we will try getting it fixed in early of next week.

Regards,
Johnny

[Johnny]

Hi Steven,

All issues have been fixed according to the descriptions mentioned above. The scale value of the ScaleBarPrinterLayer, ScaleLinePrinterLayer, ScaleTextPrinterLayer should indicate the real-time scale of the view port, here we take the scale of view port center as the scale value of these 3 PrinterLayers, when we pan the map from top to bottom or from left to right, the scale value will be changing following the action. Here is the sample with the updated version (11.0.0-beta 151 or higher) of “ThinkGeo.MapSuite”:

If we click the button “Set Scale 1320 ft/in”, no snapping any more, it will zoom to the map at the scale you are assigning. To differ from the methods of getting snapped scale, we added another new API “GetGeodesicScale” to class “ExtentHelper”. In the demo the only change I did is changing the “GetScale” to “GetGeodesicScale”. To avoid any confuse, I attached the demo I used for test as below.

ScaleBarTest.zip (47.3 KB)

Sorry for the delay.

Regards,
Johnny

[Steven1]

Johnny,

Thanks very much! It is working fine except it is drawing features outside of the MapPrinterLayer border.

Do you know when this will be available in a production build?

Thanks!

Steve

[Johnny]

You are welcome, Steven. I have already sent the API changes (compared with last release version) to the manager, if all are verified, we will do more tests and then try releasing a production build ASAP.

Thanks,
Johnny

[Johnny]

Hi @Steven1,

ThinkGeo.MapSuite v10.6.19 is now available on NuGet. Please take a try.

Thanks,
Johnny