On 2015-11-13 02:42, Paul Johnson wrote:
On Sun, Nov 8, 2015 at 8:04 PM, Paul Norman
<[email protected]
<mailto:[email protected]>> 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. :-)
--
[email protected]
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us
