Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> Никита, 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 insane
perl advocating. FIRST you teach users who use JOSM and ID who to use
regexes LATER we will listen to you.

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.


I don't really care if tagging pracites among English-speaking users so
undeveloped and pathetic. Actually I don't care if English speaking world
will not have tools to use data they enter.

http://wiki.openstreetmap.org/wiki/RU:Tag:shop%3Dticket

2015-01-21 10:53 GMT+03:00 David Bannon :

> On Wed, 2015-01-21 at 09:35 +0300, Никита wrote:
>
> > Well you actually smart person out there. Please query for features
> > that support bitcoins or coins as currency 
>
> Come on please ! This is getting quite silly.
>
> regexes are a basic part of the *nix and therefore internet world. Sure
> they are cryptic and hard to deal with by those who don't regularly use
> them but if we stopped regexe right now a lot more than OSM would stop
> working !
>
> Никита, you really need to accept regexe is a widely used technology and
> one you really are not going to stamp out.
>
> David
>
> >
> >
> > 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"=* and "payment:litecoin"!=*
> >
> >
> >
> > Now try to qurery only for features without regular coins:
> > ("payment:bitcoint"=* or "payment:litecoin"=*) and "payment:coint"!=*
> >
> >
> >
> > If really that dumb to answer questions above using regex, please
> > write an regex to filter email address from plain text.
> >
> >
> > > Probably because these are for developers, not for users.
> > Nonsense like any of your words.
> >
> >
> > How taginfo is for developers?
> > http://taginfo.openstreetmap.org/keys/payment%3Acoins#values
> >
> >
> >
> > How wiki page is for developers?
> >
> http://wiki.openstreetmap.org/w/index.php?title=Key:payment:coins&redirect=no
> >
> >
> > 2015-01-21 9:39 GMT+03:00 Friedrich Volkmann :
> > 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   http://www.volki.at/
> > Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Nadjita]

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 think, you should really calm down a bit and not sound so
aggressive, I have to agree with you. The purpose of structuring data is
not having to use a complicated, but a simple parser. 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.
The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
that it involves more typing. In fact, nobody forces us to only use yes
and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
and no. This can easily applied to a lot of values where it makes sense
and it gives the flexibility to distinguish between equal and
distinguished importance .
Using semicolon-lists for values was always considered a crutch until a
better tagging-scheme comes along.
We all know that the only real solution would be a native data type for
arrays in the database but as long as this isn't happening, we have to
work around.
But please let's not drag this down to a personal level and start
insulting each other, this isn't going to accomplish anything but anger.

- Nadjita

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Marc Gemis]

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 word boundary (defined
on spaces, and other punctuation), so you could search for "coin" without
finding "bitcoin". If this is not possible in JOSM, maybe it has to be
added.

regards

m

[1] http://docs.oracle.com/javase/tutorial/essential/regex/

On Wed, Jan 21, 2015 at 9:06 AM, Никита  wrote:

> > Никита, 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
> insane perl advocating. FIRST you teach users who use JOSM and ID who to
> use regexes LATER we will listen to you.
>
> 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.
>
>
> I don't really care if tagging pracites among English-speaking users so
> undeveloped and pathetic. Actually I don't care if English speaking world
> will not have tools to use data they enter.
>
> http://wiki.openstreetmap.org/wiki/RU:Tag:shop%3Dticket
>
> 2015-01-21 10:53 GMT+03:00 David Bannon :
>
>> On Wed, 2015-01-21 at 09:35 +0300, Никита wrote:
>>
>> > Well you actually smart person out there. Please query for features
>> > that support bitcoins or coins as currency 
>>
>> Come on please ! This is getting quite silly.
>>
>> regexes are a basic part of the *nix and therefore internet world. Sure
>> they are cryptic and hard to deal with by those who don't regularly use
>> them but if we stopped regexe right now a lot more than OSM would stop
>> working !
>>
>> Никита, you really need to accept regexe is a widely used technology and
>> one you really are not going to stamp out.
>>
>> David
>>
>> >
>> >
>> > 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"=* and "payment:litecoin"!=*
>> >
>> >
>> >
>> > Now try to qurery only for features without regular coins:
>> > ("payment:bitcoint"=* or "payment:litecoin"=*) and "payment:coint"!=*
>> >
>> >
>> >
>> > If really that dumb to answer questions above using regex, please
>> > write an regex to filter email address from plain text.
>> >
>> >
>> > > Probably because these are for developers, not for users.
>> > Nonsense like any of your words.
>> >
>> >
>> > How taginfo is for developers?
>> > http://taginfo.openstreetmap.org/keys/payment%3Acoins#values
>> >
>> >
>> >
>> > How wiki page is for developers?
>> >
>> http://wiki.openstreetmap.org/w/index.php?title=Key:payment:coins&redirect=no
>> >
>> >
>> > 2015-01-21 9:39 GMT+03:00 Friedrich Volkmann :
>> > 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   http://www.volki.at/
>> > Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>> >
>> >
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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 about data we map.
We document it instead of guessing by taginfo.
We use real tags instead of regexes for users.

We like our newbies. We don't want to insist to use f$#$g perl regexes
simply to map things around them.

I cannot stop you from using regex. But if I find your
changsets erroneous I will revert them.

> In fact, nobody forces us to only use yes and no as a value.
Wrong. It not forces you anything. You can still tag currency:X=fixme.

> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
easily applied to a lot of values where it makes sense and it gives the
flexibility to distinguish between equal and distinguished importance .
There way more tagging schemes than single Healthcare 2.0. Yes there
differences, so what?

> Using semicolon-lists for values was always considered a crutch until a better
tagging-scheme comes along.
You forgot to say "among English speaking users who fail to use JOSM search
funtion or overpass or taginfo or wiki documentation". I don't care about
them.

> We all know that the only real solution would be a native data type for arrays
in the database but as long as this isn't happening, we have to work around.
And obviously you choose the worst way to do this. With complicating things
with REGEX.


2015-01-21 11:42 GMT+03:00 Nadjita :

> 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 think, you should really calm down a bit and not sound so
> aggressive, I have to agree with you. The purpose of structuring data is
> not having to use a complicated, but a simple parser. 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.
> The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
> that it involves more typing. In fact, nobody forces us to only use yes
> and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
> and no. This can easily applied to a lot of values where it makes sense
> and it gives the flexibility to distinguish between equal and
> distinguished importance .
> Using semicolon-lists for values was always considered a crutch until a
> better tagging-scheme comes along.
> We all know that the only real solution would be a native data type for
> arrays in the database but as long as this isn't happening, we have to
> work around.
> But please let's not drag this down to a personal level and start
> insulting each other, this isn't going to accomplish anything but anger.
>
> - Nadjita
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Ford and other river crossing : (was : waterway=wadi problem)

