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

Reply via email to