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:
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.
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.
Please let me know if there is any easy fix by using MapTools.ScaleLine?
We’ve improved MapTool.ScaleLine in the latest beta123. Here’s what’s new:
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.
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.
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.
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.
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.
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?
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:
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?
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:
Remove bin and obj folders, build and run again.
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.