[Eric Sibert]

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 without specific equipment
ford=yes
surface=unpaved
depth>0

- unpaved road crossing permanent river with specific equipment  
(usually made of concrete, "radier" in French, not sure on the correct  
term in English: raft???)

ford=yes
surface=paved/concrete
depth>0

- unpaved road crossing intermittent river without specific equipment
ford=yes
surface=unpaved
depth=0
May we use intermittent=yes/seasonal/flood/winter... to indicate  
period/frequency submersion?


- unpaved road crossing intermittent river with specific equipment
ford=yes
surface=paved/concrete
depth=0
intermittent?

- paved road crossing permanent river (of course with specific equipment)
ford=yes
surface=paved/concrete
depth>0

- paved road crossing intermittent river
ford=yes
surface=paved/concrete
depth=0
intermittent?

Do we have also to use flood_prone=yes or (ford=yes / depth=0) already  
imply that it is subject to flooding?


I don't like the wiki page on flood_prone. It is telling that the main  
difference between ford and flood_prone is the danger aspect. Indeed,  
looking at illustrations, especially at the third one, I just see a  
regular ford with depth scale and so on.


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?




Eric



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Dan S]

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 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 about data we map.
> We document it instead of guessing by taginfo.
> We use real tags instead of regexes for users.
>
> We like our newbies. We don't want to insist to use f$#$g perl regexes
> simply to map things around them.
>
> I cannot stop you from using regex. But if I find your changsets erroneous I
> will revert them.
>
>> In fact, nobody forces us to only use yes and no as a value.
> Wrong. It not forces you anything. You can still tag currency:X=fixme.
>
>> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
>> easily applied to a lot of values where it makes sense and it gives the
>> flexibility to distinguish between equal and distinguished importance .
> There way more tagging schemes than single Healthcare 2.0. Yes there
> differences, so what?
>
>> Using semicolon-lists for values was always considered a crutch until a
>> better tagging-scheme comes along.
> You forgot to say "among English speaking users who fail to use JOSM search
> funtion or overpass or taginfo or wiki documentation". I don't care about
> them.
>
>> We all know that the only real solution would be a native data type for
>> arrays in the database but as long as this isn't happening, we have to work
>> around.
> And obviously you choose the worst way to do this. With complicating things
> with REGEX.
>
>
> 2015-01-21 11:42 GMT+03:00 Nadjita :
>>
>> 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 think, you should really calm down a bit and not sound so
>> aggressive, I have to agree with you. The purpose of structuring data is
>> not having to use a complicated, but a simple parser. 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.
>> The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
>> that it involves more typing. In fact, nobody forces us to only use yes
>> and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
>> and no. This can easily applied to a lot of values where it makes sense
>> and it gives the flexibility to distinguish between equal and
>> distinguished importance .
>> Using semicolon-lists for values was always considered a crutch until a
>> better tagging-scheme comes along.
>> We all know that the only real solution would be a native data type for
>> arrays in the database but as long as this isn't happening, we have to
>> work around.
>> But please let's not drag this down to a personal level and start
>> insulting each other, this isn't going to accomplish anything but anger.
>>
>> - Nadjita
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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 punctuation), so you could search for "coin" without
finding "bitcoin". If this is not possible in JOSM, maybe it has to be
added.
My point is still the same. Java regexes are simpler, yes. They miss perl
recursion and other perl specific stuff. God bless java language developers
for doing this. But this is irrelevant to my points about wiki
documentation or about need to teach *any regex* to josm user or id user.

We don't use multiple values for many things:
http://wiki.openstreetmap.org/wiki/Names#Key_Variations
http://wiki.openstreetmap.org/wiki/Key:highway#Values
... just open taginfo or do postgres query to see actual numbers.

I have no idea why one would prefer semantickey=literal1;literal2;literal3
over *key:semanticsubtag=value*.

For the latter:
- you make simple queries even with overpassQL or josm search
- you can make presets in iD or JOSM with translations in native language
- you can make wiki page about it
- you can send this link page to newbie
- you can be sure about meaning of this value

Why is there need to guess liretal values instead of semantically tagging
using ":" in key. Russian community was doing this since 2010. Do English
wiki or users that behind us? Is there real reason to support ';"? I was
really surprised when my changes were simply reverted.

Actually not that bad:
http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
was
here since 2010.

> Now you're insulting the one person who was supporting you? Please
No I didn't. Quote them.

PS. Well I'm sorry for my tone if it was looking unacceptable in some
messages.

2015-01-21 12:00 GMT+03:00 Dan S :

> 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 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 about data we map.
> > We document it instead of guessing by taginfo.
> > We use real tags instead of regexes for users.
> >
> > We like our newbies. We don't want to insist to use f$#$g perl regexes
> > simply to map things around them.
> >
> > I cannot stop you from using regex. But if I find your changsets
> erroneous I
> > will revert them.
> >
> >> In fact, nobody forces us to only use yes and no as a value.
> > Wrong. It not forces you anything. You can still tag currency:X=fixme.
> >
> >> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
> >> easily applied to a lot of values where it makes sense and it gives the
> >> flexibility to distinguish between equal and distinguished importance .
> > There way more tagging schemes than single Healthcare 2.0. Yes there
> > differences, so what?
> >
> >> Using semicolon-lists for values was always considered a crutch until a
> >> better tagging-scheme comes along.
> > You forgot to say "among English speaking users who fail to use JOSM
> search
> > funtion or overpass or taginfo or wiki documentation". I don't care about
> > them.
> >
> >> We all know that the only real solution would be a native data type for
> >> arrays in the database but as long as this isn't happening, we have to
> work
> >> around.
> > And obviously you choose the worst way to do this. With complicating
> things
> > with REGEX.
> >
> >
> > 2015-01-21 11:42 GMT+03:00 Nadjita :
> >>
> >> 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 think, you should really calm down a bit and not sound so
> >> aggressive, I have to agree with you. The purpose of structuring data is
> >> not having to use a complicated, but a simple parser. 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.
> >> The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
> >> that it involves more typing. In fact, nobody forces us to only use yes
> >> and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
> >> and no. This can easily applied to a lot of values where it makes sense
> >> and it gives the flexibility to distinguish between equal and
> >> distinguished importance .
> >> Using semicolon-lists for values was always considered a crutch un

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Marc Gemis]

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=yes,
cuisine:chinese=yes ?

If you are using all those subkeys since 2010, why aren't they documented
in the wiki ? I only joined the project in 2011, but have never seen this
being documented for all those keys...

regards

m.

On Wed, Jan 21, 2015 at 10:23 AM, Никита  wrote:

> > 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 punctuation), so you could search for "coin" without
> finding "bitcoin". If this is not possible in JOSM, maybe it has to be
> added.
> My point is still the same. Java regexes are simpler, yes. They miss perl
> recursion and other perl specific stuff. God bless java language developers
> for doing this. But this is irrelevant to my points about wiki
> documentation or about need to teach *any regex* to josm user or id user.
>
> We don't use multiple values for many things:
> http://wiki.openstreetmap.org/wiki/Names#Key_Variations
> http://wiki.openstreetmap.org/wiki/Key:highway#Values
> ... just open taginfo or do postgres query to see actual numbers.
>
> I have no idea why one would prefer semantickey=literal1;literal2;literal3
> over *key:semanticsubtag=value*.
>
> For the latter:
> - you make simple queries even with overpassQL or josm search
> - you can make presets in iD or JOSM with translations in native language
> - you can make wiki page about it
> - you can send this link page to newbie
> - you can be sure about meaning of this value
>
> Why is there need to guess liretal values instead of semantically tagging
> using ":" in key. Russian community was doing this since 2010. Do English
> wiki or users that behind us? Is there real reason to support ';"? I was
> really surprised when my changes were simply reverted.
>
> Actually not that bad:
> http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
>  was
> here since 2010.
>
> > Now you're insulting the one person who was supporting you? Please
> No I didn't. Quote them.
>
> PS. Well I'm sorry for my tone if it was looking unacceptable in some
> messages.
>
> 2015-01-21 12:00 GMT+03:00 Dan S :
>
>> 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 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 about data we map.
>> > We document it instead of guessing by taginfo.
>> > We use real tags instead of regexes for users.
>> >
>> > We like our newbies. We don't want to insist to use f$#$g perl regexes
>> > simply to map things around them.
>> >
>> > I cannot stop you from using regex. But if I find your changsets
>> erroneous I
>> > will revert them.
>> >
>> >> In fact, nobody forces us to only use yes and no as a value.
>> > Wrong. It not forces you anything. You can still tag currency:X=fixme.
>> >
>> >> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
>> >> easily applied to a lot of values where it makes sense and it gives the
>> >> flexibility to distinguish between equal and distinguished importance .
>> > There way more tagging schemes than single Healthcare 2.0. Yes there
>> > differences, so what?
>> >
>> >> Using semicolon-lists for values was always considered a crutch until a
>> >> better tagging-scheme comes along.
>> > You forgot to say "among English speaking users who fail to use JOSM
>> search
>> > funtion or overpass or taginfo or wiki documentation". I don't care
>> about
>> > them.
>> >
>> >> We all know that the only real solution would be a native data type for
>> >> arrays in the database but as long as this isn't happening, we have to
>> work
>> >> around.
>> > And obviously you choose the worst way to do this. With complicating
>> things
>> > with REGEX.
>> >
>> >
>> > 2015-01-21 11:42 GMT+03:00 Nadjita :
>> >>
>> >> 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 think, you should really calm down a bit and not sound so
>> >> aggressive, I have to agree with

Re: [Tagging] Ford and other river crossing : (was : waterway=wadi problem)

[johnw]

> 
> 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 floodwaters, while the small stream goes under in a culvert - some of 
those are basically bridges, as the usual flow goes under, and the storm flow 
goes over.  I Too have seen some “submergible” bridges that become fords in 
flood times (usually heavily reinforced concrete things). I’d be interested in 
seeing what happens when bridge, ford and flood_prone combine. 

I wonder if there are enough of them to warrant their own bridge=*, as there 
are so many kinds of bridges. I bet we can put a ford tag on the bridge - it 
might be a simple solution. 

Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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 software or outdated tools?

We use this pattern for almost anything in OSM that has multiple keys or
values (different meanings actually "table"s "chocker"s):
http://wiki.openstreetmap.org/wiki/Key:disused
http://wiki.openstreetmap.org/wiki/Key:abandoned
http://wiki.openstreetmap.org/wiki/Key:source

Please see links above, they are in English. Also, fuel: key page was
created at 2010.

I think we should start using both tagging schemes right now:
cuisine=simplevalueforoldsoftware

*And actual tags for new software and presets*
cuisine:japanse=yes
cuisine:chinese=yes

This is absolutely not new. See disused, abandoned.

Over time we will deprecate simple tags cuisine=X and possibly shop=X.


2015-01-21 12:37 GMT+03:00 Marc Gemis :

> 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=yes,
> cuisine:chinese=yes ?
>
> If you are using all those subkeys since 2010, why aren't they documented
> in the wiki ? I only joined the project in 2011, but have never seen this
> being documented for all those keys...
>
> regards
>
> m.
>
> On Wed, Jan 21, 2015 at 10:23 AM, Никита  wrote:
>
>> > 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 punctuation), so you could search for "coin" without
>> finding "bitcoin". If this is not possible in JOSM, maybe it has to be
>> added.
>> My point is still the same. Java regexes are simpler, yes. They miss perl
>> recursion and other perl specific stuff. God bless java language developers
>> for doing this. But this is irrelevant to my points about wiki
>> documentation or about need to teach *any regex* to josm user or id user.
>>
>> We don't use multiple values for many things:
>> http://wiki.openstreetmap.org/wiki/Names#Key_Variations
>> http://wiki.openstreetmap.org/wiki/Key:highway#Values
>> ... just open taginfo or do postgres query to see actual numbers.
>>
>> I have no idea why one would prefer
>> semantickey=literal1;literal2;literal3 over *key:semanticsubtag=value*.
>>
>> For the latter:
>> - you make simple queries even with overpassQL or josm search
>> - you can make presets in iD or JOSM with translations in native language
>> - you can make wiki page about it
>> - you can send this link page to newbie
>> - you can be sure about meaning of this value
>>
>> Why is there need to guess liretal values instead of semantically tagging
>> using ":" in key. Russian community was doing this since 2010. Do English
>> wiki or users that behind us? Is there real reason to support ';"? I was
>> really surprised when my changes were simply reverted.
>>
>> Actually not that bad:
>> http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
>>  was
>> here since 2010.
>>
>> > Now you're insulting the one person who was supporting you? Please
>> No I didn't. Quote them.
>>
>> PS. Well I'm sorry for my tone if it was looking unacceptable in some
>> messages.
>>
>> 2015-01-21 12:00 GMT+03:00 Dan S :
>>
>>> 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 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 about data we map.
>>> > We document it instead of guessing by taginfo.
>>> > We use real tags instead of regexes for users.
>>> >
>>> > We like our newbies. We don't want to insist to use f$#$g perl regexes
>>> > simply to map things around them.
>>> >
>>> > I cannot stop you from using regex. But if I find your changsets
>>> erroneous I
>>> > will revert them.
>>> >
>>> >> In fact, nobody forces us to only use yes and no as a value.
>>> > Wrong. It not forces you anything. You can still tag currency:X=fixme.
>>> >
>>> >> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
>>> >> easily applied to a lot of values where it makes sense and it gives
>>> the
>>> >> flexibility to distinguish between equal and distinguished importance
>>> .
>>> > There way more tagging schem

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Jo]

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 system is
better designed than what we started out with.

