ThinkGeo.com    |     Documentation    |     Premium Support

ScaleLineMapTool bug when working with OpenStreetMap

Hi

I have realized that the scale line does not display the correct values when I add the OSM background map. I have some data in the British National Grid projection, and when I overlay the OSM map, I notice a significant mismatch in the scale values—about a 40% difference compared to the measurements on the OSM website.

The image from our application with the same view as OSM:

The screenshot from the OSM website:

I understand that using the OSM with the EPSG:3857 projection in the ScaleLine comes with a 1.6 error when compared to BNG. It would be beneficial to provide an option to use WGS84 with latitude and longitude for a more accurate scale line.

Best regards
Mahdi

Hi Mahdi,

Just do

scaleLineAdornmentLayer.Projection = new Projection(3857);

It will internally create a ProjectionConverter reprojecting to WGS84 when calculating the ScaleLine.

I didn’t see any sample using it in the HowDoI, let me make sure to create a sample in the next release.

Thanks,
Ben

Hi Ben

We are using the main map Scale line, this is the way we enable the ScaleLine:

MapTools.ScaleLine.IsEnabled = true;

I believe there is an alternative method to create a Scale line.
I tried using ScaleLineAdormentLayer, but there are some problems which I keen to use the MapTools.ScleLine:

This is the image I obtained when using the ScaleLineAdornmentLayer, and the text is touching the borders.image

Please let me know if there is any easy fix by using MapTools.ScaleLine?

Best wishes
Mahdi

Hi Mahdi,

We’ve improved MapTool.ScaleLine in the latest beta123. Here’s what’s new:

  1. The tool now takes the center point of the current screen and, along with the current projection, calculates the distance using the Haversine formula for greater precision. The Haversine formula computes the great-circle distance between two points on the surface of a sphere, which better accounts for the Earth’s curvature than a simple flat-Earth approximation. This results in more accurate distance measurements, especially over longer distances.

  2. By default, if the MapUnit is DecimalDegrees, it uses EPSG:4326; otherwise, it uses EPSG:3857. We’ve also added a MapTool.Projection property so you can set a specific projection if needed for even more accurate results tailored to your data.

  3. Please note that with EPSG:3857, if you pan from the equator toward the poles, the scale line will change. This behavior is expected because the spherical Mercator projection stretches the map near the poles.

This update is currently available only in beta. Please try it out and let us know if it works for you. I bet it’s something you want to have in the hotfix release as well, right? We’ve hold off the current v14.2.6 and if this fix works fine for you, we’ll see how much work it would be to add it to the hotfix as well.

Best regards,
Ben

Hi Ben

Thank you for clarifying this issue and proposing a solution. Could you please include this in the next hotfix release, if possible?

Best wishes
Mahdi

Hi Mahdi,

Did you have a chance to try this feature (in beta version) in your project? Just want to make sure this fix works for you.

Also besides this issue and LegendAdornmentLayer Bug - ThinkGeo UI for Desktop - ThinkGeo Discussion Forums, any other bugs you want to include in the hotfix?

Thanks,
Ben

Hi Ben

I think that is because I don’t think we had these issues in the stable release:
ScaleLinePrinterLayer Issue - ThinkGeo UI for Desktop - ThinkGeo Discussion Forums
Tile border in area base layer - ThinkGeo UI for Desktop - ThinkGeo Discussion Forums

To be honest, when I updated to the stable release, the only issues I encountered were related to the printer layer. However, I am grateful to receive the pre-stable release of this hotfix, and I will provide you with feedback as soon as possible.

Best regards
Mahdi

Hi Mahdi,

We don’t have a pre-stable hotfix release, all the changes go to the beta branch first and we cherry pick some of them into hotfix. That’s why I’m wondering can you try the latest beta and ensure the ScaleLine fix works for you?

In fact, the beta branch is more stable now and getting closer to the release. That would be wonderful if you can try the latest beta and let us know the issues you see. We will try to launch the next major release v14.3 asap.

Thanks,
Ben

Hi Ben

Immediately after I updated the package to the latest beta version, I encountered this issue:

   at ThinkGeo.UI.Wpf.MapViewBase.ToWorldCoordinate(Double screenX, Double screenY)
   at ThinkGeo.UI.Wpf.MapViewBase.JUQ=(Object sender, SizeChangedEventArgs e)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.FrameworkElement.OnRenderSizeChanged(SizeChangedInfo sizeInfo)
   at System.Windows.ContextLayoutManager.fireSizeChangedEvents()
   at System.Windows.ContextLayoutManager.UpdateLayout()
   at System.Windows.Interop.HwndSource.Process_WM_SIZE(UIElement rootUIElement, IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Interop.HwndSource.LayoutFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

I believe it’s best to obtain the hotfix for the last version of ThinkGeo.UI.Wpf before the significant changes are implemented. While I’m confident that these updates will improve the ThinkGeo library, we need to release our application very soon. Unfortunately, we don’t have the time to address these issues.

Could you please let me know when the hotfix will be released?

Best regards
Mahdi

Hi Ben

I attempted to resolve the CurrentScale issue by avoiding the setting of an invalid scale, but now I’ve encountered another problem.

thinkgeo-issue

Best wishes
Mahdi

Hi Mahdi,

I don’t know why ToWorldCoordinate(Double screenX, Double screenY) throws exception for you, must be some corner cases we were missing. Anyway, let us create a hotfix for you with the following fixes:

LegendAdornmentLayer Bug - ThinkGeo UI for Desktop - ThinkGeo Discussion Forums
ScaleLinePrinterLayer Issue - ThinkGeo UI for Desktop - ThinkGeo Discussion Forums
The ScaleLine Improvement in this post.

Also, about the last issue you posted here (the semi blue polygon becomes concrete after panning), I’m pretty sure this issue was fixed. Which version you are using right now seeing this issue?

Thanks,
Ben

Hi Ben

Here is the list of package I installed yesterday:

  <package id="ThinkGeo.Core" version="14.3.0-beta127" targetFramework="net472" />
  <package id="ThinkGeo.Dependency.MicrosoftVisualCRunTime140" version="14.0.0" targetFramework="net472" />
  <package id="ThinkGeo.Gdal" version="14.3.0-beta127" targetFramework="net472" />
  <package id="ThinkGeo.Gdal.Dependency.Windows" version="14.0.1" targetFramework="net472" />
  <package id="ThinkGeo.Printers" version="14.3.0-beta127" targetFramework="net472" />
  <package id="ThinkGeo.SqlServer" version="14.3.0-beta127" targetFramework="net472" />
  <package id="ThinkGeo.UI.Wpf" version="14.3.0-beta128" targetFramework="net472" />

Best wishes
Mahdi

Hi Mahdi,

I’ve no idea why you’re seeing that error (the semi blue polygon becomes concrete after panning). We haven’t been able to reproduce it, and the source code looks correct. A couple of sanity checks:

  1. Remove bin and obj folders, build and run again.
  2. Double click the exe in the bin folder see if you can recreate it, check the version number of ThinkGeo.UI.Wpf.dll and confirm it’s the one we expect.

Regarding CurrentScale issue, you mentioned “avoiding the setting of an invalid scale”—were you setting an invalid scale in the code? Could you share a code snippet?

On another note, in beta129 we added a default MapScale, so there will not have any “MapScale not set” exception. Please pull the latest beta and give it another try.

Let me know how it goes!

Thanks,
Ben