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

"Petr Morávek [Xificurk]" xificurk at gmail.com
Thu Aug 2 13:27:10 BST 2012


Hello Peter,

you have raised interesting question, so I'll try to address at least
some of the questions regarding editor support and describe it from my
point of view (as user of Merkaartor).

Peter Wendorff wrote:
> The point is to keep the correct, even if deprecated work of local
> mappers intact.
> A mapper that has no idea about relations and added the ref tag to "his"
> streets instead, but then sees, that some stupid people from somewhere
> else deleted that stuff, probably not even recognizing now that it's
> because of duplicates, for him it's "they deleted my work".

I presume the workflow, could be something like this (I'll again write
in first person):
I download the area I've previously edited. Click on the road I've
created and see that my ref tag is gone, but wait... what's this dashed
square that got highlighted? Let's click it and see. Oh, here is the ref
tag and a bunch of others and wait... It highlighted other ways as well,
why is that? Aha, it's the whole primary road number 42.

Note, you don't need to be a brainiac or have detailed knowledge about
the underlying data structure to figure this all out. And if I'm curious
about any of this, I can go online and consult the wiki, ask the
directly the user that created/modified the relation, or send a question
to a mailing list, forum, ...

I always thought this cooperative incremental improvement is a key
feature in OSM community. If somebody comes and redeos and adds his own
bits to the stuff I've created, I don't get offended.

> You claim, it's more easily maintained in the relation - but for many
> mappers it isn't, because they don't know about the relations or at
> least they don't know how to maintain these relations.

Once I know, what I described above, I can go ahead and do more stuff like:
If I know that from point A to point B there is a road ref=123 and want
to make sure it's in OSM. I download the area, click arbitrary part of
the road, oh and here we go again with the highlighted box, click it.
Great, it highlighted a bunch of ways and:
* wait, it says ref=123$, hm... that seems like typo, let's fix it.
* somebody forgot to add this piece, let's add it.
etc.

Compare this with the alternative. The easiest way to go about this is
probably find all ways by given criteria. But if there is some kind of
mistake, I want to fix, I have to go and correct it on every single way,
instead of simply selecting them and adding/removing from relation, or
correcting the typo in one place.

I admit this is my personal view and is significantly influenced by the
editor I use. But I think I've demonstrated that the problem with
editors is not that bad as some people say, or at least it doesn't have
to be. If you think that the tasks above are hard to do with your
favorite tool, then maybe we should talk about how to improve them.

--
I have some questions as well (I've already mentioned it before, but it
was missed):
How should I correctly tag the situation when a part of road has more
refs? I don't mean the cycle/hiking routes now, because they have pretty
well-established tagging via relations. I'm not sure what the situation
is in other countries, but in Czech Republic every bridge has its own
reference number. If we abandon the idea of relations for ref numbers,
what should I put on that part of the way?
* Reference of the bridge only? I don't think that's right - if I go
over the bridge I'm still on the road nr. XY.
* Both references concatenate by semicolon? Won't this break the
algorithms that join the ways with same refs? It will definitely break
the find tools in editors.
* Or should I simply give up and don't try to add this information?

And how about a roundabout intersection of two roads, what ref should be
on it?

I don't know how to correctly solve these conflicts within the tagging
scheme of refs on ways.

Best regards,
Petr Morávek aka Xificurk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120802/5bf181fd/attachment.pgp>


More information about the Tagging mailing list