Just to add to the discussion that binary keys for all possible options are
apparently not always the solution either.

In any case, it's not impossible to work with ; delimited lists, but it's
enough if we try to limit their use. Just don't try to eradicate them, they
do have their use.

I wouldn't want to have to add:

route_ref:318=yes
route_ref:616=yes


or

route_ref:BE:De_Lijn:1=yes
route_ref:BE:De_Lijn:2=yes
...
instead of this:

route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597

Polyglot

2015-01-21 11:08 GMT+01:00 Никита :

> > 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 software or outdated tools?
>
> We use this pattern for almost anything in OSM that has multiple keys or
> values (different meanings actually "table"s "chocker"s):
> http://wiki.openstreetmap.org/wiki/Key:disused
> http://wiki.openstreetmap.org/wiki/Key:abandoned
> http://wiki.openstreetmap.org/wiki/Key:source
>
> Please see links above, they are in English. Also, fuel: key page was
> created at 2010.
>
> I think we should start using both tagging schemes right now:
> cuisine=simplevalueforoldsoftware
>
> *And actual tags for new software and presets*
> cuisine:japanse=yes
> cuisine:chinese=yes
>
> This is absolutely not new. See disused, abandoned.
>
> Over time we will deprecate simple tags cuisine=X and possibly shop=X.
>
>
> 2015-01-21 12:37 GMT+03:00 Marc Gemis :
>
>> 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=yes,
>> cuisine:chinese=yes ?
>>
>> If you are using all those subkeys since 2010, why aren't they documented
>> in the wiki ? I only joined the project in 2011, but have never seen this
>> being documented for all those keys...
>>
>> regards
>>
>> m.
>>
>> On Wed, Jan 21, 2015 at 10:23 AM, Никита  wrote:
>>
>>> > 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 punctuation), so you could search for "coin"
>>> without finding "bitcoin". If this is not possible in JOSM, maybe it has to
>>> be added.
>>> My point is still the same. Java regexes are simpler, yes. They miss
>>> perl recursion and other perl specific stuff. God bless java language
>>> developers for doing this. But this is irrelevant to my points about wiki
>>> documentation or about need to teach *any regex* to josm user or id
>>> user.
>>>
>>> We don't use multiple values for many things:
>>> http://wiki.openstreetmap.org/wiki/Names#Key_Variations
>>> http://wiki.openstreetmap.org/wiki/Key:highway#Values
>>> ... just open taginfo or do postgres query to see actual numbers.
>>>
>>> I have no idea why one would prefer
>>> semantickey=literal1;literal2;literal3 over *key:semanticsubtag=value*.
>>>
>>> For the latter:
>>> - you make simple queries even with overpassQL or josm search
>>> - you can make presets in iD or JOSM with translations in native language
>>> - you can make wiki page about it
>>> - you can send this link page to newbie
>>> - you can be sure about meaning of this value
>>>
>>> Why is there need to guess liretal values instead of semantically
>>> tagging using ":" in key. Russian community was doing this since 2010. Do
>>> English wiki or users that behind us? Is there real reason to support ';"?
>>> I was really surprised when my changes were simply reverted.
>>>
>>> Actually not that bad:
>>> http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
>>>  was
>>> here since 2010.
>>>
>>> > Now you're insulting the one person who was supporting you? Please
>>> No I didn't. Quote them.
>>>
>>> PS. Well I'm sorry for my tone if it was looking unacceptable in some
>>> messages.
>>>
>>> 2015-01-21 12:00 GMT+03:00 Dan S :
>>>
 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 

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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 software. We should work on documentation for
more user friendly tools (
http://wiki.openstreetmap.org/wiki/Osmosis/Writing_Plugins)

If you know structure your information, there nothing complex for you. In
most situations you say when some old tag should be replaced with newer
version. But I do agree conversion software support may be not the ATM or
poorly documented.

> route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;
333;334;335;337;351;352;358;370;371;372;373;374;380;395;
520;524;525;537;586;597
It is possible to get sting

route_ref:De_Lijn=8;9;284

from keys in database


*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, for now tag with short key
and multuple namespaced tags may duplicate each other. But you will also
benefit from this. As I said previously, you can use queries like this:

*"route_ref:De_Lijn:284"="yes" and "**route_ref:De_Lijn:10"!=** — this
query will capture missing 10 and present 284. You will spend hours for
learning regexes for yourself and teaching other users how to use regex.

Now, after you realized "10" was missing, you have to enter this value at
correct position in "1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;
333;334;335;337;351;352;358;370;371;372;373;374;380;395;
520;524;525;537;586;597".

You have sorted values already. But you dont need sorting to paste new
tag *"route_ref:De_Lijn:10"="yes".
JOSM may sort or even hide tags for you, don't do computer job.*

Also you get benefits from taginfo if your keys *route_ref:De_Lijn: *are
popular, you can redirect taginfo users to wiki page about your project or
tagging scheme.

Back to your problem. After tags are in database, you may develop universal
plugin for JOSM that will do very simple thing:

for defined set of tags (*route_ref:De_Lijn:, fuel:, cruisine: *and others)
it will glue their values together only for you. You may edit them as
usual, but after it should somehow (it will be less tricky than everyone
learn regex and ;; escaping) convert this string to the original keys.

Does this make sense for you? Will you adapt this approach?


2015-01-21 13:42 GMT+03:00 Jo :

> 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 system is
> better designed than what we started out with.
>
> Just to add to the discussion that binary keys for all possible options
> are apparently not always the solution either.
>
> In any case, it's not impossible to work with ; delimited lists, but it's
> enough if we try to limit their use. Just don't try to eradicate them, they
> do have their use.
>
> I wouldn't want to have to add:
>
> route_ref:318=yes
> route_ref:616=yes
>
>
> or
>
> route_ref:BE:De_Lijn:1=yes
> route_ref:BE:De_Lijn:2=yes
> ...
> instead of this:
>
>
> route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597
>
> Polyglot
>
> 2015-01-21 11:08 GMT+01:00 Никита :
>
>> > 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 software or outdated tools?
>>
>> We use this pattern for almost anything in OSM that has multiple keys or
>> values (different meanings actually "table"s "chocker"s):
>> http://wiki.openstreetmap.org/wiki/Key:disused
>> http://wiki.openstreetmap.org/wiki/Key:abandoned
>> http://wiki.openstreetmap.org/wiki/Key:source
>>
>> Please see links above, they are in English. Also, fuel: key page was
>> created at 2010.
>>
>> I think we should start using both tagging schemes right now:
>> cuisine=simplevalueforoldsoftware
>>
>> *And actual tags for new software and presets*
>> cuisine:japanse=yes
>> cuisine:chinese=yes
>>
>> This is absolutely not new. See disused, abandoned.
>>
>> Over time we will deprecate simple tags cuisine=X and possibly shop=X.
>>
>>
>> 2015-01-21 12:37 GMT+03:00 Marc Gemis :
>>
>>> 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=yes,
>>> cuisine:chine

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[jgpacker]

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 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 software or outdated tools?
>
> We use this pattern for almost anything in OSM that has multiple keys or
> values (different meanings actually "table"s "chocker"s):
> http://wiki.openstreetmap.org/wiki/Key:disused
> http://wiki.openstreetmap.org/wiki/Key:abandoned
> http://wiki.openstreetmap.org/wiki/Key:source
>
> Please see links above, they are in English. Also, fuel: key page was
> created at 2010.
>
> I think we should start using both tagging schemes right now:
> cuisine=simplevalueforoldsoftware
>
> *And actual tags for new software and presets*
> cuisine:japanse=yes
> cuisine:chinese=yes
>
> This is absolutely not new. See disused, abandoned.
>
> Over time we will deprecate simple tags cuisine=X and possibly shop=X.
>
>
> 2015-01-21 12:37 GMT+03:00 Marc Gemis <[hidden email]
> >:
>
>> 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=yes,
>> cuisine:chinese=yes ?
>>
>> If you are using all those subkeys since 2010, why aren't they documented
>> in the wiki ? I only joined the project in 2011, but have never seen this
>> being documented for all those keys...
>>
>> regards
>>
>> m.
>>
>> On Wed, Jan 21, 2015 at 10:23 AM, Никита <[hidden email]
>> > wrote:
>>
>>> > 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 punctuation), so you could search for "coin"
>>> without finding "bitcoin". If this is not possible in JOSM, maybe it has to
>>> be added.
>>> My point is still the same. Java regexes are simpler, yes. They miss
>>> perl recursion and other perl specific stuff. God bless java language
>>> developers for doing this. But this is irrelevant to my points about wiki
>>> documentation or about need to teach *any regex* to josm user or id
>>> user.
>>>
>>> We don't use multiple values for many things:
>>> http://wiki.openstreetmap.org/wiki/Names#Key_Variations
>>> http://wiki.openstreetmap.org/wiki/Key:highway#Values
>>> ... just open taginfo or do postgres query to see actual numbers.
>>>
>>> I have no idea why one would prefer
>>> semantickey=literal1;literal2;literal3 over *key:semanticsubtag=value*.
>>>
>>> For the latter:
>>> - you make simple queries even with overpassQL or josm search
>>> - you can make presets in iD or JOSM with translations in native language
>>> - you can make wiki page about it
>>> - you can send this link page to newbie
>>> - you can be sure about meaning of this value
>>>
>>> Why is there need to guess liretal values instead of semantically
>>> tagging using ":" in key. Russian community was doing this since 2010. Do
>>> English wiki or users that behind us? Is there real reason to support ';"?
>>> I was really surprised when my changes were simply reverted.
>>>
>>> Actually not that bad:
>>> http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
>>>  was
>>> here since 2010.
>>>
>>> > Now you're insulting the one person who was supporting you? Please
>>> No I didn't. Quote them.
>>>
>>> PS. Well I'm sorry for my tone if it was looking unacceptable in some
>>> messages.
>>>
>>> 2015-01-21 12:00 GMT+03:00 Dan S <[hidden email]
>>> >:
>>>
 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 Никита <[hidden email]
 >:
 >> 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 about data we map.
 > We document it instead of guessing by taginfo.
 > We use real tags instead of regexes for users.
 >
 > We like our newbie

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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 day I will add ref="3;10;13;113;133;13E" — will you update your query?

My query will always correct:
"ref"="13"

No matter how many 113 or 13A or 13/1 or 13-1 you may want to add.

OSM is not about writing regexes, it is about defining meaining in
key=values and documenting them at wiki. We did this way before 2010.

Our current tools (JOSM, overpass, taginfo, osmosis, iD, presets in JOSM
and iD, any other sane tool) and documentation (wiki) are key-sentric, not-
*something-in-the-middle-of-value*-centric

2015-01-21 14:38 GMT+03:00 jgpacker :

> 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] <[hidden email]
> >:
>
>> > 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 software or outdated tools?
>>
>> We use this pattern for almost anything in OSM that has multiple keys or
>> values (different meanings actually "table"s "chocker"s):
>> http://wiki.openstreetmap.org/wiki/Key:disused
>> http://wiki.openstreetmap.org/wiki/Key:abandoned
>> http://wiki.openstreetmap.org/wiki/Key:source
>>
>> Please see links above, they are in English. Also, fuel: key page was
>> created at 2010.
>>
>> I think we should start using both tagging schemes right now:
>> cuisine=simplevalueforoldsoftware
>>
>> *And actual tags for new software and presets*
>> cuisine:japanse=yes
>> cuisine:chinese=yes
>>
>> This is absolutely not new. See disused, abandoned.
>>
>> Over time we will deprecate simple tags cuisine=X and possibly shop=X.
>>
>>
>> 2015-01-21 12:37 GMT+03:00 Marc Gemis <[hidden email]
>> >:
>>
>>> 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=yes,
>>> cuisine:chinese=yes ?
>>>
>>> If you are using all those subkeys since 2010, why aren't they
>>> documented in the wiki ? I only joined the project in 2011, but have never
>>> seen this being documented for all those keys...
>>>
>>> regards
>>>
>>> m.
>>>
>>> On Wed, Jan 21, 2015 at 10:23 AM, Никита <[hidden email]
>>> > wrote:
>>>
 > 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 punctuation), so you could search for "coin"
 without finding "bitcoin". If this is not possible in JOSM, maybe it has to
 be added.
 My point is still the same. Java regexes are simpler, yes. They miss
 perl recursion and other perl specific stuff. God bless java language
 developers for doing this. But this is irrelevant to my points about wiki
 documentation or about need to teach *any regex* to josm user or id
 user.

 We don't use multiple values for many things:
 http://wiki.openstreetmap.org/wiki/Names#Key_Variations
 http://wiki.openstreetmap.org/wiki/Key:highway#Values
 ... just open taginfo or do postgres query to see actual numbers.

 I have no idea why one would prefer
 semantickey=literal1;literal2;literal3 over *key:semanticsubtag=value*.

 For the latter:
 - you make simple queries even with overpassQL or josm search
 - you can make presets in iD or JOSM with translations in native
 language
 - you can make wiki page about it
 - you can send this link page to newbie
 - you can be sure about meaning of this value

 Why is there need to guess liretal values instead of semantically
 tagging using ":" in key. Russian community was doing this since 2010. Do
 English wiki or users that behind us? Is there real reason to support ';"?
 I was really surprised when my changes were simply reverted.

 Actually not that bad:
 http://wiki.openstreetmap.org/w/index.php?title=Key:fuel&direction=next&oldid=400799
  was
 here since 2010.

 > Now you're insulting the one person who was supporting you? 

