Skip to content

Instantly share code, notes, and snippets.

Created January 27, 2015 10:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save anonymous/c1c256ae066ed1444354 to your computer and use it in GitHub Desktop.
Save anonymous/c1c256ae066ed1444354 to your computer and use it in GitHub Desktop.
> BTW, who are those "people" anyway? Are you speaking for them for real or did you elect yourself as their spokeman without asking them?
Follow my countless links to taginfo and wiki before. Most people use "color:something"=approach, some people still unaware of problems in color=...;...;...
> Overpass could handle semicolons, if it wanted to. That is, it could provide a query interface which can fetch you the "green", etc. even when there are semicolons used without require the use of regexp. I think it even should do that!
Why it should do this? Nobody use tag fuel=...;...;... or payment=...;...;...
How would your approach deal with this then?
tag:;;;;=yes
or
tag:=yes four times(?!?)
Does that make sense to "newbies"?!?
...I suppose you'll respond that this was a bad example and I'll
whole-heartedly agree with you :-).
Well my question was too abstract. Here is better example:
color="green;;red;;yellow"
color="green;red;yellow"
How do you know if something escaped or not?
I think you clearly agree that this is indeed better approach for newbies and preset developers:
"color:green"=yes
"color:red"=yes
"color:yellow"=yes
Root of the problem is in "some character to escape". If there none, then you don't have to parse anything (value or key). We need real structure for sets/unindexed arrays with support for nulls. I believe you will agree that you cannot parse 3 null values from this string:
";;;;" - this wasn't bad example actually, this was also demo that you cannot encode nulls using strings without defined character for nulls... (CS gods please forgive me for saying this)
IMO any further discussion on this topic will be pointless and will end like "yes, we do need native structure for multi valued tags". For now we have to agree about ban in value part of tags for most tags (excluding openings_hours=*, simple ref="3;4" etc). Again this was stated at wiki multiple times long before changes to "Semi-colon_value_separator" changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment