On 11/09/2014, Andrew Hain <andrewhain...@hotmail.co.uk> wrote: > > The TIGER import used name_n istead of alt_name_n. > > Have any data consumers got a preference for one or the other?
To me there's very little semantic value in distinguishing between name_2 and alt_name. Even old_name and loc_name arguably don't bring much to the table (I do see the nuance, but it doesnt seem to be worth the complication). We've got the same problem with the ref tag and many others. We've invented loads of conflicting schemes because there's no obviously correct solution for this common problem. To me it's a failure in the osm data model, like the lack of a dedicated "area" object type. It should be possible to assign an ordered list of values to a key, without resorting to a confusing collection of hacks. Maybe an update to the data model would be so disruptive that it wouldn't be worth it. Maybe we could decide instead on a key separator that only and always indicates an alternate value (neither "_" nor ":" fit the bill). But it'll face the usual adoption uphill battle (xkcd 927), and efficiency/ambiguity issues (like the current use of relations and implicit area=yes/no tags to identify areas). _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk