i've removed prior discussion so that this can stand on its own.
i admit that the distinction between keys and values is a bit
blurry; it would be a fallacy to claim that data goes only in
values because that's obviously not completely true.
however, i will assert that for key space to be
On 23/01/2015, Никита acr...@gmail.com wrote:
the classic example being the name key.
This is bad example. We have many tags with their own semantic:
http://wiki.openstreetmap.org/wiki/Names#Key_Variations We don't need
name_1, name_2 or name#1 or name#2 keys.
Of course when you can figure
Tag namespaces already provide a kind of data structure facility. IMHO
a syntax that is close to the traditional way of representing vectors of
structures would be something like this:
addr[1]:housenumber=1234
addr[1]:street=Main Street
addr[2]:housenumber=7654
addr[2]:street=Elm Avenue
All
On 23/01/2015, althio althio.fo...@gmail.com wrote:
Visually for index I would go for # or - but I don't know if that
is acceptable regarding special characters status.
name=*
name#2=*
name#3=*
I really like using '#' as the index separator. It is sometimes
pronounced number. It hasn't been
On 23/01/2015, moltonel 3x Combo molto...@gmail.com wrote:
name=purple
name#2=orange
name#3=green
How do you query for green in overpass? In JOSM?
josm: name(#\d+)?=green
overpass: I don't know it enough
Note that if key#index=value becomes commonly used, tools like josm
and overpass (and
Le 23/01/2015 21:53, moltonel 3x Combo a écrit :
Given that relations in general are not going away, the proper
solution to the novices have trouble with relations problem is not
to use less relations but to make relations easyer to edit and better
documented. FWIW, I feel there is slow but
On 23/01/2015 20:53, moltonel 3x Combo wrote:
+1 to all of that
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
2015-01-23 21:53 GMT+01:00 moltonel 3x Combo molto...@gmail.com:
On 22/01/2015, Johan C osm...@gmail.com wrote:
From an OSM point-of-view, which includes being friendly towards novice
users, relations should be avoided whenever possible. And
associatedStreet
relations are avoidable.
The
On 22/01/2015, Johan C osm...@gmail.com wrote:
From an OSM point-of-view, which includes being friendly towards novice
users, relations should be avoided whenever possible. And associatedStreet
relations are avoidable.
The counter-argument is that a novice is less likely to break the data
when
On 22/01/2015, Charles Basenga Kiyanda perso...@charleskiyanda.com wrote:
I have to add fuel to a heated discussion, but in the whole exchange on
whether or not semicolon lists should be allowed/used, the most obvious
example (to me) that requires semicolon lists was not mentionned,
namely:
On Jan 24, 2015, at 11:04 AM, Richard Welty rwe...@averillpark.net wrote:
On 1/23/15 8:37 PM, Warin wrote:
Yes .. it makes the admin more complex. But it will get some to say
something, and get others off the group. Flame away.
i do not think it appropriate for the membership of this
Or wait, I actually misunderstood you, my point is still valid. Did you
mean
color[1]=yellow?
color[2]=red?
But again, how do you query then? Query for red? color[*]=red? Regexes
again.
___
Tagging mailing list
Tagging@openstreetmap.org
On Fri, Jan 23, 2015 at 10:08 AM, Никита acr...@gmail.com wrote:
But again, how do you query then? Query for red? color[*]=red? Regexes
again.
He is representing an array where [1] is the first position. There is
no need for regexes.
___
Tagging
Agree, there no regexes at first. But is it possible to query this tagging
scheme? Lets say you have
color[1]=purple
color[2]=orange
color[3]=green
How do you query for green in overpass? In JOSM?
And what if for another object you will have different set of tags with
different order?
That object is not part of the result set. Maybe he meant how to find out
that an item is missing from the list? Well I don't see how that becomes
any easier by moving the values over to the keys.
color:green!=* in overpass should return values without information about
green color or
On Sat, Jan 24, 2015 at 6:40 AM, Никита acr...@gmail.com wrote:
Well I don't see how that becomes any easier by moving the values over to
the keys.
color:green!=* in overpass should return values without information
about green color or color:green=no will return objects without green
color
Well not perfect solution at the moment, but least I don't need to teach
somebody regexes: color:green=yes | color:lightgreen=yes | color:
bluegreen=yes | ...
But how this is different from regexes? you would say.
1. There no regexes at all
2. There should be pages about
On 23.01.2015 21:53, moltonel 3x Combo wrote:
The counter-argument is that a novice is less likely to break the data
when updating an area that is mapped using associatedStreet. I like
the fact the fact that people need not even be aware of addresses in
order to fix a street name.
That's not
On 22/01/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
a minor issue with semicolon separated lists: we don't have yet defined how
to escape actual semicolons in values.
To me, that is actually a major issue (putting blank fields in the same basket).
Defining how litteral semicolons
On 22/01/2015, Tod Fitch t...@fitchdesign.com wrote:
With respect objects that have multiple values for a key, the arguments seem
to come down to either:
1. key=value1;value2;. . . ,valueN
2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes
3. keyindexseparatorindex=value
As a
On 22/01/2015, fly lowfligh...@googlemail.com wrote:
Am 22.01.2015 um 21:32 schrieb Tod Fitch:
key:1=value1
key:2=value2
key:3=value3
No not at all, this makes it worse. Numbers are way to general and you
gain little.
: is usualy used for subkeys so key1, key2 would even be better.
the classic example being the name key.
This is bad example. We have many tags with their own semantic:
http://wiki.openstreetmap.org/wiki/Names#Key_Variations We don't need
name_1, name_2 or name#1 or name#2 keys.
name=*
name#2=*
name#3=*
There no point in using indexes in key. You need
I don't understand the insistence in using regexes as some kind of argument
against semicolon lists.
A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT regexes.
Me and other developers in this thread (Imagic, Friedrich, David, Dmitry,
Marc) are
On Jan 23, 2015, at 7:47 AM, Richard Welty wrote:
On 1/23/15 10:13 AM, jgpacker wrote:
I don't understand the insistence in using regexes as some kind of argument
against semicolon lists.
A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT
While I am no skilled programmer I agree with the next points:
(any guru is welcome to disregard my following opinion if he wants to)
Just because one can use a regular expression to grep out a certain meaning
doesn't mean it's a good thing to do and will always work.
Regexps are AFAIK quite
Also, I think that the subkey separator (':') should be different from
the index separator (let's say '_' although that isn't fully
standardised yet). Because I could concoct an example where 2 is a
subkey rather than an index.
Visually for index I would go for # or - but I don't know if that
On 1/23/15 10:13 AM, jgpacker wrote:
I don't understand the insistence in using regexes as some kind of
argument against semicolon lists.
A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT regexes.
Me and other developers in this thread (Imagic,
27 matches
Mail list logo
