+1 Am 24.09.2013 08:44, schrieb Bryce Cogswell: > On Sep 23, 2013, at 10:45 PM, Jochen Topf <[email protected]> wrote: > >> On Mon, Sep 23, 2013 at 01:44:23PM -0700, Paul Norman wrote: >>>> From: Jochen Topf [mailto:[email protected]] >>>> Sent: Monday, September 23, 2013 6:51 AM >>>> To: [email protected] >>>> Subject: Re: [OSM-talk] Who interprets semicolon in tag values? >>>> >>>> I finally wrote down what I found out about semicolons in tag values and >>>> what I think about them. Turns out there isn't much software that >>>> interprets them and where it does, only in special cases. Thanks to all >>>> who replied and sorry that I haven't mentioned every case in my blog >>>> post. >>>> >>>> http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html >>> >>> It's worth noting that when two objects are merged in iD it splits the >>> tag's value into lists at semicolons, merges the lists from the two objects, >>> >>> and then turns the resulting list into a semicolon separated list. See >>> https://github.com/systemed/iD/issues/943. I believe iD is actually the >>> only editor that attempts to support semicolon lists in tags. JOSM and >>> P2 emit them, but don't interpret them. >>> >>> This of course doesn't avoid contradictory tags like tiger:separated=yes;no >>> but it at least avoids tiger:separated=yes;no;no;no;yes;no;yes;... >> >> This would be better if semicolons always indicated sets of values, which, >> as I describe in my blog post, is the wrong assumption. For 'ref' tags this >> is probably the right behaviour, for about anything else it is wrong. >> >> IMHO editors should either do something clever, if they know the specific >> tag and how it is used, or fall back to forcing the user to make a decision. > > It would be great if support for semicolons was opt-in for tags. If a > particular tag supports semicolons it should be documented along with the > appropriate semantics (ordered vs. unordered, etc.) during merges, and with a > hint in taginfo that editors could follow. Tags that don't opt-in should not > get special treatment. > > > _______________________________________________ > talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk
