> Imo, yes, you should put all those details onto the objects that carry > addr:housenumber (either nodes or building outlines). That's the method > intended by the documentation and I don't see a good reason for not > sticking to it in this case.
inconsistent duplication. I can't image having to convince anyone that this was bad: http://thedailywtf.com/Articles/The-Utlimate-State-Selector.aspx Why is this a special case where duplication is a good thing? It may be that no-one can think of a better way of doing it - but that doesn't make it good. > Brian Quinion wrote: >> However there are >> plenty of cases where people have used it as I suggested because it >> makes sense > > It does not make much sense to add information to a temporary construct > (interpolation way) that will be replaced with individual tags on each > building outline in the long term anyway. I think in many places this data will not be very temporary. Due to the rapid rate of mapping Germany may well be the exception. >> and any one implementing reading OSM data for addresses >> will have to deal with both > > I think an evaluator can ignore addr:street on interpolation ways - with > documentation and tools (such as JOSM presets) supporting consistent > tagging you will be able to extract most data this way. Unless, of > course, enough people prevent consistent tagging by denying its possibility. Well speaking as an evaluator I can say that simply coping with the possibility of addr:street being on the way rather than the node is very trivial compared with all the other difficulties, in fact it falls out of the code required to cope with the relations anyway. Discarding all data that doesn't perfectly conform to the specification would remove quite a large percentage - this case alone accounts for around 3% of the data. In a way I don't actually care about which is the 'correct' answer, I've written my code to cope with this and a lot of the other edge cases because in practical terms with the current data that is the only choice. It is more that I'm confused by the the apparent assumption that this is the one specification in OSM that will never change - everything else in OSM evolves. -- Brian _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
