[Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

Minh Nguyen minh at nguyen.cincinnati.oh.us
Fri Nov 13 12:10:18 UTC 2015


On 2015-11-13 02:42, Paul Johnson wrote:
> On Sun, Nov 8, 2015 at 8:04 PM, Paul Norman
> <penorman at mac.com
> <mailto:penorman at mac.com>> wrote:
>
>     On 11/7/2015 10:18 AM, Kevin Kenny wrote:
>
>         I find lately that it needs a patched Mapnik, because Mapnik
>         (sensibly)
>         went to a read-only database connection, and one of Phil's stored
>         procedures modifies the database the first time that a shield
>         cluster
>         is requested. One of these times I'll fix it.
>
>         I'm a little disappointed that none of the 'standard' renderers
>         picked this up.
>
>
>     Phil's demo was an excellent proof of concept of pictorial shields
>     from route relations, but isn't something that can be reasonably
>     incorporated into a stylesheet as-is.
>     https://github.com/gravitystorm/openstreetmap-carto/issues/596 is
>     the OpenStreetMap Carto issue for shields from relations,
>     https://github.com/gravitystorm/openstreetmap-carto/issues/508 is
>     the one for pictorial shields.
>
>
> There's been a lot of productive talk thus far about potentially moving
> this forward, but I'm curious if it makes any difference if we preserve
> the existing legends for ref right now, but start rendering the route
> relations for the existing style legends where available and just skip
> shields until a viable read-only method is developed on the back
> burner.  Or is the problem not necessarily depending on shield legends
> but something more central?

I'm not very familiar with the toolchain involved here, but this is what 
I gather after racking my brain on the issue for some time:

osm-carto and lots of other styles rely on osm2pgsql to import OSM data 
into a Postgres database. There's already rudimentary support in 
osm2pgsql for generating geometries based on route relations. 
Specifically, it reads in each cycling or walking route and turns it 
into a linestring that coincides with the member ways.

This is fine for OpenCycleMap, which represents routes as translucent, 
badged overlays on roads and trails. But that won't necessarily work for 
road shields. You have to somehow conflate shields on ways with shields 
on the overlaid route. My impression is that that could be expensive, 
though I haven't looked deeply into it. So you'd have to ignore all refs 
on all ways, which could be a nonstarter in parts of the world that have 
yet to see the relation light.

So this osm2pgsql issue asks for a way to apply the relation's tags on 
the member ways:

https://github.com/openstreetmap/osm2pgsql/issues/230

It's a great idea, but it depends on keeping all potential route member 
ways in memory until the relations are all done processing. Or issuing 
lots and lots of UPDATEs. Either way, it sounds expensive, but I really 
hope I'm wrong.

At a higher level, this openstreetmap-carto ticket covers the overall 
enhancement:

https://github.com/gravitystorm/openstreetmap-carto/issues/596

The question then becomes: what sort of shield do you display? Obviously 
switching to pictoral shields is a large undertaking in itself, due to 
the amount of artwork required. But if we instead stick to the textual 
badges for now, we have some additional complications: in the U.S., a 
badge with just a number is horribly ambiguous. Out in Logan County, 
Ohio, there's a state route, county route, and township route all with 
the same number, and two of them intersect.

http://www.openstreetmap.org/relation/184351
http://www.openstreetmap.org/relation/2599900
http://www.openstreetmap.org/relation/2605494

So we need alphabetic prefixes on badges. Unfortunately, it isn't 
straightforward to map `network` values to familiar alphabetic prefixes:

network=US:I                  => I ###
network=US:US:Business        => US ### Business
network=US:CA                 => CA ###
network=US:OH                 => SR ###
network=US:TX:Beltway         => Beltway #
network=US:KY:Parkway         `short_name`?
network=US:NY:Onondaga        => CR ###
network=US:OH:MED:Harrisville => T-###

Then there's the issue of concurrencies, where the relations aren't in 
any particular order. You'd need rules for prioritizing one network over 
another in badges or shields. The best heuristic I've come up with is to 
sort by the number of colons, but that doesn't work in Europe (where 
they don't use the same format) or even for some of the examples above.

So in short, it's complicated, and that conclusion comes from someone 
who's both enamored with route shields and very naïve. But no one said 
it was easy. :-)

-- 
minh at nguyen.cincinnati.oh.us




More information about the Talk-us mailing list