Sourdough includes a routes layer containing all linear features tagged route=*, including route relations as well as a handful of ways tagged e.g. route=ferry. This is unlike most other vector tile schemas, which usually include route relations only indirectly, by copying some of their tags (like ref and network) onto their member ways.
I chose this approach because it's in keeping with Sourdough's philosophy, which is to be a simple and direct mapping from OSM elements to vector tile features. But I think it remains to be seen whether encoding routes in this way is useful for cartography. Route relations in OSM represent a wide variety of features: from highways (in the American English sense, i.e. named/numbered long distance road routes), to hiking and cycling trails, to bus, subway, ferry, and other public transit routes. Most maps draw these different kinds of features in very different ways.
Road routes, for example, are usually represented by placing shield icons along them, while the road lines themselves are drawn separately based on information about the individual physical segments.
Road routes shown using highway shield icons in Americana
But for bus, subway, light rail, and other public transit routes, it's more common to draw a line on the map to represent the path of the route itself, even if that path traverses physical infrastructure like roads or railways that is also drawn beneath.
Public transit routes shown as colored lines in Apple Maps
Ideally, Sourdough's routes layer should support both of these use cases. But currently, there are a couple of problems with the layer that prevent this.
- Road route relations (
route=road) are currently omitted entirely, because they bloated the tiles too much when I included them. The problem is that there are a small handful of road routes that make sense to include at low zooms (Americana starts showing highway shields at z6 for national highways). But there are also a huge number of road routes relations in OSM for minor roads, like PLSS section line roads and even major streets in many US cities. And unlike OSM's highways where there is a functional classification scheme based on importance, the relations don't have any tags to tell you how important this road route is. So Sourdough will need to apply some heuristics to decide which road routes to include at low zooms.
- Tags like
colour, network, and operator are currently included as detail tags, not primary tags (i.e. they are not included at all zoom levels). But without these, it's not practical to color-code public transit routes, since the colors won't appear initially (only when you zoom in far enough).
Before v1.0, I'd like to revisit these details of the routes layer in order to make sure that it's usable for symbolizing routes on maps. I suspect that Sourdough's direct representation of routes as their own features, rather than "joining" route information onto roadways, is somewhat limiting cartographically (as many of Sourdough's other design decisions are), but that doesn't mean Sourdough can't at least support the most common ways that map makers will want to render routes on their maps.
Sourdough includes a
routeslayer containing all linear features tagged route=*, including route relations as well as a handful of ways tagged e.g.route=ferry. This is unlike most other vector tile schemas, which usually include route relations only indirectly, by copying some of their tags (likerefandnetwork) onto their member ways.I chose this approach because it's in keeping with Sourdough's philosophy, which is to be a simple and direct mapping from OSM elements to vector tile features. But I think it remains to be seen whether encoding routes in this way is useful for cartography. Route relations in OSM represent a wide variety of features: from highways (in the American English sense, i.e. named/numbered long distance road routes), to hiking and cycling trails, to bus, subway, ferry, and other public transit routes. Most maps draw these different kinds of features in very different ways.
Road routes, for example, are usually represented by placing shield icons along them, while the road lines themselves are drawn separately based on information about the individual physical segments.
Road routes shown using highway shield icons in Americana
But for bus, subway, light rail, and other public transit routes, it's more common to draw a line on the map to represent the path of the route itself, even if that path traverses physical infrastructure like roads or railways that is also drawn beneath.
Public transit routes shown as colored lines in Apple Maps
Ideally, Sourdough's
routeslayer should support both of these use cases. But currently, there are a couple of problems with the layer that prevent this.route=road) are currently omitted entirely, because they bloated the tiles too much when I included them. The problem is that there are a small handful of road routes that make sense to include at low zooms (Americana starts showing highway shields at z6 for national highways). But there are also a huge number of road routes relations in OSM for minor roads, like PLSS section line roads and even major streets in many US cities. And unlike OSM'shighwayswhere there is a functional classification scheme based on importance, the relations don't have any tags to tell you how important this road route is. So Sourdough will need to apply some heuristics to decide which road routes to include at low zooms.colour,network, andoperatorare currently included as detail tags, not primary tags (i.e. they are not included at all zoom levels). But without these, it's not practical to color-code public transit routes, since the colors won't appear initially (only when you zoom in far enough).Before v1.0, I'd like to revisit these details of the
routeslayer in order to make sure that it's usable for symbolizing routes on maps. I suspect that Sourdough's direct representation of routes as their own features, rather than "joining" route information onto roadways, is somewhat limiting cartographically (as many of Sourdough's other design decisions are), but that doesn't mean Sourdough can't at least support the most common ways that map makers will want to render routes on their maps.