ThinkGeo.com    |     Documentation    |     Premium Support

ThinkGeo WPF v9.0 - Limit OpenStreetMapsOverlay map

Hello,

I’m currently working on a project to display an OSM overlay based on a Lat/Long and Radius (in nautical miles), I have no shape files to pull from. I was wondering if there was a way to limit the amount of tiles that the OSM overlay can display based on that radius.

Ex) I have a point of 60 lat, -150 long and a radius of 100 nm. OSM would display up to the 100 nm worth of data, and panning further would just not render further tiles.

I have something that sort of works by setting the RestrictExtent, but this does not allow panning when the user zooms in. Would I need to recalculate the RestrictExtent property to allow panning up to the initial map size?

I’m still learning how much of the ThinkGeo methods and functions work so thank you for your help.

Matt

Hi Matt,

I think your 100nm is the screen distance? In fact the RestrictExtent works for world coordiantes, so when you zoom in the works area should get increased, and I think you should can pan the map in target extent.

If you don’t want to allow user pan out of your setting extent, I think you can also handle the event for example CurrentExtentChanging etc.

I don’t think I understand your question: “Would I need to recalculate the RestrictExtent property to allow panning up to the initial map size?”

I think you can set correct CurrentExtent to make map render specified area when it initialization.
You can also don’t set RestrictExtent at first, when you need to use it, you can set it and just refresh the map.

Wish that’s helpful.

Regards,

Ethan

Hi Ethan,

Thank you for the information. I’ve taken over this project from another contractor so I’m still trying to understand how all of the ThinkGeo is utilized. From what I’m understanding, the 100nm is set to be the initial zoom level of the map.

May I ask why you wouldn’t want to set the RestrictExtent at initial creation?

Setting the RestrictExtent in my case, does allow the initial search radius of the map to be displayed, which is desired functionality, however when I zoom into the map it does not let a me navigate the map, even though my debugger indicates that I am dragging the map.

For my question “Would I need to recalculate the RestrictExtent property”, I was assuming since we zoom in that the extent would increase and thus a new Restriction would need to be set to allow the panning at the desired zoom level.

If I instead go the route of handling the event with a CurrentExtentChanging, how do I go about determining if we’re trying to go beyond the currentExtent of the map? I’m assuming i’d somehow have to compare the rectangleShapes or PointShapes?

Thank you very much for the help,
Matt

Hi Matt,

I think I still don’t understand your scenario clearly, and my last reply looks not so exactly.

So let us double check some points:

  1. By default your map will zoom into a specified scale(100 Nautical Mile / 1 ??(map unit)), and you limit user to pan out of specified area(implemented by the RestrictExtent now)
  2. When you zoom in to other scale(deeper zoom level), you want to pan the map out of limitation area? If so I think maybe I misunderstand your requirement, do you means you want to show an area(For example a circle) around your center point(Or a point for ship), and this circle area will move follow your pan(or ship move or mouse move, I guess maybe you want to render a map looks like a radar screen)? If I still misunderstand your scenario here please let me know. Because the RestrictExtent will limitation user pan out of specified area in each zoomlevel, zoom out or zoom in will get the same result.
  3. You never can beyond current extent, I means the current extent is the map area you viewed in map, it will be changed when you pan or zoom. I mentioned the CurrentExtentChanging when I hadn’t understand your requirement correct, so maybe you can just ignore it now, if it’s really useful for your scenario we can discuss about it.

Regards,

Ethan

Hi Ethan,

  1. I am currently limiting my users to pan out of the specified area with RestrictExtent. For some more info regarding scale, if needed, it seems that we are using a custom zoom level set with an initial scale of 14427644 and seem to have 53 custom zoom levels. So I pass the 100 nm as a zoomlevel to the thinkgeo map’s customZoomLevels and it returns a scale which is then used by the ZoomTo or ZoomToScale. If you would like, I can provide the list of zoomlevels we are using.

  2. It would in a sense be like a radar, only displaying the map contents of the initial search radius. So with 100 nm radius, I’d like to only display up to that amount of the map, and when zoomed in I could only pan up to the intital 100nm limit.

  3. Okay, I believe this ties into point 2 of mine, but if I were to create a global variable to hold the current extent, lets say “initialExtent”, of the map upon first render and then zoom in, “zoomedExtent”. Could I compare the two extents, initialExtent and zoomedExtent, to determine if I’ve reached the edge of my radius?

The reason for this is that I’m trying to limit the amount of tiles needed to try and increase performance when rendering the map. Currently it’s taking too long and is not valid for use in the field. I’m currently in talks to try to get us upgraded to version 10 of ThinkGeo and also potentially trying either Bing or Google overlays instead of OSM.

I know this is slightly off topic, but if we upgraded to version 10, would we be able to use the ThinkGeo Cloud api’s within wpf desktop applications or are those only used for web based applications?

Thank you,

Matt

Hi Matt,

Thanks for your explain.

It looks RestrictExtent is OK for your scenario. Your target is make user only can pan in map limitaion area ( It’s “initialExtent” for example the 100NM circle). The RestrictExtent limit based on world coordinates, so it means the same area for different zoomlevel, but when you zoom in, the area looks bigger in screen(in fact it’s the same area), so that’s why I don’t understand before about you mentioned “however when I zoom into the map it does not let a me navigate the map”.

If you want to increase performance, you can also try other ways, for example reduce map control size, open cache, optimize the render logic if you have other layers besides background layer. If access OSM is slow in your network, you can also try the Bing and Google.

If you upgrade to version 10, you can use the Cloud API, our cloud API can be used in all of our products, you can view more detail information in our cloud page here:
https://cloud.thinkgeo.com/
https://wiki.thinkgeo.com/wiki/#thinkgeo_cloud

Wish that’s helpful.

Regards,

Ethan

Hi Ethan,

If RestrictExtent is ok for my scenario, then how do I handle, if at all, panning once zoomed in? Since you are saying that the extent doesn’t actually change when zoomed in.

I’ll have to look and see if I can reduce the map control size in our product, and I’m already utilizing the caching feature for the tiles, as for rendering, the OSM overlay is the very first in the list of the ThinkGeo wpf map control.

Could we possibly setup a date/time for a meeting next week? I think it might be easier to explain and show what we are attempting to achieve with our product.

Thank you,
Matt

Hi Matt,

I read our discussion again and found I still missunderstand your scenario.

Here is a sample for you, it only shows the area which radius equal 100 NM around target point(-150, 60), but you still can pan to out of this area in each zoomlevel.

9588.zip (10.4 KB)

If you have further requirement about it please let us know.

Regards,

Ethan

Hi Ethan,

Thank you for providing an example. However we do not have version 10 at this time and are only using 9, specifically 9.0.0.1124 . So I could not get the example to run and I tried to use our v9 Dlls but it still failed. Is it possible to rebuild the example for v9?

Thank you,
Matt

Hi Matt,

Here is the sample for V9, wish that’s helpful.

9588_v9.zip (9.6 KB)

Regards,

Ethan

Hi Ethan,

This is exactly what I am trying to do!

Thank you so much,

Matt

Hi Matt,

I am glad to hear that’s helpful.

Regards,

Ethan