Re: [Tagging] AddrN

[Friedrich Volkmann]

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 address may not be suitable for other uses.
E.g. I live in an apartment complex that extends over 2 building blocks:
http://www.openstreetmap.org/relation/1060497
The postal address is Davidgasse 76-80, staircase (addr:unit) 14. My windows
are heading to the Buchengasse. The Davidgasse is not even adjacent to the
whole block. So nobody finds to me when I tell them my postal address. I
need to tell them I live in Gußriegelstraße 5, because that's the location
of the building passage that leads to the correct corner of the courtyard.
The chimney sweep uses Buchengasse 151 though, because that's the street
where my apartment (and the chimney) is located.

So I'd say that Davidgasse 76-80 is the primary address (addr:*),
Gußriegelstraße 5 the secondary address (addr2:*), and Buchengasse 151 the
tertiary address (addr3:*).
Malborghetgasse 6 (addr4:*) and Rotenhofgasse 86-88 (addr5:*) are also
equivalent, but are never actually used for my side of the building.

> 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,

It's a "best guess" approach, delivering lots of false positives, because
the scope of address nodes is undefined. The address may be valid for the
whole building, or only part of the building, or even for multiple buildings
(take my postal address as an example).

> but it does have a couple advantages:
> 
>   * Works with existing data consumers

That's fine, but if that were a criterion, OSM wouldn't exist. I think that
addresses are important enough to justify extensions of applications.

>   * Simple for users to tag.

addr2 is simple too. It's just one more character. And you don't need to
create additional nodes, let alone relations as suggested somewhere in this
discussion.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] AddrN

[Andrew Shadura]

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,
>
> It's a "best guess" approach, delivering lots of false positives, because
> the scope of address nodes is undefined. The address may be valid for the
> whole building, or only part of the building, or even for multiple buildings
> (take my postal address as an example).

But that's not precisely true. The scope of an address node inside a
building outline is this building. If you want to specify an address
for a part of a building only, just split that building.

-- 
Cheers,
  Andrew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Fairhurst]

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 in this
vein I will use them.

Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830806.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Frederik Ramm]

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 "key"
space. While we allow arbitrary keys, we still want them to be keys, not
a mixture of keys and values. We don't want "name:Main Street=yes".

No matter what one thinks about semicolon lists, the above is clearly worse.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] AddrN

[Friedrich Volkmann]

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 "best guess" approach, delivering lots of false positives, because
>> the scope of address nodes is undefined. The address may be valid for the
>> whole building, or only part of the building, or even for multiple buildings
>> (take my postal address as an example).
> 
> But that's not precisely true. The scope of an address node inside a
> building outline is this building. If you want to specify an address
> for a part of a building only, just split that building.

That's a well-meant advice, but a big portion of buildings in the database
are not split. That's because mappers walking to the street writing down
housenumbers do not measure building lengths, or the seam between two
buildings parts may not even be visible from the outside. You often cannot
see it on arial images either. OGD may help, but many buildings were mapped
before OGD became available for the respective regions.

Moreover, I am not aware of any wiki page stating that the scope of an
address node is the whole building.

The approach comparing address nodes to building outlines may be perfect in
theory, but you'll always get tons of false positives with real data.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Andy Mabbett]

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 moderators reading?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Fairhurst]

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.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> 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=*part-of-value-withown-meaining1;*
*part-of-value-withown-meaining2;part-of-value-withown-meaining3;*
*part-of-value-withown-meaining4* into separate keys
key:semanticsubkey1=yes
key:semanticsubkey2=yes
key:semanticsubkey3=yes
key:semanticsubkey4=yes

and not
key:value=yes — this is horrible and impossible to query similar to
multivalued keys
key=parsemevalue1;parsemevalue2;parsemevalue3 — this is also impossible to
query (realistically, not with regexes)

But it also wrong if you remove all flexibility of multiple keys under
really-log-unusable-value simply because "we have relations for that
realson". Relations are fine, but keys are easier to understand for newbies
and query. Instead of regexes you have to learn about querying only for
relations, querying only for members with specific roles. This is donable,
but this takes time.

This is imporlant. *Roles are not accessible by our documentation or tools*.
We cannot use this in presets or localize strings for it. There no
difference in documentation for building=yes if it is with role 'inner' or
'address'.

Users should decide when to really use ';'. But we should discourage them
from using it everywhere. It was proposal multiple times by many users
already:

http://wiki.openstreetmap.org/w/index.php?title=Key:abandoned&diff=next&oldid=878767
http://wiki.openstreetmap.org/w/index.php?title=Key:disused&diff=next&oldid=862845
http://wiki.openstreetmap.org/w/index.php?title=Semi-colon_value_separator&diff=prev&oldid=1113856
https://wiki.openstreetmap.org/w/index.php?title=Key:is_in&diff=prev&oldid=67210#Problems_of_accuracy

Again, see millionshighways with only 1 value
http://taginfo.openstreetmap.org/keys/highway#values
Many name tags with only 1 value
http://taginfo.openstreetmap.org/search?q=name

Actually there very-very few examples where this can make sense:
ref=3;4 — reference roads with same meaning. There way more reference
systems than you may think
http://wiki.openstreetmap.org/w/index.php?title=Key:ref&oldid=1129065
opening_hours — this is very specific key you have to process/parse its
value each time, you can query "opening_hours"="24/7", but this tag is more
complex than "simple tag to tag 24/7 feature"
lanes — used to indicate lanes, with specific order, left-to-right
http://taginfo.openstreetmap.org/search?q=lanes

Can somebody continue this list of exceptions?

2015-01-21 15:23 GMT+03:00 Frederik Ramm :

> 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 "key"
> space. While we allow arbitrary keys, we still want them to be keys, not
> a mixture of keys and values. We don't want "name:Main Street=yes".
>
> No matter what one thinks about semicolon lists, the above is clearly
> worse.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sidewalk=* or footway=*

[Hubert]

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/listinfo/tagging

Re: [Tagging] AddrN

[Friedrich Volkmann]

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/Key%3Aaddr%3Aconscriptionnumber

Sadly, that wiki page is not referenced where it should. Particularly,
there's no mention of addr:conscriptionnumber on
http://wiki.openstreetmap.org/wiki/Key:addr. That's the reason why we do not
use addr:conscriptionnumber in Austria.

