ThinkGeo.com    |     Documentation    |     Premium Support

ScaleLineAdornmentLayer Distance values are inconsistence in each levels In WPF

#1

Hi,
Initially I have implemented the Map Scale Tool for distance measuring in my sample application using MapView Interactive Overlay. But while checking with the distance in different zoom levels extent I observed that the distance is displaying in Units of either Kms/Mi or Meters/Feet’s.

  1. Conversion of km to miles is not correct on the ScaleLine map tool.
  2. When we try to move the map either left to right or Top to bottom then also distance values are changing. The Expected should not change the values.
  3. Sometimes when the zoom level move to Level 1 stage at that time Map scale is not able to visible and when we try to change the zoom level as Level 2 then its displaying the Map Scale.
    Below is the following sample code for Map Scale. Please have a look at it.
    _scaleLine = new ScaleLineAdornmentLayer ()
    {
    Name = @“scale”,
    UnitSystem = ScaleLineUnitSystem.ImperialAndMetric,
    Location = AdornmentLocation.LowerRight,
    Projection = new Projection(Projection.GetSphericalMercatorProjString()),
    XOffsetInPixel = -50f, // Adjust horizontal offset
    YOffsetInPixel = -10f, // Adjust vertical offset
    };
    // _mapView is nothing but the in Xaml ThinkGeo.UI.WPF MapView Name
    _mapView.AdornmentOverlay.Layers.Add(_scaleLine);

As per the above code I am facing the wrong Map Scale distance value in the Map.
Zoom Level - 1 it is showing 20kms/20 Mi
Zoom Level: 3 it is showing 500kms/500 Mi
Zoom Level: 4 it is showing 200kms/200 Mi

Miles distance also is not the approximate values

Thanks,
Sana Venkatesh

#2

Hi Sana,

Thanks for your post and I’ll be happy to assist. I’ve used your code from #3 and done some tests. I haven’t found a bug yet, but I think I can explain some of your concerns.

Can you give me more details here? When I ran a sample with your ScaleLineAdornmentLayer configuration, I always saw the ‘km’ value was always ~0.6 as long as the miles value. This is what I expect. Are you seeing something different?

When you’re panning around a projected map, the scale bar is expected to change(in some scenarios) even when the zoomlevel does not. In spherical mercator, you will notice this change when panning north/south and not east/west. In order to project a globe onto a flat 2d map, the projection must be stretched. This is why Greenland is much larger on a flat map than on a globe. And as a result, as you pan north, the scale bar will need to adjust accordingly. You can use more accurate projections for polar regions or state plane projections, but on a general projection like spherical mercator, there will always be some change in the distances when panning north/south.

I have been unable to recreate this in my sample. Can you put together a stripped down sample .sln that shows the error occurring and post it here (or email it to support@thinkgeo.com if you do not want it public)? Once we are able to recreate the bug, we can put together a fix.

Thanks,
John

#3

If possible can you please share a sample WPF application with the ScaleLineAdornmentLayer. That could be so helpful for us for the better understanding.

Thanks.

#4

Hi,

I have created a sample application and uploading please have a look at it.

Xaml Code:


<uc1:MapView x:Name="_mapView"
Margin=“5” >
</uc1:MapView>

C# Code:

using System.Windows;
using ThinkGeo.Core;

namespace Sample
{
///


/// Interaction logic for MainWindow.xaml
///
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();

        ScaleLineAdornmentLayer _scaleLine = new ScaleLineAdornmentLayer()
        {
            Name = @"scale",
            UnitSystem = ScaleLineUnitSystem.ImperialAndMetric,
            Location = AdornmentLocation.LowerRight,
            Projection = new Projection(Projection.GetSphericalMercatorProjString()),
            XOffsetInPixel = -50f, // Adjust horizontal offset
            YOffsetInPixel = -10f, // Adjust vertical offset
        };
        _scaleLine.TextStyle.Font.Size = 12f; //Adjust the text Font Size.
        _scaleLine.TextStyle.Font.FontName = "Courier New";
        _scaleLine.TextStyle.TextBrush = new GeoSolidBrush(GeoColors.DarkSlateGray);
        _scaleLine.TextStyle.Font.IsBold = true;
        _scaleLine.TextStyle.TextPlacement = TextPlacement.Right;
        // _mapView is nothing but the in Xaml ThinkGeo.UI.WPF MapView Name
        _mapView.AdornmentOverlay.Layers.Add(_scaleLine);
    }
}

}

#5

Hi @SVenkatesh,

Below is a zip for a very simple WPF app that shows a scale line adornment using your code above:

Can you run this and tell me what issues you’re seeing? Or does this sample work and your app is having issues?

I just want to get a better idea on what issue you see and whether it’s just in your app or if it’s a general issue in the ScaleLineAdornmentLayer.

Thanks,
John

#6

Hi John,

Thanks for your Sample Application. Here is my sample application uploaded in drive file link. Please have a look at it.

When the application starts initially the window size will be in Minimized. Check out all the Zoom Levels for Level-1 to Last Level extent. Now repeat the same steps before that maximize the application window and try it in each and every zoom level extent then we can see that Inconsistence values for Minimize and Maximize screens. Some times both the Kms and Mi values are getting same. But not repeating in all the time.

Thanks,
Sana Venkatesh

#7

Hi @SVenkatesh,

Thanks for the sample. I do see some inconsistencies now when I’m at the lower zoomlevels. I’ve found in my testing that if the following line is removed, the issues go away:

Projection = new Projection(Projection.GetSphericalMercatorProjString()),

This may work for you as a temporary workaround while I try to dig further into the issues and get back to you.

Thanks,
John

#8

Hi @ThinkGeo_Products

Any Clue with the above issue ?

#9

Hi @SVenkatesh,

How are your results after you remove the Projection line listed above? I have a ticket into our product development team to look into this issue, but work has not started on it yet. I believe a good temporary workaround is to just remove the projection line. Please let me know if this helps or not.

Thanks,
John