2010/8/19 Tobias Knerr <o...@tobias-knerr.de>: > On 19.08.2010 18:28, Tom Chance wrote: >> On 19 August 2010 16:54, Tobias Knerr <o...@tobias-knerr.de >> <mailto:o...@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 editable"? _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
