[Tagging] Moving forwards with multi-valued attributes

Kevin Kenny kevin.b.kenny+osm at gmail.com
Mon Jan 23 21:12:02 UTC 2017


On Mon, Jan 23, 2017 at 3:15 PM, Paul Norman <penorman at mac.com> wrote:

> On 1/23/2017 1:42 AM, Colin Smale wrote:
>
>> This subject has been discussed so many times in the past, over several
>> years. It seems that OSM is incapable of moving forward. The current data
>> model does not accommodate multi-valued attributes
>>
>
> It used to, then we moved forward to one that doesn't, because that's what
> all the tools work with.* Leadership was done, a choice was made on
> multiple values for a key in the data model, and now people are claiming a
> lack of leadership in the same choice.
>
> * This was before I joined OSM


I've not been on OSM all that long myself, you're an old-timer relative to
me. Still, I don't see an unambiguous consensus regarding fields with
multiple values.

In particular, the specific keys 'name_1', 'name_2', ... are widely
tolerated, at least in part because various imports left them all over the
database. I suppose this situation can be regarded as a special case.

There's no obvious solution in the case where multiply-valued keys need to
be kept in correspondence, which appears to be what prompted the current
discussion. It's not obvious that the present data model can handle the
complexity of "destination #1 on the sign shows Erie Boulevard, toward
Schenectady and the GE plant, while destination #2 on the sign shows State
Street (NY 5) West, proceeding toward Scotia". I suspect that the best we
could do is transcribe the sign verbatim, and then show lane restrictions
and further destination signs on the link road. Having multiple sets of
semicolon-separated values that have to be kept in correspondence seems
error-prone. Moreover, I don't know at present of any data consumers that
can handle such a notation. (Then again, I don't know of any data consumers
that can handle the concept in any notation, so that's not a good argument.
It is evidence, however, that the current discussion isn't entirely
revisiting already-trodden ground.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170123/e6a74b1a/attachment.html>


More information about the Tagging mailing list