On Fri, May 18, 2018 at 10:38 PM, <osm.tagg...@thorsten.engler.id.au> wrote:
> It’s not an carto-osm bug, it’s a level lower: > > > > https://github.com/openstreetmap/osm2pgsql/issues/230 > > > > If that ever gets implemented properly, then carto-osm and other data > users can make use of it… > > > > *From:* Paul Johnson <ba...@ursamundi.org> > *Sent:* Saturday, 19 May 2018 12:12 > *To:* Tag discussion, strategy and related tools < > tagging@openstreetmap.org> > *Subject:* Re: [Tagging] tagging arbiters (gone OT) > > > > On Mon, May 14, 2018 at 8:03 AM, Dave F <davefoxfa...@btinternet.com> > wrote: > > 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 > > > No. > > 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 routes?" 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) . . . route_8 network_8 ref_8 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 - https://kbk.is-a-geek.net/catskills/test4.html?la=41.4080&lo=-74.4177&z=14 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.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
