Well, I don't see a need to reinvent this tag anyway.
The key note=* is well-established as far as I'm aware.
If the editor interface isn't satisfactory, we should be talking with the
developers.
I'm not sure if it's possible, but placing the note closer to the top of
the presets seems like a
This tag already exists and has editor support (at least in iD) for a
considerable time.
It's called note=*.
Cheers,
João
--
View this message in context:
http://gis.19327.n5.nabble.com/README-tag-with-editor-support-tp5847911p5847943.html
Sent from the Tagging mailing list archive at
The problem with oneway is the key name - it's 3 letters too long:
How is this NOT trolling?
--
View this message in context:
http://gis.19327.n5.nabble.com/OSM-is-a-right-mess-was-Craigslist-OpenStreetMap-Rendering-Issue-tp5846860p5847385.html
Sent from the Tagging mailing list archive at
As one of the people that evaluated Loomio, I have to say that it actually
would be good enough for replacing the tagging mailing list with
considerable benefits*, with two caveats: (1) it's not too suitable for the
long ramblings and discussions (no paging) that are characteristic of the
tagging
I call people to review the wiki page Why OSM and not another collaborative
mapping service?.
link:
http://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service%3F
It was written by a single user as a generic page to compare other
collaborative mapping services to
I agree with Andreas that the current colour of defacto is misleading.
In fact, most current colours could be improved, and it would be a good idea
to turn off colour-coding until a consensus has been reached (since it
affects the whole goddamn wiki).
And please, let's not colour-code the whole
I don't know about this specific case, but if a key /by definition/ can be
used only in places where language X is spoken, then I think it would make
sense to have them in language X
I know at least one tag that works like that:
Hi,
I saw in the wiki page Key:smoothness
http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there
is a section about the controversy over it's verifiability.
As far as I remember, this tag was throughly discussed here until a
consensus was achieved (which was that it should
It may be a bit off-topic, but as I have expressed elsewhere, I think one of
the problems with the current voting process is the infrastructure.
I believe that using a mailing list plus wiki voting worked ok so far, but
needs to be updated.
Most young people probably don't even know what a
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
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
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
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
Hi,
Richard managed to explain to me in a private email after that email, but
thanks for the intention!
jgpacker wrote on 2015-01-21 15:56:
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
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
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
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
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
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, I saw that a user recently added a suggestion in the wikipage Key:source
http://wiki.openstreetmap.org/wiki/Key:source to add the date of the
source of the object in a separate tag called source:date=*.
Example:
source=survey
source:date=2014-08-15
Another example:
source:name=XYZ
22 matches
Mail list logo
