[Tagging] Data redundancy with "ref" tag on ways vs relations
richard at systemed.net
Tue Jul 31 10:56:17 BST 2012
Paweł Paprota wrote:
> The recommendation of using relations in this case is just to kick
> off the whole thing and define some base line for collaboration -
> not because I desperately am itching for fixing some technical
> design problem in OSM.
In theory there is certainly a logic to using relations for road numbering.
There is a tendency to use relations for absolutely everything, but in this
case, there's a strong rationale in those countries where a road can be part
of more than one route (e.g. US, Poland), and it would be saner to use the
same system the world over.
_However_, there's some pretty big technical obstacles to be crossed before
we can get there.
Firstly, as Peter and Martin have posted, editor support needs to be much
better. Right now, changing a road number via the ref tag is as simple as
clicking on the road and entering the number in a text field. Doing it via a
relation... well, first you need to search the wiki to find out if there's
already a relation for this route, then you need to copy the relation ID,
then you need to load it into your editor, then you need to add the way to
the newly loaded relation, and so on. And that's assuming that there _is_
already a relation and it _is_ listed on the wiki.
The user shouldn't be bothered with any of this. We need to be making OSM
easier to use, not harder. Fixing the above will require fairly serious work
both to editors (for the UI) and to the API (for a fast, efficient
bbox-limited search function).
Secondly, how do we cope with the relation member limit? If a road has too
many constituent ways, then we'll hit that. Again, that's either a big
usability problem (pity the poor novice who tries to add a bridge, i.e. two
new ways, and is told that they suddenly need to learn about super-relations
because this takes the relation over the limit) or a really gnarly piece of
code to invisibly handle this.
Thirdly, even 2000-member relations are trouble for the API in themselves.
It's very easy for their member lists and, especially, history to balloon to
the point where you can no longer view them through the /browse pages. This
may be fixable, but will require some serious hacking.
And finally, our osm2pgsql/Mapnik stack would need to be fixed to take
account of this, as would pretty much every other consumer of OSM data.
Don't get me wrong: I don't think it's a bad idea per se, and from a
normalisation point of view, I can see some compelling arguments for it. But
we're not in a position to do it yet, and as an editor writer, I would
rather spend time making OSM easier to edit than fiddling around with a data
model which works fine as it is.
View this message in context: http://gis.19327.n5.nabble.com/Data-redundancy-with-ref-tag-on-ways-vs-relations-tp5719083p5719160.html
Sent from the Tagging mailing list archive at Nabble.com.
More information about the Tagging