Am 22.01.2015 um 21:18 schrieb Martin Koppenhoefer:
a minor issue with semicolon separated lists: we don't have yet defined how
to escape actual semicolons in values.
Hi,
Is that an issue?
IMHO it's only an issue for tags where the values are names as a
semicolon can be avoided easily for any
I have placed a request to stop these edits on the users talk page and
warned him that I will ban him if this kind of working against the
community continues.
Please let me know if the problem continues, as I don't watch the tagging
list permanently.
Wolfgang
* Martin Vonwald
I did not read any apology so far, which would be a first step.
I think he was banned from this mailing list for the time being, so he
would have to apologize elsewhere; but I agree that would help make amends.
I would also ask him to avoid making the issues personal.
But to be honest, I don't
Who has admin power in the Wiki? I again request a ban of this user.
Martin
2015-01-27 11:31 GMT+01:00 jgpacker john.pack...@gmail.com:
Not five minutes later, he already reverted my changes, justifying it as a
single user opinion and undiscussed changed.
I also fixed some of his additions
Our friend Никита (user Xxzme in the wiki) put his opinion in the wiki
regardless of the opposition.
Since, as far as I can see, the discussion is still ongoing, I reverted his
changes.
--
View this message in context:
Not five minutes later, he already reverted my changes, justifying it as a
single user opinion and undiscussed changed.
I also fixed some of his additions in other pages, but he is already
reverting them.
It seems he is trying to win the discussion by Fait accompli
Am 24.01.2015 um 17:28 schrieb Martin Vonwald:
2015-01-24 17:20 GMT+01:00 Никита acr...@gmail.com
mailto:acr...@gmail.com:
Are you an idiot? I mean really.
I hereby request a ban of this individual from this mailing list and I
definitively support an OSM-wide ban.
+1
this user
On 01/24/2015 10:28 AM, Martin Vonwald wrote:
2015-01-24 17:20 GMT+01:00 Никита acr...@gmail.com
mailto:acr...@gmail.com:
Are you an idiot? I mean really.
I hereby request a ban of this individual from this mailing list and I
definitively support an OSM-wide ban.
On Sat, 24 Jan 2015, Никита wrote:
Valid point, but also should suggest good practices for people who would
like to benefit from default indexes:
API performance
API doesn't care. Or which API call you're refering to?
overpass performance
Overpass could handle semicolons, if it wanted to.
On Sat, 24 Jan 2015, Никита wrote:
You know that it's always a trade-off, right?
Exactly. Regex advocates are ponies in DB design.
disk usage/IO
Index lookup for color:green:lightgreen=yes is fast.
So is the index lookup for color=...;lightgreen;... !
network traffic could increase.
You know that it's always a trade-off, right?
Exactly. Regex advocates are ponies in DB design.
disk usage/IO
Index lookup for color:green:lightgreen=yes is fast.
full table scan just to compute regex for each value is not
Or wait do you have an custom DB for OSM tailored both for regexes and
On 1/24/15 11:20 AM, Никита wrote:
ltivalue tags, there easier way to avoid problem: avoid multiple
values in /value /part of key=value.
i suggest learning to deal with it.
Are you an idiot? I mean really.
ok, i'm done here.
richard
--
rwe...@averillpark.net
Averill Park Networking - GIS
2015-01-24 17:20 GMT+01:00 Никита acr...@gmail.com:
Are you an idiot? I mean really.
I hereby request a ban of this individual from this mailing list and I
definitively support an OSM-wide ban.
___
Tagging mailing list
Tagging@openstreetmap.org
i suggest learning to deal with it.
Are you an idiot? I mean really. Try answer these points:
Insulting people will get you nowhere at all. If you want to be able to
perfom index searches, then import the data in tables with fields allowing
you to do so. That's the great thing about open data.
I suggest you to deal with it (sic!)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Insulting people will get you nowhere at all.
Well there over hundred messages and some people don't dare to study topic,
I was repeating my messages multiple times already.
If you want to be able to perform index searches, then import the data in
tables with fields allowing you to do so.
On Sat, Jan 24, 2015 at 11:36 AM, Никита acr...@gmail.com wrote:
reduced cpu load for database because there no need to compute smart regexes
You know that it's always a trade-off, right?
While the CPU usage *could* be lowered, disk usage/IO and network
traffic could increase.
There is no magic
On 1/24/15 10:58 AM, Nelson A. de Oliveira wrote:
On Sat, Jan 24, 2015 at 11:36 AM, Никита acr...@gmail.com wrote:
reduced cpu load for database because there no need to compute smart regexes
You know that it's always a trade-off, right?
While the CPU usage *could* be lowered, disk usage/IO
in order to catch them all you need color:*green*=yes, a (simple) regular
expression
I don't need any regex. STOP.
color:green=yes
color:green:lightgreen=yes
color:green=yes query is dead simple.
Even with your schema you will not be able to avoid that people will need
regular expressions to
2015-01-24 14:29 GMT+01:00 Никита acr...@gmail.com:
Clueless people
Once again I want to thank you for your kind words.
The end.
Any chance, that you will follow this rule anytime soon?
___
Tagging mailing list
Tagging@openstreetmap.org
On Tue, Jan 20, 2015 at 7:51 PM, Никита acr...@gmail.com wrote:
Wow. Quality of discussion here.
I even find the second example more difficult to visualize. It's just
worse than the first in every respect
payment=efectivo;visa;mastercard;american␣express
payment=mastercard;visa;efectivo
in order to catch them all you need color:*green*=yes, a (simple) regular
expression.
No, I don't. I use tags
color:green=yes
color:green:lightgreen=yes
And will search for color:green=yes while I wait for native multivalue
tags.
Even with your schema you will not be able to avoid that people
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
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:
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 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,
Which too schemes? I think you'd need to be more specific.
As for deprecating semicolon-delimited lists. I don't think it's practical
to abolish them completely, so they'll have to stay.
I do agree that it makes sense to try and avoid them as much as possible,
but it's simply not always
Hi Jo/Polyglot and list,
On 22 January 2015 at 12:01, Jo winfi...@gmail.com wrote:
Which too schemes? I think you'd need to be more specific.
1. key=values;separated;by;semicolon
2. several key:subkey=*
On Thu, Jan 22, 2015 at 12:59 PM, althio althio althio.fo...@gmail.com
wrote:
I even find the second example more difficult to visualize. It's just
worse
than the first in every respect.
From a mapper's point of view
My little +1 for key:subkey=*
New people don't know how to add new
It's an actual example:
https://www.openstreetmap.org/node/80725474
https://delijn.be/nl/haltes/halte/303059 (real time information)
121 characters... there's still some breathing room. I guess the risk of
the street getting congested is higher than hitting the 255 characters
limit.
Jo
Rattling on about those bus stops, I have an other example:
https://www.openstreetmap.org/node/485938967
bus http://wiki.openstreetmap.org/wiki/Key:bus?uselang=en-US yes highway
http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en-US bus_stop
First point:
It is good that several people invent, propose and use various schemes.
Second point:
At some point, unification of schemes with similar intent would be great.
As usage grows, having the same kind of data treated differently is a pain
for everyone, mappers, developers, maintainers
I even find the second example more difficult to visualize. It's just
worse
than the first in every respect.
From a mapper's point of view
My little +1 for key:subkey=*
In free text like this thread, several key:subkey=* may look more heavy and
complicated than
Am 22.01.2015 um 18:08 schrieb Marc Gemis:
On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com
mailto:althio.fo...@gmail.com wrote:
Well at least iD knows quite well about the semi-colon:
Just merge two ways together and you might get access=no;yes
highway=primary;path without any
Am 22.01.2015 um 21:32 schrieb Tod Fitch:
I've been following this and the addrN thread with a mixture of amusement and
irritation.
Lots of the arguments come down to how easy it is to parse using some tool or
another. Or whether the problem the original poster was trying to address
opening_hours:Mo-We 08:00-17:00 = yes
opening_hours:Th-Fr 08:00-21:00 = yes
would in my opinion lead to an inordinate number of subkeys.
If you were reading other people messages you would probably notice
that opening_hours=* tag was mentioned as minor exception to general rule *not
to use
Using a xxx:yyy schema also requires checkboxes besides every existing
value in JOSM presets. So I don't see how it is any easier for new mappers
or preset creators.
Problem in multiple values in value part in *key=value.*
How iD should parse cuisine=mexican;japanese?
This work repeated every
Propaganda. Propaganda. Propaganda.
But it's harder to get all tags in category. How would you get all the
payment methods, not the exact 'ellectrico'?
Why normal person need to know about all payments methods if he/she only
have mastercard/ellectrico/coins?
You probably never use data at all.
On Fri, Jan 23, 2015 at 12:22 AM, Никита acr...@gmail.com wrote:
we don't need to teach every person how to parse japanese from
cuisine=mexican;japanese
using f#$% regexes
In my code editor I can search for complete word by ticking a checkbox,
how simple is that ? It will not match
On 15-01-22 01:44 PM, tagging-requ...@openstreetmap.org wrote:
Message: 3
Date: Thu, 22 Jan 2015 18:08:49 +0100
From: Marc Gemis marc.ge...@gmail.com
To: Tag discussion, strategy and related tools
tagging@openstreetmap.org
Subject: Re: [Tagging] Wiki Edit War on using/avoiding
A) For which keys and/or type of data are semicolon lists pertinent?
For keys that can logically have multiple values and that are not the
main/defining key of the object.
B) How can semicolon lists be handled better in the different editors?
If you are using a tag from a preset, iD theorically
On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com wrote:
New people can have problems or make mistakes and then experienced
users can help and point to recommended tagging or explain good
practices .
Not everybody reaches out to community for help. Probably many just stop
a minor issue with semicolon separated lists: we don't have yet defined how to
escape actual semicolons in values.
cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Am 22.01.2015 um 14:07 schrieb Jo winfi...@gmail.com:
network DLVB;IBXL;TECB;TECC;IBXL
operator De Lijn;STIB/MIVB;TEC;STIB/MIVB
I'd completely refrain in this case from tagging these to one object and use
relations instead.
I cannot understand your example without illustration.
Hide the internals from the end-users.
We can easily hide
*something*:japanese=yes
*something*:korean=yes
under single field *something*=*traditional semicolon presentation*, but
not vice versa. I suggested plugin for JOSM that will present
traffic_calming = table; choker in Russia?
This is not specific to Russia actually. Not many software will support
tagging:
traffic_calming:table=yes
traffic_calming:chocker=yes
Is there problem to tag this in database and covert to traffic_calming =
table; choker to get support in legacy
When you ask to have it rendered, one of the arguments for not doing so
is that those extra fields are not imported in the DB specifically set up
for rendering. It's considered too complicated,
if data is clean and consistent, conversion process should be easy even for
legacy renders or routing
Getting all places with japanese and chinese cuisine around the globe in
Overpass: http://overpass-turbo.eu/s/7b2
2015-01-21 8:09 GMT-02:00 Никита [via GIS]
ml-node+s19327n5830778...@n5.nabble.com:
traffic_calming = table; choker in Russia?
This is not specific to Russia actually. Not many
The 'new' public transport scheme actually has 'binary' keys for bus, tram,
train, etc.
When you ask to have it rendered, one of the arguments for not doing so is
that those extra fields are not imported in the DB specifically set up for
rendering. It's considered too complicated, even though the
Getting all places with japanese and chinese cuisine around the globe in
Overpass: http://overpass-turbo.eu/s/7b2
cuisine data is clean is *easy to query right now. *It may get more
complicated at every moment.
Better try to query for 13 in ref=3;10;13;113;133 without loosing your
sanity.
Next
Please calm down. And do not insult other people.
Java has regular expressions as well [1], I know they are not for the every
day user, but this problem also holds for OR, AND. There are a lot of
people that do not understand logical expressions.
Furthermore, many word editors allow to search for
On 21.01.2015 09:06, Никита wrote:
If you trying to parse name=school *with any regex *to map it as
amenity=school* *you are wrong. OSM is not for you.
If you trying to parse currency=bitcoin;coin for coin, then stop it
right now. You have no idea how regexes or tags in osm work.
While I
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
We easily revert these edits in Russia. Quite often user who want to show
their regex fu will fail so hard to guess actual properly of the real
world.
We care
Now you're insulting the one person who was supporting you? Please
STOP this thread everyone. Please.
2015-01-21 8:55 GMT+00:00 Никита acr...@gmail.com:
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
We
Никита, you really need to accept regexe is a widely used technology and one
you really are not going to stamp out.
You missing the point. I do aware of POSIX standard. I do aware of perl
quirks and overengineered regex syntax.
JOSM uses Java. There no command line wiht perl in Java. STOP your
Hi,
On 01/21/2015 12:07 PM, Никита wrote:
*route_ref:De_Lijn:8=yes*
*route_ref:De_Lijn:9=yes*
*route_ref:De_Lijn:284=yes*
I want to see bolded keys in database directly
No. Relations have been invented specifically to avoid this.
Conceputally, the value space should not overflow into the
Andy Mabbett wrote:
Are any of the list's moderators reading?
Please see
https://lists.openstreetmap.org/pipermail/tagging/2015-January/021249.html
Richard
--
View this message in context:
Please
a) stop insulting people and using hyperbolic language
b) quote, and snip, properly rather than top-posting and repeating the
entire previous message
As you can see from https://lists.openstreetmap.org/listinfo/tagging I have
administrative powers on this list, and if this thread
We don't want name:Main Street=yes.
You are mixing everything in key, this is not what I suggest.
fullsemantickey=fullsemangicvalue shouldn't be moved to
fullsemantickey:fullsemangicvalue=yes
This makes to sense, now you have to parse key instead of value...
I only talk about separating
Click on the dots, ctrl-a, delete. It's a lot easier than regex.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
I agree.
Sorry, I thought the previous messages we renecessary so the server could
find out the who answered to who and to which thread this belongs.
So when you said snip the message, I thought of quoting the part you are
answering and not of excluding previous emails.
2015-01-21 12:51 GMT-02:00
On 21 January 2015 at 02:16, Никита acr...@gmail.com wrote:
Ad hominem. Wow. You are so low.
Then:
You are not only ignorant but annoying person. There no place for your
proganda or your unjustified claims.
and:
And you are egoiste who poison OSM database with garbage data.
Are any of
Better try to query for 13 in ref=3;10;13;113;133 without loosing
your sanity.
Next day I will add ref=3;10;13;113;133;13E — will you update your
query?
I believe the following regular expression is enough for both examples:
ref ~ \b13\b
\b means word boundary (any character that
Please snip the message to which you are replying to reduce it to the
minimum required.
The problem might be that some mail programs (such a gmail), just reduce
the included message to a button with 3 dots. So, one might not be aware
that there are hundreds of lines under it.
regards
m.
jgpacker wrote:
[8 lines of text plus 240 lines of quote]
Repeated request:
Please snip the message to which you are replying to reduce it to the
minimum required.
Anyone continuing to post disproportionately formatted messages like this
will be removed from the list.
Thank you.
Richard
\b means word boundary (any character that starts or ends a word, such as
space, colon, semicolon, etc)
However, word boundaries can be slow and are not recommended if you need to
search large areas (e.g. whole world, germany or similar).
In this case, we could use something like:
ref ~
On 19.01.2015 12:10, Richard Z. wrote:
##== Disadvantages of semicolon separated lists ==
##* parsing of values is required
sure parsing is required. How terribly difficult is it to split
a string by ;?
It's trivial.
Xxzme is one of those mappers who try to design tagging rules
Friedrich Volkmann
Ad hominem. Wow. You are so low.
, by making assumptions instead of asking those who know.
This is called data analys. Statistics. Numbers. There nobody to ask if
users prefer one method over another.
The resulting tagging rules are actually a burden for both mappers and
On 21.01.2015 02:51, Никита wrote:
payment=efectivo;visa;mastercard;american␣express
payment=mastercard;visa;efectivo
Now try to find *efectivo *with your regexes.
With a perl regex:
^[^=]+=(.*;)?\s*efectivo\s*(;.*)?$
Usually you only have the value in your variable, so you only need:
You don't know regexes and theory behind them. I don't care about your
one-line perl hacks.
You will never teach your ugly hacks to to OSM users. You are insane to
write these things as argument for using ;.
You will always fail when I add more data to database. There always pattern
that will
E.g.?
Well you actually smart person out there. Please query for features that
support bitcoins or coins as currency
http://overpass-turbo.eu/?w=%22payment:coins%22=%22yes%22%20or%20%22payment:bitcoin%22=%22yes%22
Now try to query for only with bitcoin without litecoin tag:
payment:bitcoint=*
On 21.01.2015 03:59, Никита wrote:
You don't know regexes and theory behind them. [...] There always pattern
that will broke your regex.
E.g.?
You will never teach your ugly hacks to to OSM users.
Probably because these are for developers, not for users.
--
Friedrich K. Volkmann
If I had to guess, I would think that most people find the second
alternative much more complicated than the first one.
Oops, my bad; that's actually what I meant. I agree with you.
--
View this message in context:
route_ref=(^|.+;)26(;.+|$)
I haven't tested this, but usually you can safely remove the .+,
shortening it to route_ref=(^|;)26(;|$) i.e. start of string OR
semicolon, followed by 26, followed by end of string OR semicolon.
You can further shorten it to route_ref=26 if you don't need to make sure
Hi,
On 01/19/2015 11:03 AM, NopMap wrote:
On the other hand, just reverting them does not feel right to me either.
Some of the examples have their merit.
Revert the lot (which has been already done) and then step by step weave
in the examples that have merit, in a neutral language (i.e. not
I support the revert. The edits by Xxzme are in my opinion completely
unacceptable.
Best regards,
Martin
2015-01-19 11:03 GMT+01:00 NopMap ekkeh...@gmx.de:
There seems to be an edit war on the wiki page
http://wiki.openstreetmap.org/wiki/Avoid_semi-colon_value_separator
I personally think
There seems to be an edit war on the wiki page
http://wiki.openstreetmap.org/wiki/Avoid_semi-colon_value_separator
I personally think that the problem has been discussed many times and it is
well understood that semicolon lists only work for some special tags and
would generally be discarded as
I understand that the main tags of an object should avoid using semicolons to
make map renderer's life easier, but I don't think only exceptional tags
should use it and think most lists of values should be separated by
semicolon.
Particularly, I don't see how the example given in the page is
Hi!
2015-01-19 12:34 GMT+01:00 jgpacker john.pack...@gmail.com:
I.e. How is this:
amenity=library
library:stock=books;newspapers;recorded_music
better than this?:
amenity=library
library:stock:books=yes
library:stock:newspapers=yes
library:stock:recorded_music=yes
As a
96 matches
Mail list logo
