After my initial report on the SotM conference in Milano there are a few things i would like to discuss in more depth. The first one is the vector tiles on osm.org topic.
A bit of background first: The term vector tiles has in the OSM community kind of been a white elephant for the past couple of years. I think over the years vector tiles have been proposed as the magic solution for just about every problem in community map production that exists.
When used with actual meaning and sense and not just as an empty buzzword the term is used for two fairly different things:
- for the idea of caching the results of queries in a tiled map rendering framework. In a classical rendering system like OSM-Carto the map tiles are generated based on a number of queries of the data from a spatial database (usually postgis) for the area of the tile rendered. The results of these queries are thrown away right after the tile has been rendered. By caching the query result you can much more efficiently render different styling and tile variants – like different labeling languages, different color schemes or different resolution tiles.
- for the idea of tiled rendering of the map on the client (web browser) instead of the server based on tiled vector data. This has similar advantages as in the first concept but in particular it allows the map provider to outsource rendering and supplying the computational capacity for it to the map user.
As you can probably imagine there are technological similarities between implementations of these two approaches so use of the same term for both of them is not without basis. But it is always important when you talk about vector tiles to make clear which of these two ideas you are talking about.
The first approach described above is fairly non-problematic. It is widely used in maps produced today without this necessarily being visible for the user. Of the maps available on openstreetmap.org several are using these methods and there also exists a port of OSM-Carto that uses server side vector tiles. The second approach however is more tricky because for this to work without serious performance issues the vector tiles transferred to the client must not be much larger than raster tiles. And this is extremely hard and practically it is almost never achieved. For one specific rendering task, the plain color rendering of polygons, i discussed this in more depth some time ago. What map producers currently do to work around this problem is using massive lossy vector data compression. And compared to lossy raster image compression where decades of research went into the methods used and we have have specialized methods for all kinds of specific applications (like raw photo compression) these methods are relatively crude. You can see that in most maps based on client side rendering where the appearance of the map is usually primarily defined by the data volume reduction needs and not by cartographic requirements and considerations and a significant part of the information communicated to the user by the map is compression artefacts rather than geographic information.
So much for general background. What i now want to discuss and comment on a bit here is the proposal from Richard Fairhurst to initiate a project to provide vector tiles for client side rendering (the second approach above) on OSMF infrastructure. There are a few blog posts and messages related to that and there was a breakout session at the SotM conference about the topic.
In general and as i said before i support the initiative to increase the diversity in community created maps available to OpenStreetMap users. But due to the white elephant nature of the topic there is a lot of blind enthusiasm surrounding this that can easily lead to ignoring important things. I want to point out a few of them here – some of them i have already mentioned at the SotM meeting, others are new here.
1) It is currently fundamentally impossible to fulfill all of the functions of the current standard map style with a framework based on vector tiles for client side rendering. This might not seem overly relevant because OSM-Carto at the moment unfortunately all too frequently ignores the requirements of these functions as well (see here) but the fundamental difference is that with OSM-Carto this is a (bad) choice that can easily be changed, with vector tiles for client side rendering this would be much harder.
Most at the meeting at SotM were aware of this limitation but i fear that quite a few people ultimately have a strong desire to push this approach at all costs and just agree to this in an attempt to pacify potential opposition while still believing the white elephant to be the solution to any and all problems. So i will repeat in all clarity here: The client side rendered vector tiles approach is currently fundamentally incapable of generating maps that fulfill all of the core functions of the OSM standard style and there are no technological innovations visible at the horizon that are likely to change that.
2) It would be important IMO to consider and discuss the question if the OSMF should actually become active in this field at all. If you look at the OSMF mission you can see that providing maps for all kinds of purposes is not part of that mission. The fact that the current standard map style fulfills important functions for the OSM community and for the public image of OpenStreetMap, is generally accepted (although you can of course argue how well it actually fulfills these functions). So i think a new, additional map rendering project would – to justify receiving significant support from the OSMF in the form of computer infrastructure – have to state what important functions it aims to fulfill and demonstrate that it is capable to do so within the spirit of the OSMF mission.
There seems to me a significant likelihood that such a project from a user perspective could end up being more or less a knock-off of the OpenMapTiles project or similar and in that case it would IMO be fair to ask if this would warrant the OSMF investing resources in such a project.
3) Paul Norman in the discussion mentioned an important point: The number of developers in the OSM community capable and interested in productively working on map rendering and map design projects in general is fairly limited. This means people will ultimately vote with their feet. This is similar to what i wrote about OSM-Carto last year: The question that will most likely decide on the success of such a community project (no matter if run on OSMF infrastructure or not) is if it can successfully attract competent and committed developers capable of actually achieving whatever goals the project started with.
Not that it matters that much (since i am not very qualified to help kicking off such a project anyway) but i have at the moment rather limited interest in this project myself because my interest in community maps is primarily in those areas for which as said the client side rendering approach is currently unsuitable for. But this is not set in stone and it is quite possible that there are aspects of such a map project that could turn out to be interesting for me as well.
So far for the specific plans for an additional map rendering project on osm.org which as said as an increase in diversity in community maps i would support. But i also want to put a bit of a different perspective on the topic of the future of OSM community maps in general:
Richard’s blog post starts with an accurate analysis of what makes OpenStreetMap different from the big corporate players. The visualization or map rendering part of OpenStreetMap – the standard style – has historically been an important part of OSM becoming a very distinct player in the field. OpenStreetMap would probably not have developed into what it is today if its main visualization platform would have aimed to be a Google Maps lookalike. Instead the standard style as i pointed out before has been pushing the boundaries of what is possible technologically and cartographically in quite a lot of things for a large part of its history and in many aspect in a very different direction than where Google and other commercial map providers are going. And it seems to me that this has a significant part in OSM being able to concentrate on its core values and not following short term trends that seem to promise a quick way to success. That this has diminished more recently in OSM-Carto development is something most people more intensively involved with OSM feel and which certainly is a huge part of what motivates people now betting on and pushing for the white elephant so to speak.
But trying to address this problem now by crawling under the wings of Mapbox or other big corporations and making OSMs public image fully dependent on technology developed and controlled by corporate players would in my opinion be a big mistake. Open Source or not – the past experience with Mapnik and Carto has quite well demonstrated i think that OSM currently lacks the resources and expertise to develop or to organize development of a map rendering framework for the specific needs of the project independent of either the big corporate OSM users or the broader FOSS community. OSM will either need to invest into improving capabilities in this field within the project (which is not that feasible because OSM as a project does not have the level of organization or resources for that) or it would need to reach out more to the FOSS community to foster independent development of map rendering tools for OSMs current and future technological and cartographic needs. Projects in that field already exist (like Mapserver for example) but they are currently mostly developed for smaller commercial users and public institutions. Getting these projects to include OpenStreetMap community maps as an important use case or initiating new projects for OSMs needs together with the independent FOSS development community would be a practical approach that could ensure an independent future for OSM in terms of community maps.
And yes, vector tiles (in the generic sense described above, less in the sense of a specific file format the specifications of which are under control of Mapbox) could likely be a part of such developments. But they are not the white elephant many hope for.