One further reason may be that we find it difficult sometimes to distinguish
housenumbers and conscriptionnumbers. Actually, we use housenumber
(Hausnummer) as the hypernym for orientation number (Orientierungsnummer)
and conscription number (Konskriptionsnummer). The orientation number is the
number to be used in conjuntion with a street name. However, the street name
is omitted on many housenumber plates, so you won't know for sure if it's an
orientation number or a conscription number when you are just passing by.
You need to look for name signs on the nearby streets. But sometimes you'll
find a settlement name on them, leaving you in doubt. As a consequence,
addr:street, addr:hamlet and addr:place are used almost interchangably in
many rural settlements.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Fairhurst]

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




--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830833.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[jgpacker]

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 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 ~ "(;|^)13(;|$)" 

which can be read as: either semicolon or the start of the value, followed
by 13, followed by either semicolon or the end of the value.
I would recommend to also allow a space before 13 (because people sometimes
like to add an extra space after the semicolon), making it:

ref ~ "(;|^| )13(;|$)" 


Note: For technical reasons, if you need to use a word boundary in Overpass
QL, use \\b (you need to escape the backslash character). This is not the
case in Overpass XML.

PS: I don't know Perl and don't want to learn it. Regular expression is a
common feature in mature programming languages.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830838.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Marc Gemis]

> 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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Ineiev]

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 whole
Russian comunity. in fact, you have the same communication issues
with Russian mappers as with this mailing list.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Contents of Tagging Digest, Vol 64, Issue 84, 5 tagging allumination quality

[St Niklaas]

> 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 such
> an approach. And in order not to upset things I will use the
> lit=yes
> lit:level=poor|sufficient|good

Volker how to tag a intermitting / dimable 'lit' with led lights, its level 
goes up when you approach and goes down if you proceed afterwards.
Hendrik
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Mann]

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[jgpacker]

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 Richard Mann-2 [via GIS] <
ml-node+s19327n5830843...@n5.nabble.com>:

> Click on the dots, ctrl-a, delete. It's a lot easier than regex.
>
> ___
> Tagging mailing list
> [hidden email] 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830843.html
>  To unsubscribe from Wiki Edit War on using/avoiding semicolon lists, click
> here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830846.html
Sent from the Tagging mailing list archive at Nabble.com.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Contents of Tagging Digest, Vol 64, Issue 84, 5 tagging allumination quality

[Volker Schmidt]

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 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 such
> > an approach. And in order not to upset things I will use the
> > lit=yes
> > lit:level=poor|sufficient|good
>
> Volker how to tag a intermitting / dimable 'lit' with led lights, its
> level goes up when you approach and goes down if you proceed afterwards.
> Hendrik
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

>
> \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 ~ "(;|^)13(;|$)"


Well I don't to discuss regexes actually. I learn nothing from your words.
It will not help newbies at all. There lot of complexity in OSM already,
starting from GPS collection to complicated tags and their poor
documentation at wiki. I see no reason to complicate things with
introducing any king of regex. Regular mappers get nothing from regex you
wrote. Dollar means currency is USA, nothing else. "1;2;4;5;6;7;8" - just
find missing "3" here, with any regex. I will not continue discussion about
it with you actually.

Regexes miss set logic, regex miss default and missing values. As you
mentioned they require processing power. It will eat all of your cpu. If
you don't trust me just ask any DB admin is it good idea to query values in
database using regexes.

I'm sorry, I don't believe you are entitled to speak for the whole
> Russian comunity. in fact, you have the same communication issues
> with Russian mappers as with this mailing list.

Ad hominem. So what? I speak only for myself and my observations. If you
cannot follow links I were mentioning thats not my fault. How this is
relevant to tagging guideline at all?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] waterway=wadi problem

[Tod Fitch]

> 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 english, 'autum' for english english ?
> 
> Comments: An intermittent=winter may not flow every winter .. but it is 
> 'expected' to flow in winter. This year the 'Todd River' flowed in central 
> Australia, usually there is no folw, might flow evrey 5? years. As such it is 
> 'ephemeral'. As it is called a 'River' by the locals and on maps and by the 
> government so it is tagged in OSM. I looked at wadi ... but it does not match 
> my understanding nor local use.
> 

There is continuing discussion regarding fords of intermittent waterways, but 
my feeling was a consensus was reached with respect to extending intermittent 
to:

intermittent=yes/no/winter/spring/summer/autumn/seasonal/ephemeral (default 
assumption of "no")

To that end, I've edited the talk page for the intermittent tag at 
https://wiki.openstreetmap.org/wiki/Talk:Key:intermittent

What would be the next step in working toward getting the actual wiki page for 
the intermittent tag updated without stepping on too many toes.

I see that RicoZ has already made a change to the wiki page for waterway=wadi 
tagging that seem to be a result of this same tagging email thread.

Thanks!
Tod___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Motorroad does not apply to all lanes

[715371]

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-20 3:36 GMT+01:00 715371 :
>>
>>> motorroad:lanes=yes|yes|yes|no
>>>
>>>
>> Seems absolutely fine to me. One alternative (for better compatibility)
>> would be motorroad=yes + motorroad:lanes=yes|yes|yes|no
>>
>> this sounds strange to me, a motor road according to German law (and word)
>> is referring to a road, not to a lane, so there shouldn't be roads with
>> lanes of which some are motor roads and others aren't, it is more probable
>> that the whole motor road gets interrupted by the bridge (to allow crossing
>> by all vehicles) and restarts after it.
>>
> 
> My response was solely to the tagging itself. If the original observation
> is wrong, that's a completely different story ;-)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=wadi problem

[Lukas Sommer]

> 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 can we
distinguish between “normal water” and “flood water”.

I think rivers – also intermittent rivers – belong to the first
category. Also fords belong to the first category, because the
defination of the ford is that here you cross water (and the water can
be intermittent or not). This does no harm, thought it is quite
“normal”.

However, other objects like the house you are living in probably you
do not want to be filled with water. If it is filled with water, this
will not be a normal-life situation for you. If your house is for
example in the nice city of Cologne (Germany) near the river “Rhein”,
than perhaps at least a part of your house will be filled with water
one time each year. So your house can be filled with water in a very
regular way, nevertheless this is not nice for you. Your house belongs
to the second category.

I think the key flood_prone should be applied only for the second
category. The wiki page of the flood_prone key is not really clear.
But texts like

> Flooded roadways are often very dangerous to cross and many people die each 
> year as a result.

on the wiki page suggest the same thing. It’s not about the normal
ford, where you know that there maybe you have to cross water and that
normally you can do so without a big danger. It’s about the not-normal
situations.

