Cloud Native Maps
Examples Strategy Documentation Download ChangeLog
It is imperative that you understand how to define your data sets at different zoom levels. A poor data set definition will result in an interactive map that is less than useless.
FlatGeobuf is a vector data format we will abbreviate as FGB and has a file extension of .fgb. Cloud Optimized Geotiff is a raster data format abbreviated as COG and has a file extension of .tif. Your data must be in one of these 2 formats.
A very bad FGB strategy
You have an FGB file that contains 145 million building footprint features representing your entire country. This file is 36GB, it's huge. In your data set you have given this FGB file a 'minZoom' of 1 and a 'maxZoom' of 20.
You're viewing your Leaflet map centered on your country at zoom 5. Given the spatial bounds of the Leaflet map viewport, it's likely that the SDK will try to load the entire 36GB FGB. It is certain this is not what you want.
A much better FGB strategy
First, ask yourself, "Do I really need to show building footprints at zoom 5? Or zoom 10 for that matter?" You can't make out any footprint detail at those levels so why display it at all? Perhaps a 'minZoom' of 15 and 'maxZoom' of 20 might be a better solution.
At zoom 15 the SDK will load a much more reasonable amount of data, in a timely and responive manner. Also, at this zoom level you see lots of detail. Attaching mouse events to those footprints makes sense.
What if you need to see this vector data at zoom 5 or 10 for an overall view or general density?
A hybrid COG/FGB strategy
When working with large FGB data sets that need to be visualized at low zoom levels, you might create a rasterized version saved as a COG. Now, create a data set for that COG to be shown at 'minZoom' 1 and 'maxZoom' 14. The SDK will work in conjuction with your FGB data set that has 'minZoom' of 15.
High/Low Resolution FGB Strategy
Another approach for using FGB at all zoom levels might be to create 2 FGB data sets. One data set at its native high resolution and another low resolution data set created with larger geometry tolerances. Say your high resolution data set tolerance is roughly .000001 degrees, create a lower resolution data set at tolerance .001. ogr2ogr -simplify works great for this while preserving topology.
Now you can display the low resolution at say 'minZoom' 1 and 'maxZoom' 14. Your high resolution can be displayed at 'minZoom' 15 and 'maxZoom' 20. Attaching mouse events to both high/low data sets makes sense.
When using this approach a low resolution FGB file to be displayed at low zoom levels should be of a reasonable file size. 500K is a good upper value.
COG Is Forgiving
A properly created single band COG is bullet proof. 1MB or 10GB, it doesn't matter. A COG data set is going to display nicely in a timely and responsive manner. If you're developing a strategy and experimenting as you go, start with this.
A file with more than 1 band can mean serious network latency. The more data, the longer it takes to transfer. Same for pixel data type, a 64 bit data type will take longer than an 8 bit data type.
CloudNativeMaps.com © 2024 :: Contact :: Portfolio :: X/Twitter