> Никита, 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
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
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
> 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 abo
My apologize for switching the discussion (so I change the title
accordingly) and also for slowly answering.
First, I was not aware of depth=* use recommendation with ford=yes
although it is in the wiki for years.
Let me back to Madagascar. We have:
- unpaved road crossing permanent river
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 Никита :
>> 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 th
> 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 word boundary (defined
on spaces, and other punct
How do you tag traffic_calming = table; choker in Russia ?
I'm willing to adapt my tagging, but how can I do this ? Both forms of
traffic calming are used at the same place sometimes, a table that is
smaller than the rest of the road.
Furthermore what about cuisine ? Do you use cuisine:japanse=ye
>
> I have one last case: some low profile bridge (without parapet) may be
> submerged after heavy rain but may be still usable if water depth above the
> bridge in not too high. How to tag this?
>
I was going to ask this - as most of the fords in Southern California are only
made for floodw
> 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 soft
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
> 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 s
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 ma
> 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.
Ne
On 19.01.2015 12:06, Paul Johnson wrote:
> This seems like a particularly strange edge case for the address scheme, but
> I'm curious if any of those valid addresses are consider the "primary?"
Usually the postal address which you give in your official documents is
considered the primary. But this
On 21 January 2015 at 13:17, Friedrich Volkmann wrote:
>> And
>> if that's the case, what's wrong with creating a node on the building for
>> each additional valid address? People looking for an amenity could look up
>> closest POIs after finding a secondary address. It's not a clean situation,
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 continues
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
On 21.01.2015 13:00, Andrew Shadura wrote:
>>> if that's the case, what's wrong with creating a node on the building for
>>> each additional valid address? People looking for an amenity could look up
>>> closest POIs after finding a secondary address. It's not a clean situation,
>>
>> It's a "bes
On 21 January 2015 at 02:16, Никита 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 the list's mode
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:
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830819.htm
> 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 key=
Thank you (Warin, fly, Andy) for the replies.
I know think that I have a basic understanding why *we* favor sidewalk=* over
footway=*.
Again, thank you all.
Hubert
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/l
On 19.01.2015 17:41, Clifford Snow wrote:
> If these are conscription numbers, why not use the addr:conscriptionnumber
> tag? It is document in the wiki [1] and appears to be in use. It would also
> appear more accurate and less likely to lead to misuse.
>
> [1] http://wiki.openstreetmap.org/wiki
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
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 t
> 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.
__
On Wed, Jan 21, 2015 at 11:55:19AM +0300, Никита wrote:
> > 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.
I'm sorry, I don't believe you are entitled to speak for the
> Message: 5
> Date: Tue, 20 Jan 2015 08:55:37 +0100
> From: Volker Schmidt
> To: "Tag discussion, strategy and related tools"
>
> Subject: Re: [Tagging] Tagging road illumination quality
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>So I will try, at least locally suc
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:0
Hendrik,
Great invention I would say, but not my problem here.
I would invent something like lit:level=automatic.
Volker
On 21 January 2015 at 15:50, St Niklaas wrote:
> > Message: 5
> > Date: Tue, 20 Jan 2015 08:55:37 +0100
> > From: Volker Schmidt
> > To: "Tag discussion, strategy and rela
>
> \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:
>
> Warin 61sundowner at gmail.com
> Sat Jan 17 21:27:13 UTC 2015
>
> Less work if intermittent is simply used without the frequency extension
> .. thus:
>
> intermittent=yes/no/winter/spring/summer/autum/seasonal/ephemeral (default
> assumption of "no")
>
> Note 'fall' = northern American engl
Hi,
Here is a picture of the situation.
https://wiki.openstreetmap.org/wiki/File:Special_motorroad_situation.jpg
Cheers
Tobias
Am 20.01.2015 um 15:05 schrieb Martin Vonwald:
> 2015-01-20 14:56 GMT+01:00 Martin Koppenhoefer :
>
>>
>> Am 20.01.2015 um 08:44 schrieb Martin Vonwald :
>>
>> 2015-01
> No! Flood prone means that they are expected to be flooded from time to
> time. Nothing about the design.
So you would have to tag also each wadi, each river and each lake
because this area is covered with water? Maybe the terms “designed”
and “expected” are missleading. But the question is: How
The practical use is that routing algorithms can calculate the travel time more
accurate if the durations are known. By specifying the via ways a routing
algorithm knows which signals can be ignored. Simulations can be done more
precisely.
To reply to the other comments:
I am aware of the pro
2015-01-21 18:08 GMT+01:00 715371 :
> Here is a picture of the situation.
>
> https://wiki.openstreetmap.org/wiki/File:Special_motorroad_situation.jpg
>
Interesting... and confusing ;-)
Is there any motorroad signpost before that part of the road? When looking
at the photo I'm tempted to say tha
Am 21.01.2015 um 19:41 schrieb Martin Vonwald:
> Is there any motorroad signpost before that part of the road?
No. The only existing sign on that link is that one on the picture.
There is no second on the right hand side, too.
If you mean the other direction: https://www.openstreetmap.org/way/20
Am 21.01.2015 um 00:03 schrieb Mariusz:
> Judging from Google Street photos (from 2008) all four lanes are motorrad.
> The sign 331.2 - end of motorrad - can be seen at about this location:
> http://www.openstreetmap.org/node/1968608980
> This would imply the way http://www.openstreetmap.org/way/31
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.
No that is what References (previous Message-IDs in the thread)
in the header are for, in your mail:
Messag
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.
No
On 01/19/2015 03:39 AM, Friedrich Volkmann wrote:
On 18.01.2015 22:23, Markus Lindholm wrote:
I think that comes down to how addresses are viewed, either as a
proper feature in their one right or as an attribute to some other
feature.
Yes, that's the crux.
I think addresses are proper featur
It seems like the German community started some voting process on the
deprecation of the associatedStreet-relation (it was on the mailing list
and on the forum).
Discussion is going on on the wiki
https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet
regards
m.
___
44 matches
Mail list logo
