Recently the openstreetmap landing page has been populated with two vector tile layers. These are awfully bad at providing users the informations present in the data pertaining to outdoor (a.k.a. hiking/scrambling/&c) leisurely pastimes. I see an urgent need to fill that gap – outdoor as vector. No idea how you can align that with the needs of your business though.
We are on our way to Vector Tiles now, but it is a marathon and not a sprint.
5 Likes
Topographic maps at the scales useful for outdoor maps are often suited to raster tiles. The popular UK Ordnance Survey outdoor maps are served as pre-drawn raster tiles (even if the underlying data is all vector).
I do not see that as an argument against creating “topographic maps” with vector tiles. With all the craze for vector tiles, the future will certainly belong to them. As far as I can see, most “apps on mobile” already only use vector. Some of them make great use of openstreetmap data for this special/niche interest. So why not for the desktop too?
Certainly, what I want from a topo map is a terrain model in the decimeter scale and a slope map in the (5 at least)m scale. Of course, unlike contour lines, these will never be vector data but raster data instead. From what I am aware of, the “apps on mobile” and a number of “web portals” serving such for outdoor enthusiasts know well how to combine that.
PS: Our local Ordnance Survey (they call themselves BEV) dabbled with vector but dropped that, yet I guess that was just because they either did not manage vector to give the same visually appealing look (they got really close, IMO), perhaps, because they see themselves as only providing a “basemap” to overlay special interest stuff, who knows? Just my guess. Regardless of all the crave.
I wasn’t saying that you shouldn’t create outdoor maps using vector, but I was disagreeing with this idea that they “are the future”. I often use printed outdoor maps - you don’t want all that pinching and zooming to find stuff. Here you can’t beat a carefully designed printed-therefore-rastered map.
I think we often get the wrong idea of raster tiles from the dodgy resolution Carto tiles, limited by serving bandwidth on the OSM website. The “old school” postgresql/mapnik toolchain can produce beautiful SVG/PDF maps. The classic national “ordnance survey”, e.g. French IGN, maps are another case in point.
It’s an interesting point, though I’m not aware of any National Mapping Agency cartography produced with Mapnik. Much of it is hand-drawn to a greater or lesser extent, or using proprietary tools.
There is no particular reason why that has to be served as rasters rather than vectors - most of OS Landranger could be delivered as vector tiles if OS had the time and budget to digitise it, for example. The main issue is label placement, which isn’t great in Mapnik and much worse in Mapbox/Maplibre GL.
Arguably, with both Mapnik (raster) and Maplibre (vector) approaches, the difference between “mediocre” and “ok-ish” cartography is the amount of preprocessing you’re prepared to do. Sometimes this simply isn’t available in the mainstream tools: there’s nothing in PostGIS that will do building merging of the sort you’d expect from an OS map, for example. You can approximate it with a positive then negative buffer but that potentially causes issues with narrow streets.
(There’s much more I could say but I’m aware that cartography critics are traditionally themselves the worst actual cartographers, so I’ll stop there 
)
5 Likes
Indeed. I didn’t mean to imply that national mapping agencies might be using mapnik to generate their topographic maps!
The pre-processing point is important. It would be great, for example, to do some prioritisation of peaks so that an “appropriate” number of peaks were displayed as a function of zoom level. This has been vaguely discussed for Carto, but would be useful for any style. Indeed, it would be simpler to apply the methods to tilesets that are less beholden to minutely updates.
The thing about peaks is that they don’t spring up out of nowhere too often, so just like the coastline, you can get away with less-than-minutely updates.
It’s not that hard - I’ve done similar density-based postprocessing for cities/towns with an extra Postgres table and a little Ruby wrapper script, and I don’t see why the same approach shouldn’t work for peaks. Thus far I haven’t baked it into cycle.travel’s vector tiles but it’s on the to-do list!
That talks about using prominence, which is what I’ve been doing for a while (with an on the fly “guess” where prominence isn’t in OSM). It’s not in any sense “cartography”, but it gets better results than just raw ele numbers.
OpenAndroMaps, a well know provider of global Vector maps for mobile devices has implemented a system to class peaks into 5 categories, based on its topographic isolation (not on its prominence). Details are discussed in Anzeige Berggipfel in Elevate LE - openandromaps
It’s done with the help of a pre-calculated isolation list https://geo.dianacht.de/topo/topographic_isolation_viefinderpanoramas.txt , which generation is described in User:Maxbe/Dominanz von Gipfeln - OpenStreetMap Wiki
(All in German, but should be easy to translate them online nowadays)
This Peak seperation on the map works very well, at least a lot better than without this procedure.
1 Like
osm2pgsql’s generalization module offers a discrete isolation algorithm, which only takes a couple of minutes to run on the whole planet. We’ve only used it with cities right now but the original paper on the algorithm uses it for mountain peaks as well.
1 Like
So I got me a fresh topic :) Seems to be about peak-selection. I wonder how that is different in vector and raster maps: I suppose, selection both times done on the tile server?
Here some maps to make comparisons: In Search of the Großglockner, highest peak in Austria, second most prominent in the Alps, located in the Hohen Tauern, between Salzburg, Tirol and Kärnten, I always find it hard to find in OSM Carto, if it was not for Nominatim: Zoom in with the buttons to stay centred on Großglockner. See how peaks show and hide. Obviously, with settlements there is something different from peaks although some might be tempted to see parallels.
- OSM Carto: OpenStreetMap
- OpenTopoMap: OpenTopoMap - Topographische Karten aus OpenStreetMap
- Dianacht Map: Topographische Karte aus Openstreetmap-Daten
- Adiminstrative Topo Map: Austrian Map
From the OSM based set I like Dianacht the most. Looks to me amenable to serving as vector too. Obviously quite some preprocessing needed for ridges, valleys and such. The nice rendering of labels for lakes by the same author only used in opentopomap though. If those labels too expensive to compute on the client, a vector tile would have to include extra geometry for labels, that might span several tiles?
Obviously topo maps present other things too of interest for recreative activities, e.g. selection of PoIs, different path signatures, … (Dianacht even shows disused:highway=path)
UPDATE: Link to opentrailsmap for above location (as this is vector, off by one zoom level) below:
- OpenTrailsMap: OpenTrailMap by OpenStreetMap US
UPDATE II: Another vector topo map, now this one makes the Search trivial 
- Trailmap (from Finland): Trailmap - Löydä uusia polkuja (I’d say choice of peaks execellent, close to Dianacht, but behaving better while zooming! For use in mountainous areas little adaptations come to mind, apart from the peaks, but this is not the subject of that map.)
It sounds like you’re describing OpenTrailMap!
The vector tiles are from OSM US.
2 Likes
There was someone at State of the Map Europe who gave a lightning talk about his project, Ascend Maps. It’s a vector based map for hiking and other outdoor activities. He has created his own tile schema for the purpose.
It’s in the early stages but worth checking out. There is an app is in the iOS app store, for Android there’s an APK on the GitHub: GitHub - styluslabs/maps: 3D maps for iOS, Android, and desktop
1 Like
It doesn’t have to be. For the example I gave above, the prominence calculation and peak classification is done in one bit of code, which is used both at initial database load (raster), vector tile creation (vector) and minutely update (raster).
If you’re doing a spatial calculation that needs a spatial database then obviously you need a database , but you can create either raster or vector tiles from that.
If you’re doing extensive “fix it in the mix” postprocessing to create a nice cartographic map then again, you need a database and again, you can create raster or vector tiles from that.
As an example, this:
is just vector tiles created from tilemaker with no database. If you click the button at the top of the screen to look at the same area in the equivalent raster style you can go back and forwards. Some of the differences are restrictions of one technology over the other, some are just bugs where I haven’t replicated something properly. The vector toolchain won’t scale to the entire planet but If you wanted a vector map of a couple of European countries it’s moderately easy to create (a build takes about 90 minutes) and host (it just needs “a web site”, so … pennies per month).
This is primarily a mtb map for Finland so it’s perhaps not optimized for mountain ranges. But here’s what Trailmap does, for comparison.
3 Likes
It’s not different. Peak selection needs to be done on the server where it can look at all the peaks at once. This doesn’t change between client-side and server-side rendering.
1 Like
From my understanding, the single most important advantage a client side vector renderer has over a server side raster renderer: It knows the viewport. So theoretically, it could adjust the choice of which peaks to show at the current viewport. (Device dependant, so not the same as the zoom level.)
Anybody else here who thinks, outdoor recreation about more than which peaks to show?
I looked at the screenshots. It looks quite adequate. Slope map, it is in! But why that feature creep, 3D eg?
Not really. You only have a fixed viewport on static maps, and both client-side and server-side static maps can know the viewport. Once you have a map you can pan there’s no longer a fixed viewport. If your rendering isn’t viewport independent then the rendering of a given area will change as you pan around. This leads to labels suddenly appearing and disappearing.
1 Like