> as this may help routing software to avoid potentially hazardous crossings if 
> there has been heavy rain.

This seems to be the original idea of the tag. And it’s useful. In
most western coutries, a heavy rain isn’t a big problem – there are
well-working sewerage systems. But I assure you that there are other
parts of the world where this is different. If you are living in
Abidjan (Ivory Coast) and you want to travel during the rainy season
during a rainfall than you know that there are many roads that are
impassable: Maybe 20% of the paved routes can’t be used because the
water reachs 1 or 2 meters. (But most roads are unpaved. And unpaved
roads are evern worser when it’s raining ;-)

> I'd hope that the flood_prone tag would be
> applied to an area

I think both tagging – on areas an on highways – can be useful. Both
tagging are also present in the database.

> and best if the frequency is noted e.g. once every 100
> years.

Agree. (Though – every 100 years is a very risky description. At
places where floods occure more often – for example once a year –
predictions tend to be more reliable.)

> Again no. A ford may be continuously under water. E.G. a road that goes
> through a river .. where the river normally flows across the top of the
> road.  Some fords may only have water in floods, others seasonally, and
> others continuously.

That is what I said ;-)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Lukas Schaus]

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 problem of dynamic timings. Nevertheless it is important to 
have a rough idea how these traffic signals are timed. The suggestions of 
Nakaner to tag the timings with fractions like green=40/120, indicating that 
the signal is 40 of 120 seconds green seems like a good compromise between 
complexity and loss of information. To increase the information a use of 
conditional fraction timings for different times at a day also seems to be a 
reasonable optional tool. I think the connection between more intersection is 
to complex to model and can be guessed of the simulation and routing 
applications. To know the exact via ways is a crucial feature for routing and 
simulation tasks. Relations seem to be a good way to model them. Also it seems 
to be more easy to tag on all relations which include certain nodes than to tag 
the information in the single nodes. Why do you think that it is better not to 
use relations?

I’d like you to use the discussion page for a better readability

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals 



> I'm going to have to agree with this.  What's the practical purpose of this
> schema?  I the only thing I can come up with would be to recreate the
> system for a driving game of some realistic fashion, however, that seems to
> be more of something the game designer would need to implement on their own
> rather than expecting some overly baroque tagging model in a third-party
> database (ie, OSM) to sort out for them.  The GPS navigation model doesn't
> really bring up a solid case for this, either (with the exception of turn
> lanes that prohibit turn on red and have their own signals, in which
> there's bound to be a simpler way to indicate the presence of left or right
> turn signals and whether or not they allow turn on red to give navigation
> systems finer grain control over cost assignment, ie, in the pacific
> northwest US model, a right turn would have the same penalty as a two-way
> stop, as would a left turn to a one-way street (since you can make a left
> on red arrow if it's to a one-way street in that part of the world, even
> from a two way), but all other left turns involving a left turn signal
> would "cost" more).
> 
> I guess we're going to need a better idea of what this is trying to solve
> beyond just mapping for the sake of detail overkill (which I have nothing
> against, but let's not make things overly complex just for the sake of
> this).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Motorroad does not apply to all lanes

[Martin Vonwald]

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 that the left lane is a motorroad and the
right one isn't, although I doubt that I would be brave enough to tag it
that way.

Best regards,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Motorroad does not apply to all lanes

[715371]

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/203752771

It is a motorroad, but has a sidewalk.

But trunk nevertheless, I think, because it does not have any crossings.

I think to tag motorroad=yes/no would be wrong. Both does not apply to
all lanes. If you tag yes, you gonna have to add bicycle=yes,
moped=yes,... due to the single non-motorroad-lane (sidewalk does imply
foot=yes/designated).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Motorroad does not apply to all lanes

[715371]

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/318383860 is
> motorrad, and hence the bridge too.

Good clue.

But since this is (one of) the first possibilities to put a sign to end
the motorroad, this maybe meaningless.

Just imagine the situation was true, that there is a single lane which
is not motorroad, then why shouldn't you put a sign, which is applied to
all lanes?

> By the way, at this entry to motorrad from Daniel-von-Büren-Straße
> http://www.openstreetmap.org/node/3247878878
> the sign 331.1 - begining of motorrad - is visible at left side. It
> should be applied to whole road, not only to the left lane.

Well, I think the German law might not be that straight at those
situations. I am not a lawyer, but at the StVO it reads like: Regularly
the signs are at the right hand side of the road and if they just apply
to single lanes, they are above those lanes (see StVO §39 (2)).

Well, this sentence sounds like bullshit to me (maybe somebody can tell
me what is regelmäßig means). However - the best I knew.

References:
http://www.gesetze-im-internet.de/stvo_2013/__39.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mail Threading / was: Wiki Edit War ...

[Tom Pfeifer]

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:

Message-ID: 
In-Reply-To: 

References: 
 
 
 
 
 
 
 <1421848908482-5830833.p...@n5.nabble.com>
 
 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mail Threading / was: Wiki Edit War ...

[jgpacker]

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 that is what References (previous Message-IDs in the thread)
in the header are for, in your mail:

Message-ID: http:///user/SendEmail.jtp?type=node&node=5830884&i=0>>
In-Reply-To: <[hidden email]
>
References: <[hidden email]
>
  <[hidden email] >
  http:///user/SendEmail.jtp?type=node&node=5830884&i=4>>
  http:///user/SendEmail.jtp?type=node&node=5830884&i=5>>
  <[hidden email] >
  <[hidden email] >
  http:///user/SendEmail.jtp?type=node&node=5830884&i=8>>
  <[hidden email] >
  <[hidden email] >
  <[hidden email] >

___
Tagging mailing list
[hidden email] 
https://lists.openstreetmap.org/listinfo/tagging


--
 If you reply to this email, your message will be added to the discussion
below:
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830884.html
 To unsubscribe from Wiki Edit War on using/avoiding semicolon lists, click
here

.
NAML





--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5830886.html
Sent from the Tagging mailing list archive at Nabble.com.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addrN:*

[John F. Eldredge]

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 features, so a distinct address
should be found only once in the database.


And I see it the other way. Addresses are just attributes. It may pendend on
the country, I don't know. In Austria and most certainly in entire central
Europe, an address is always bound to a building, apartment or strictly
delimited plot of land. An address cannot exist on its own. Every address
includes a housenumber, indicating that there's a house. There are no
addresses in the midst of a lake or somewhere in the cliffs.



If you have a "strictly delimited plot of land", with no house currently 
built upon it, but which is intended for later construction, does it 
have a house number?  Or is the address only assigned once a building is 
built?


--
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness; only light can do that.
Hate cannot drive out hate; only love can do that."
Dr. Martin Luther King, Jr.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Deprecation of associatedStreet-relations

[Marc Gemis]

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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging