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. cheers Richard -- 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. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
