[Tagging] tagging arbiters (gone OT)
kevin.b.kenny+osm at gmail.com
Sat May 19 04:17:21 UTC 2018
On Fri, May 18, 2018 at 10:38 PM, <osm.tagging at thorsten.engler.id.au> wrote:
> It’s not an carto-osm bug, it’s a level lower:
> If that ever gets implemented properly, then carto-osm and other data
> users can make use of it…
> *From:* Paul Johnson <baloo at ursamundi.org>
> *Sent:* Saturday, 19 May 2018 12:12
> *To:* Tag discussion, strategy and related tools <
> tagging at openstreetmap.org>
> *Subject:* Re: [Tagging] tagging arbiters (gone OT)
> On Mon, May 14, 2018 at 8:03 AM, Dave F <davefoxfac63 at btinternet.com>
> On 13/05/2018 22:34, Kevin Kenny wrote:
> I've long said that the final arbiters of tagging should be... the people
> who implement the routers, renderers, navigation systems,. search engines,
> and so on
> We already have the case where Carto-OSM are requesting duplicated tags on
> ways that are already in relations as they're unwilling/unable to right
> code that manipulates relation data.
> Is that a bug in the carto-osm github right now? Even the Linux kernel
> killed the ext filesystem dinosaur once ext4 became a thing, and by then it
> already overstayed it's welcome once ext2 was widespread. Killing the
> route-refs-on-ways dinosaur is long overdue.
Paul: I agree with you that in the specific instance you cite, the request
from the downstream data consumers is wrongheaded. (I include a more
technical description of my understanding of the problem below.)
In any case, I intended my remark to address the "what" rather than the
"how" - not the highly technical aspect of how relations interact with ways
and nodes, but rather "should objects of this type be distinguished from
objects of that type, and if so, how?" I've seen that go wrong on both
sides of the fence.
On the one hand, I have cases like the (still unsolved) "public land,
permit required to enter", which I wish to distinguish and render
differently on my maps from both "public land, open without prior
arrangement", and "private land". Whenever I've brought that up on this
list, I've been shouted down by people who insist that those three
categories should be only two. When I reply that I perceive three
categories, and wish to render them on maps that I produce, I've even been
accused of wishing to "tag for the renderer." I'm not trying to tell lies
in the tagging in order to have things render correctly in Carto. No
conceivable renderer can show as being different two objects that are not
tagged differently in some way!
On the other hand, I see endless discussions here in which people geek out
about whether 'gravel' means actual gravel, or railway ballast, what the
difference is between a draw bridge and a bascule bridge, and similar
niggling details where I can barely imagine any router, navigator, or map
renderer ever being able to make use of those fine details, much less how
the community could maintain that level of detail for an entire planet.
So - if YOU have a use for tagging that's not in our shared understanding,
well, "any tag you like", but I'd really appreciate it if, for instance,
the Wiki pages that discuss particular tags also were to discuss what the
use cases are! Right now we leap both to dismiss actual use cases "I'm
rendering a map that wishes to show ..." and invent useless tagging
"Someone, someday may care about the difference between ..."
That's where I insist that the data consumers rule!
Now, some technical details about route relations:
Right now, tagging route refs in Mapnik, when routes can be coincident, is
an unmitigated disaster. I know: I render my own maps from time to time.
The data model with the ref=* tags on route relations only is fine. What
isn't fine is that osm2pgsql and osmosis leave us with a schema that leaves
Mapnik no easy way to execute the query that it needs to render the highway
shields: "What are the the strings of ways that have identical sets of
It's bad enough that what I've resorted to is to create an auxiliary,
intentionally denormalized, SQL table that has columns:
idx (an arbitrary integer to serve as primary key)
way (the geometry)
highway (copied from the highway=* tag on the underlying way)
route=1 (the value of the "route=*" key on the first containing relation)
network_1 (the value of the "network" key on the first containing relation)
ref_1 (the value of the "ref" key on the first containing relation)
I've never seen more than eight routes overlaid, and that appears to be the
maximum that mapnik can handle in a shield cluster.
For each of the "route, network, ref" tuples, I use external scripts to
create an SVG file with the highway shield - derived at some remove from
Phil! Gold's 'osm-shields' project. I don't use Phil!'s clustering - I use
Mapnik's shield renderer instead. Phil!'s stored procedures are
incompatible with the read-only database connection used in current Mapnik,
so I avoid those as well. This lets me run with an unpatched Mapnik.
Instead of Phil!'s clustering, I use Mapnik's GroupSymbolizer, with a
ShieldSymbolizer as its renderer. The GroupSymbolizer requires that all the
graphic elements in the group be in a single row of a database result set.
I found it easier to create the auxiliary table in denormalized form than
to invent a stored procedure that would walk a properly normalized set of
relations and repackage the result as a single row. This is simply an
unfortunate design feature of Mapnik.
The results that I get are reasonably attractive -
shows a variety of shield shapes including some clusters - but the process
that I use would not scale to the planet.
It's truly nasty - the limitations seem to run from one end of the
rendering pipeline to the other. I can see where someone who is not aware
of all the low-level details would think that the obvious fix is in the
data model of route relations. (It isn't. I agree with you there.)
In general, dealing with relations in the osm2pgsql schema is problematic;
without the slim tables, it's downright impossible, and with them, it
requires some pretty sophisticated monkeying about with stored procedures.
But coincident routes are utterly insane to deal with, and the fault is in
the osm2pgsql data model, not in OSM itself.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging