[Tagging] [OSM-talk] collection/street relation: which one to use?

Simone Saviolo simone.saviolo at gmail.com
Fri Aug 20 08:39:04 BST 2010

2010/8/19 Tobias Knerr <osm at tobias-knerr.de>:
> On 19.08.2010 18:28, Tom Chance wrote:
>> On 19 August 2010 16:54, Tobias Knerr <osm at tobias-knerr.de
>> <mailto:osm at tobias-knerr.de>> wrote:
>>     Basic address editing, however, requires more knowledge if implemented
>>     using relations - which is bad, because editing addresses is one of the
>>     most basic tasks and would otherwise be well suited for new mappers.
> [...]
>> The solution is in making the editor UIs more usable, not refusing to
>> use the elegance offered by relations.
>> A more usable editor for addressing might, for example, offer a
>> drop-down list of ways to associate a new object with rather than making
>> them manually type in addr:street=whatever. The software could then
>> automatically check for a relation and create one if it doesn't exist.
> A specialized editing tool that is hand-written for a single task will,
> in theory, always offer the best UI for that task. And, of course, the
> underlying representation doesn't matter anymore if you use such a tool:
> Neither relations nor plain tags have an advantage if you hide them
> behind software abstractions.

Seriously, how does having a "reference" to a street in a relation (so
that if the street changes nothing else needs to be done, because the
relation is already updated and the addresses are computed fine) offer
"no advantage" over having to go through an arbitrary number of
objects and check if their addr:street matches with the name of a way?
How far would we have to go to find that way? How close would the
match have to be?

While it's true that a high-level management of the issue *could*
render both methods useful and useable, still the lack of it strongly
requires a schema that is ROBUST - which having addr:street on every
house number is not.

> Unfortunately, writing specialized editing tools for each task scales
> badly with the number of features that can be mapped. This means that we
> have to deal with the fact that these tools will likely not be available
> for most relation types in most editors* for quite a while.
> Therefore, I still prefer things to remain as easily editable as
> possible with general purpose editing tools, instead of relying on
> specialized tools that may or may not be widely available in the future.

Aren't relations easily editable? But wait, you wouldn't actually have
to edit it! The first mapper to create the way or to add a house
number would create the relation, which, admittedly, may be a slightly
harder task (it's still easy if you take five minutes to read the wiki
and to push buttons); if a mapper wants to add a housenumber, he would
only need to find the appropriate relation (in JOSM, he'd select the
way of the street, see all the relations it's a member of, and usually
there won't be thirty of them) and add the new node; if a mapper wants
to edit the housenumber of a node, he would do just that, on the node.
In the (not so unlikely, seeing the state of the map) event that a
street changes name or city or whatever (postal code, maybe?), only
the way itself would need to be changed, and every address would be
up-to-date right away.

On the other hand, if I wanted to add a house number I would have to
add the addr:housenumber tag on the node, then, wait, I have to put in
the very same name as the street, so I pick the street, find its name,
copy it, go back to the node, paste it in the addr:street tag. Rinse
and repeat, because I've had the good idea of adding a hundred house
numbers for the few blocks around my house. How is this "more easily

More information about the Tagging mailing list