[Tagging] Data redundancy with "ref" tag on ways vs relations

Peter Wendorff wendorff at uni-paderborn.de
Tue Jul 31 11:59:34 BST 2012

Am 31.07.2012 12:12, schrieb "Petr Morávek [Xificurk]":
> Peter Wendorff wrote:
>> Am 31.07.2012 10:33, schrieb "Petr Morávek [Xificurk]":
>>> If he knows for sure, that on that road from point A to point B is
>>> ref=42 and not ref=56 as the OSM data says, then the user should fix
>>> it as I wrote in previous email. Remove the ways from the current
>>> relation and add the correct ref tag to the ways themselves, or create
>>> a new relation for them. Problem fixed!
>> Hooray!
>> now we have a relation that's incomplete again - how to use it?###
> What do you mean incomplete? You can use it the same way as before, the
> old relation retains the latest known data about the other ways.
about the other ways, but not about the removed ways - so it's again a 
route with gaps in between pieces, where ways have been removed, 
breaking the connectivity of ways.
>> It's hard to see these changes.
> You can see it on the rendered map, in navigation SW, in QA tools, what
> more do you want? I don't get it.
Which rendering does render relations for road numbers? highway shields 
afaik are usually drawn from the ways currently.
Gaps in the route are not detectable, as long as the route is not marked 
in a separate color; for small gaps this require on top of that a 
sufficiently high zoomlevel.

Show me the map where the route relations (not public transport, but 
roads) are rendered.
Show me the QA tool that detect these changes.

Sure: someone could build it; but you cannot require all mappers to 
follow your rules as long as there's no benefit, no application that 
uses it RIGHT NOW.
>>> Note, that if the edit was mistake after all, then QA tool analyzing
>>> road network should catch that.
>> How should it do that?
> The graph structure of the road has changed.
Sure, but the graph structure changes, when there's a detour build as an 
alternative route around a city - where the authorities decide to 
attatch the same ref to.
This isn't necessarily an error.


More information about the Tagging mailing list