Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

callagga

macrumors member
Original poster
Mar 2, 2007
84
0
How should I manage a large number of overlays I have (e.g. ~8000 across the country) noting there will be only a small number in a given view typically as the users typically zoom in a bit. Also noting I want to have direction arrows out from the current user location to the currently "visible" overlays (i.e. on the screen) at a given time? There are Overlays and NOT Annotations keep in mind. Specifically:

Q1 - Should I load up all the overlays into the app upfront? Or should I be manually managing myself which ones need to be displays at the given time and load them, remove them?

If I should load them all up up front then:

Q2 - Does MKMapView actually intelligently render them when visible only? It doesn't seem like this???

Q3 - How do I get a list of currently "visible" overlays from my MapView to create the direction pointers from the current user location? I can't see any function in Mapview to allow this? So does this imply I would need to manually check through all overlays (i.e. whole 8000) continually to see which ones are visible manually?

thanks
 
You should use a quad tree to organize this location data. When a user is zoomed out you only display a subset.

https://robots.thoughtbot.com/how-to-handle-large-amounts-of-data-on-maps

Using the word "MKMapView" and "intelligent" in the same sentence is not advisable.

The MKMapView class provides a bounding rect for the currently visible area of the map. Using a quadtree you can efficiently figure out which overlays are being shown.
 
Are you using this to provide an offline mapping view?
hadn't thought about this - just the default behaviour I think (i.e. no option to pre-load maps)
[doublepost=1464211562][/doublepost]
You should use a quad tree to organize this location data.
Thanks for the pointer, I hadn't come across this before.

Question - I'll read up, but will the concept be still is you'd load all overlays up at startup? (i.e. leave MapKit work out when to render the visible items, however because MapKit doesn't provide you access to which these are, use quad tree to find out?)
 
Update - actually I don't "quad tree" will help for overlays. Overlays have basically all points around the path and all the points inside the path. For example if you are zoomed into the middle area of an overlay you might not see the edges, however you are still within the overlay so it's shading would still need to apply....make sense?
 
Update - actually I don't "quad tree" will help for overlays. Overlays have basically all points around the path and all the points inside the path. For example if you are zoomed into the middle area of an overlay you might not see the edges, however you are still within the overlay so it's shading would still need to apply....make sense?
No, don't understand what you're saying.

A quad tree is useful for many things, it is excellent for storing location data since it is significantly faster to search a quad tree than most other data structures when dealing with vectors like a GPS coordinate.

It's also useful because you can very rapidly determine how many stored coordinates exist inside of a given area. Given this ability, you can make it so that if a user zooms all the way in you will show every overlay, but as they start zooming out and clustered overlays start overlapping, you can efficiently only display a few of them instead of sluggishly showing all of them.
 
So I guess I mean with the quad tree example you add a point, however in the case of an overlay it might really be 100 points as part of the path. So I guess you're saying add the 100 points of the path to the quad tree, but probably in the structure keep a link for these points back to the parent overlay... Then if your search picks up a bunch of points you'd then get a unique list of the overlays associated with those points?
 
So I guess I mean with the quad tree example you add a point, however in the case of an overlay it might really be 100 points as part of the path. So I guess you're saying add the 100 points of the path to the quad tree, but probably in the structure keep a link for these points back to the parent overlay... Then if your search picks up a bunch of points you'd then get a unique list of the overlays associated with those points?
No. Your overlays are coming FROM the quad tree. Basically, when the user changes their zoom level, or starts panning around the map, you ask the quad tree "what overlays should I show in this region?". You can instill a "maximum", ie. If the quad tree returns 20 overlays, you can only show the most popular 10 overlays.

My only point here is this: trying to store a large number of GPS coordinates in other ways will be excruciatingly slow. Use a quadtree and save yourself a headache.
 
When loading each overlay, you should be able to get bounding coordinates of everything it shows, to be able to quickly determine if that overlay should be added for the current zoom / center of the map.
 
When loading each overlay, you should be able to get bounding coordinates of everything it shows, to be able to quickly determine if that overlay should be added for the current zoom / center of the map.
Thanks - the question here for me is what is then the best approach for rechecking through all overlays to see if the map (which is moving due to user moving) needs to have overlays added (as you move into a new area) or removed. In fact questions here would be:

Q1 - How often to check - every GPS update? Or if not how to decide how ofter to check and trigger this?

Q2 - How to do this without impacting the UI? Would the concept just be to trigger this check off the main thread, but then if there were any changes (e.g. add another overlay) then these UI calls have to be made back on the main thread?
 
Just adopt the MKMapViewDelegate protocol, and comform to the functions that are called for updating the map and user location, and the redo your overlays there.
 
Last edited:
  • Like
Reactions: callagga
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.