I love vector-tiles. They enable features on your device (in the client / web-frontend) like infinite map styles or seamless zooming. After download you can work offline and even do rooting or search.
I hope, OSM will change its main webpage to a vector-tile web-client soon. Vector-tiles probably will reduce the server load, compared to bitmap-tiles. A public server for tiles is needed. Could this tiles als be used for other map render applications?
Today, apps like OrganicMaps or Pocket-Earth run their proprietary tiles. This tiles are not divided in squares but large or small geographic regions, for far and less zoom levels. This is useful for downloading offline tiles.
I don’t like large and slow region tiles. Small tiles are downloaded fast and cause almost no delay. For offline, small regions could be served in a tree of groups to load even whole countries.
But this concept I quite different from the zoom-level tradition of OSM. An app wouldn’t be much different, wether the tiles are squares or regions. Do we need zoom level? Sure, but not all the Z0 to Z20, as we use for bitmaps now. Two or even four levels could be merged: A world tile, large and smaller regions, local regions and cities. Or just squares Z0 Z4 Z8 Z12 Z16. Or both to make everyone happy?
? Do you agree with this ?: The vector-tiles should NOT define, what and how things are rendered!
Not only the map style is off the tiles, even wether something is rendered at what zoom or not at all defines the app, the map-style or even the user. Sure, one has to define, what is included in what “tile-zoom-level”. Well, if some detail is needed in a raw zoom-level already, additional detailed tiles need to be loaded. Different levels needs to have the same objects in detailed or raw solution; like rivers, borders or motorways and city regions. The app decides when to fade between this levels.
What is contained in a vector-tile? One could just put OSM tagging in it. But do we agree, a check of tags is done and tags get transformed to a GIS like format. I assume the actual tile generators and Overture do this. For the large area tiles, it seems obvious, what data is needed. Not for the detailed tiles. If we include really anything, the tiles will be huge. Most users/apps will only need “the usual” objects. Time will tell, what that means; we have to be flexible and adapt to the needs.
Anyway, really all OSM tagging should be accessible! My idea is, to have always two tiles side by side: the “Usual" and the “Other", containing anything, not being in the “Usual". Invisible objects like nature reserve are candidates for “Other", bus stops certainly not, but bus-routes, I think.
To get all the mad OSM tagging in a GIS scheme, will be a change. As a fallback, any renderer could request the basic OSM-API or Overpass to get really all OSM tagging. This will also helpIf an application also offers editing, it could upload tags, then download them and use them to show a really actual map. Because the vector tiles may get refreshed in minutes in best case, but way slower most possibly. As with bitmap tiles, OSM may offer to request a refresh by API.
Reading this, you may have only 2D maps in mind. But all above is meant for 3D too. Aseptically the “All” tiles are meant to contain 3D tagging exclusively. Mostly in the detailed levels; but large buildings like towers or castles will also be in a tile “up”, to get visible from the distance, with a less detailed Level of Details of course.
Let’ consider the existing popular 3D renderers, I know:
We don’t know the details of F4Map.com . It seems to need no “zoom levels”. The conversion of the OSM/GIS objects into 3D objects is done at the server. The well known GLB-format is used as “3D-Tiles”. This squares are downloaded by the web-client. And F3Map adds its own complex building models as GLB. We already have “3dmr.eu” as a developable solution for this.
The new “streets.gl” is quite like F4. It can use Overpass direct in the web-client and offers cached tiles on its own server. Its vector-tiles are squares, they are proprietary because some extra preparations for 3D are added. This could be included in the “All” tiles too, so all 3D-renderer could use them. Street GL converts into 3D objects in the web-client. Even map-styles are possible this way.
OSM2World.org uses the World file and runs a server for slicing the world file in temporary vector tiles and conversion into 3D proprietary 3D-tiles stored on the server. The client just decodes into the GPU.
OSMgo.org uses no server but only Overpass and does all steps, decrypted above in the web-client.
My dream is, OSM, together with existing renderer teams, defines and manages and serves global application independent vector-tiles. 2D- and 3D-renderer and even editors use them, if they like. Do we really need two sets of tiles, squares and regions, or could we agree about one? If the service is running, will teams like OrganicMaps accept them?
I just found Host vector tiles generated by tilemaker · Issue #565 · openstreetmap/operations · GitHub, about generating and serving tiles. Is there more discussion about what kind of tiles and what data are served (schema)? What about writing a frontend for the homepage and run an experiment? May be we could use MapLibre?
Were no rendering has gone before
-karlos-
