-
-
Save anonymous/c1c256ae066ed1444354 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
> 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