Re: [Tagging] Feature Proposal - RFC - police=*

[Jan S]

Am 15. März 2019 07:55:31 MEZ schrieb Joseph Eisenberg 
:
>Please don’t change the established meaning of amenity=police; it
>should
>keep meaning “a public police station”.
>
>Most database users are only going to be interested in public police
>stations, that’s why we’ve gotten by for over 10 years with just
>amenity=police.

But amenity=police is currently used indiscriminately for *all* police 
stations, public-facing or not. That's what makes the current mapping 
inconsistent and impractical. To make it usable and consistent again, we'd at 
least have to either replace amenity=police by police=* in all 
non-public-facing police facilities or add police=* to the tagging of these 
facilities.

And, I don't think that tagging police stations as amenity=police and 
police=station would be too demanding for the average mapper. You just have to 
get used to it.

I simply find it undesirable to use different keys for things that are so 
closely connected in reality as is the case of police facilities.

Best, Jan

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

Re: [Tagging] Mapping deforestation wikipage

[Joseph Eisenberg]

>
> > “The idea is to have mapathon in
>
> different time, when new imagery are
>
> available and after check what
>
> changed searching in the database
>

In this case you only need to map the area of woodland or forest now, and
it’s no problem to leave other landuse and natural areas unmapped.

But it may be difficult to use the OSM database for checking changes over
time, if you would like scientific, publishable results.

To properly compare the current woodland area with the area in a couple of
years, you will need to make sure that the aerial imagery that you use now
is all from the same year.

Then, when you repeat the project in 1 or 2 years, you need to have new
imagery from around the same time, and you should map the woodland or
forested areas using the same standard and methods as they first time. This
will be easiest if you remap everything from scratch the second time as
well.

If you try to use the OSM database both times, you may find that other
mappers have changed things in the meantime. Perhaps they have changed some
of your landuse=forest to natural=wetland wetland=mangrove, because they
know the area better. Perhaps they have mapped a new palm
oil plantation based on local information, but it isn’t visible in the
aerial imagery. How will you deal with such changes?

So it is great to add the forest or wood areas to OSM right now based on
the latest aerial imager.

But you should plan to keep your own copy of the database to compare with
and edit in the future. If you do this right it could be
professionally-quality data for environmental research, but that means you
need to keep a copy of the data that won’t change, and use that for
comparison in the future.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Mateusz Konieczny]

Mar 15, 2019, 7:37 AM by grimpeu...@gmail.com:

>
>
> Am 15. März 2019 00:19:22 MEZ schrieb althio <> althio.fo...@gmail.com 
> > >:
> >Martin Koppenhoefer <> dieterdre...@gmail.com 
> >> > wrote:
>
>>> > If this seems viable, I would expand the proposal by a migration
>>>
> >proposal from amenity=police to police=station
>
>>>
>>> I don’t think we should abandon amenity=police and it will likely not
>>>
> >happen unless people tag so many different things with the tag that it
> >becomes useless. My primary interest is in specifying the kind of
> >police and facility, a generic amenity=police on top of that does not
> >harm. If the new scheme becomes so widespread that every police station
> >also has a more specific police=* tag, we can still decide to remove
> >the amenity=police tags.
>
> That sounds reasonable. So we'd keep amenity=police as the general indicator 
> of police facilities
>
Public-facing police facilities. For example police warehouse should not be 
tagged with it
(and even if some are tagged this way I think that everybody would consider it 
as a tagging
mistake).

>  and use police=* as a sub-tag to specify the type of facility.
>
It should be noted that it can be used also without amenity=police for 
non-public
facilities.

>  amenity=police would be reduced to indicate that the tag is used for all 
> police facilities
>
I am against changing meaning of an established tag (even if it has some 
mistaggings).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Charles MILLET]

Taginfo shows it is not the preferred method 979<3562

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane

*=opposite_lane is/was well understood as far as I know (I am regularly 
"teaching" OSM using the bicycle wiki page as reference).


Why using two tags when one works well, when the value opposite_lane 
exists and the interpretation is the same?


I can understand the more structured aspect but using the :oneway value 
not to traduce the oneway but its direction is not clean for me. Why not 
using something with backward and forward in this case?


Just my opinion but if "cycleway:left:oneway=-1" is officially preferred 
I will use it and promote it.


Charles

On 15/03/2019 01:35, Hubert87 wrote:

I also regard

"cycleway:left=lane"
"cycleway:left:oneway=-1"

as the currently preferred method and have been mapping/tagging like 
this for a while now.


Just my two cents

Hubert87


Am 15.03.2019 um 00:12 schrieb althio:

Discussed: maybe there
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
Decided : I don't know

Cmuelle introduces rather complex combinations of tags such as 
cycleway:left=lane + cycleway:left:oneway=-1, that should in his 
view be used instead of cycleway:left=opposite_lane.  Does anyone on 
this list know whether this change has been discussed anywhere, and 
where and when it has been decided that cycleway=opposite_lane is a 
"legacy tag" ? If so please point me at some references.

___
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] Mapping deforestation wikipage

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 08:32, Joseph Eisenberg  
> wrote:
> 
> But you should plan to keep your own copy of the database to compare with and 
> edit in the future.


the OSM db contains all the history as well, not just the current state. What 
you often cannot tell from the data though, is the reason for an edit: have the 
changes been applied to follow changes in the real world, or were there simply 
errors or imprecisions before which have now been fixed, without any change to 
the real situation.

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 09:23, Charles MILLET  wrote:
> 
> Why using two tags when one works well, when the value opposite_lane exists 
> and the interpretation is the same?


why using a specific tag if everything can be expressed with standard tags?
There are arguments for both points of view 


Cheers, Martin 


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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Charles MILLET]

It was introduce in may 2018 when opposite_lane was already well used 
and described in the wiki. I don't see any process of validation but 
correct me if I am wrong. I feel the wiki modification to introduce 
cycleway:left=lane + cycleway:left:oneway=-1 has been forced through.


Charles

On 15/03/2019 00:12, althio wrote:

Discussed: maybe there
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
Decided : I don't know


Cmuelle introduces rather complex combinations of tags such as cycleway:left=lane + 
cycleway:left:oneway=-1, that should in his view be used instead of 
cycleway:left=opposite_lane.  Does anyone on this list know whether this change has been 
discussed anywhere, and where and when it has been decided that cycleway=opposite_lane is 
a "legacy tag" ? If so please point me at some references.

___
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] Wild changes to wiki pages changing the cycleway tagging scheme

[Topographe Fou]

In absolute yes but be carefull: Some editors (like StreetComplete since some 
weeks or iD) might push one or the other schema without the user knowing which 
one is used in the background and sometimes without rationale why this one and 
not the other one on editor side (they implement ONE, they do not offer the 
choice to the user). And I suspect many of those data came from an editor input 
field vs a user which have typed the key and the value.

Yours,


LeTopographeFou


  Message original  



De: charlesmil...@free.fr
Envoyé: 15 mars 2019 9:25 AM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging 
scheme


Taginfo shows it is not the preferred method 979<3562

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1

https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane

*=opposite_lane is/was well understood as far as I know (I am regularly
"teaching" OSM using the bicycle wiki page as reference).

Why using two tags when one works well, when the value opposite_lane
exists and the interpretation is the same?

I can understand the more structured aspect but using the :oneway value
not to traduce the oneway but its direction is not clean for me. Why not
using something with backward and forward in this case?

Just my opinion but if "cycleway:left:oneway=-1" is officially preferred
I will use it and promote it.

Charles

On 15/03/2019 01:35, Hubert87 wrote:
> I also regard
>
> "cycleway:left=lane"
> "cycleway:left:oneway=-1"
>
> as the currently preferred method and have been mapping/tagging like
> this for a while now.
>
> Just my two cents
>
> Hubert87
>
>
> Am 15.03.2019 um 00:12 schrieb althio:
>> Discussed: maybe there
>> https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
>> Decided : I don't know
>>
>>> Cmuelle introduces rather complex combinations of tags such as
>>> cycleway:left=lane + cycleway:left:oneway=-1, that should in his
>>> view be used instead of cycleway:left=opposite_lane.  Does anyone on
>>> this list know whether this change has been discussed anywhere, and
>>> where and when it has been decided that cycleway=opposite_lane is a
>>> "legacy tag" ? If so please point me at some references.
>> ___
>> 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] Wild changes to wiki pages changing the cycleway tagging scheme

[althio]

Whatever the preferred tagging method, both are used and both should be
documented in the wiki.
At least for the sake of data users and definition of used tags.

The edit of the wiki looks suspicious.

On Fri, Mar 15, 2019, 09:25 Charles MILLET  wrote:

> Taginfo shows it is not the preferred method 979<3562
>
> https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1
>
> https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane
>
> *=opposite_lane is/was well understood as far as I know (I am regularly
> "teaching" OSM using the bicycle wiki page as reference).
>
> Why using two tags when one works well, when the value opposite_lane
> exists and the interpretation is the same?
>
> I can understand the more structured aspect but using the :oneway value
> not to traduce the oneway but its direction is not clean for me. Why not
> using something with backward and forward in this case?
>
> Just my opinion but if "cycleway:left:oneway=-1" is officially preferred
> I will use it and promote it.
>
> Charles
>
> On 15/03/2019 01:35, Hubert87 wrote:
> > I also regard
> >
> > "cycleway:left=lane"
> > "cycleway:left:oneway=-1"
> >
> > as the currently preferred method and have been mapping/tagging like
> > this for a while now.
> >
> > Just my two cents
> >
> > Hubert87
> >
> >
> > Am 15.03.2019 um 00:12 schrieb althio:
> >> Discussed: maybe there
> >> https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
> >> Decided : I don't know
> >>
> >>> Cmuelle introduces rather complex combinations of tags such as
> >>> cycleway:left=lane + cycleway:left:oneway=-1, that should in his
> >>> view be used instead of cycleway:left=opposite_lane.  Does anyone on
> >>> this list know whether this change has been discussed anywhere, and
> >>> where and when it has been decided that cycleway=opposite_lane is a
> >>> "legacy tag" ? If so please point me at some references.
> >> ___
> >> 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] Wild changes to wiki pages changing the cycleway tagging scheme

[Mateusz Konieczny]

Yes, one of main points of StreetComplete is to allow editing without
knowing how objects are tagged, similarly iD.

It means that to count "how many people decided to use tag XYZ"
all iD users and all StreetComplete users count as say 4 people
because not each mapper is deciding on its own but it is 
decision of whoever makes the software.


Mar 15, 2019, 9:41 AM by letopographe...@gmail.com:

> In absolute yes but be carefull: Some editors (like StreetComplete since some 
> weeks or iD) might push one or the other schema without the user knowing 
> which one is used in the background and sometimes without rationale why this 
> one and not the other one on editor side (they implement ONE, they do not 
> offer the choice to the user). And I suspect many of those data came from an 
> editor input field vs a user which have typed the key and the value.
>

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Charles MILLET]

I am not comfortable with the definition of standard tag in this case.

Isn't the tag or name space "oneway" made to define that a lane is 
oneway or not ? In this case using cycleway:left means by default it is 
oneway. So the name space ":oneway" is used to describe the direction.


Correct me if I am wrong.

Charles

On 15/03/2019 09:32, Martin Koppenhoefer wrote:


sent from a phone


On 15. Mar 2019, at 09:23, Charles MILLET  wrote:

Why using two tags when one works well, when the value opposite_lane exists and 
the interpretation is the same?


why using a specific tag if everything can be expressed with standard tags?
There are arguments for both points of view


Cheers, Martin


___
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] Wild changes to wiki pages changing the cycleway tagging scheme

[Richard Fairhurst]

Mateusz Konieczny wrote:
> Yes, one of main points of StreetComplete is to allow editing 
> without knowing how objects are tagged, similarly iD.
> 
> It means that to count "how many people decided to use tag 
> XYZ" all iD users and all StreetComplete users count as say 
> 4 people because not each mapper is deciding on its own 
> but it is decision of whoever makes the software.

Oh, come on. Just because iD has an actual user interface doesn't mean that
every single iD user is unaware of the tags used. There are plenty of
experienced mappers (I'm one) who choose not to use JOSM because they just
don't like JOSM, believe it or not!

On topic: I don't have a great preference for either tagging scheme (they're
both a bit ungainly, I've found them both a bit of a PITA to support in
cycle.travel's tag parsing). cycleway=opposite_lane is concise but unclear.
Regardless, both are in widespread use so the wiki should document both.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 09:59 Uhr schrieb Charles MILLET <
charlesmil...@free.fr>:

> I am not comfortable with the definition of standard tag in this case.
>
> Isn't the tag or name space "oneway" made to define that a lane is
> oneway or not ? In this case using cycleway:left means by default it is
> oneway. So the name space ":oneway" is used to describe the direction.
>


from my understanding, "oneway" is a legal restriction, and it also defines
the direction (yes means in direction of the osm object, -1 means in
counter direction).

I would not read too much implicit restrictions or permissions into
"cycleway:left"=track/lane etc. as the intended "defaults" may vary across
jurisdictions and mappers, and would rather add explicit information about
oneway, amount of lanes, surface, width etc.

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Mateusz Konieczny]

Mar 15, 2019, 10:03 AM by rich...@systemed.net:

> Mateusz Konieczny wrote:
>
>> Yes, one of main points of StreetComplete is to allow editing 
>> without knowing how objects are tagged, similarly iD.
>>
>> It means that to count "how many people decided to use tag 
>> XYZ" all iD users and all StreetComplete users count as say 
>> 4 people because not each mapper is deciding on its own 
>> but it is decision of whoever makes the software.
>>
>
> Oh, come on. Just because iD has an actual user interface doesn't mean that
> every single iD user is unaware of the tags used. There are plenty of
> experienced mappers (I'm one) who choose not to use JOSM because they just
> don't like JOSM, believe it or not!
>
Thanks, I was unaware about it! I was always really frustrated by iD
hiding tags and requiring scrolling to get it (and really slow performance).

I admit that I was unaware that it is used as a primary editor also by people 
editing tags directly.

Sorry for spreading misinformation.


> On topic: I don't have a great preference for either tagging scheme (they're
> both a bit ungainly, I've found them both a bit of a PITA to support in
> cycle.travel's tag parsing). cycleway=opposite_lane is concise but unclear.
> Regardless, both are in widespread use so the wiki should document both.
>
Yes, if both are in a widespread use then both should be described.

Claim that opposite_lane is a value that has no meaning with cycleway:left
that appeared on Wiki (in edit description) is completely untrue.

Maybe some people dislike this tag and it is more confusing than it should be
but it  has a known meaning.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Tony Shield]

Agreed - don't change the meaning. If additional information is required 
- and I'm not sure why - then additional police=* tag is a good 
alternate to the Amenity tag.


TonyS

On 15/03/2019 06:55, Joseph Eisenberg wrote:
Please don’t change the established meaning of amenity=police; it 
should keep meaning “a public police station”.


Most database users are only going to be interested in public police 
stations, that’s why we’ve gotten by for over 10 years with just 
amenity=police.


It’s fine if the police=* tag isn’t I’m used by all renderers and 
database users at first, because only some types of maps and databases 
need additional info.


Joseph

On Fri, Mar 15, 2019 at 3:39 PM Jan S > wrote:




Am 15. März 2019 00:19:22 MEZ schrieb althio
mailto:althio.fo...@gmail.com>>:
>Martin Koppenhoefer mailto:dieterdre...@gmail.com>> wrote:
>> > If this seems viable, I would expand the proposal by a migration
>proposal from amenity=police to police=station
>>
>> I don’t think we should abandon amenity=police and it will
likely not
>happen unless people tag so many different things with the tag
that it
>becomes useless. My primary interest is in specifying the kind of
>police and facility, a generic amenity=police on top of that does not
>harm. If the new scheme becomes so widespread that every police
station
>also has a more specific police=* tag, we can still decide to remove
>the amenity=police tags.

That sounds reasonable. So we'd keep amenity=police as the general
indicator of police facilities and use police=* as a sub-tag to
specify the type of facility. The current wiki page for
amenity=police would consequently move to police=station and
amenity=police would be reduced to indicate that the tag is used
for all police facilities (and maybe hold a list of what's
considered police by country).

I'll adapt the proposal.

>There is no need to abandon amenity=police for public facing police
>stations.

That, on the contrary, doesn't seem consequent to me. We'd end up
with amenity=police and police=* as main tags for different types
of police facilities. I fear that that would be confusing and
cause inconsistent mapping.

___
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] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 15/3/19 10:12 am, althio wrote:

Discussed: maybe there
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
Decided : I don't know


Even for the tagging list that is one rambling thread. After pushing 
through a lengthy discussion on how to count the number of lanes, how 
OSM is not like the Linux kernel and a deviation into tagging arbiters, 
you'll find that several mappers suggest using opposite_lane and no-one 
objecting to that.


The previous time this is discussed is in this thread from Feb 2017:

https://www.mail-archive.com/tagging@openstreetmap.org/msg31084.html

Once again with no mention that opposite_lane is not the way to tag.

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Andrew Davidson]

On 15/3/19 11:35 am, Hubert87 wrote:

>

"cycleway:left:oneway=-1"

as the currently preferred method and have been mapping/tagging like 
this for a while now.


What makes you think that?

cycleway:left:oneway=-1 => 979
cycleway:right:oneway=-1 => 19

oneway:bicycle=no => 70400

and looking at http://taghistory.raifer.tech/ oneway:bicycle was being 
added at a rate of 120:1 to cycleway:left/right:oneway in the first half 
of 2018.


It seems to be that the preferred method is oneway:bicycle=no and 
cycleway:left/right:oneway=-1 is a rarely used oddity.


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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 11:15 Uhr schrieb Andrew Davidson <
thesw...@gmail.com>:

> On 15/3/19 11:35 am, Hubert87 wrote:
>
>  >
> > "cycleway:left:oneway=-1"
> >
> > as the currently preferred method and have been mapping/tagging like
> > this for a while now.
>
> What makes you think that?
>
> cycleway:left:oneway=-1 => 979
> cycleway:right:oneway=-1 => 19
>
> oneway:bicycle=no => 70400
>
> and looking at http://taghistory.raifer.tech/ oneway:bicycle was being
> added at a rate of 120:1 to cycleway:left/right:oneway in the first half
> of 2018.



these tags are stating different things though:

oneway:bicycle=no => 70400 is about oneway roads where the oneway
restriction does not apply to cyclists.

cycleway:left:oneway=-1 on the other hand is describing a dedicated cycling
infrastructure with a oneway restriction (opposite to the osm way
direction).

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Hufkratzer]

I wonder why we need a separate type=superroute if everything what can 
be done with superroutes can also be done with normal routes. Example: 
http://hiking.waymarkedtrails.org/?l#route?id=371740 is a normal hiking 
route, more than 10k km long, with 7 child relations that have child 
relations again. What is the difference between relation type route and 
superroute except the name? You might say that a superroute is a route 
that does not contain ways or nodes but only relations. But is that a 
good/sufficient reason to define a new relation type? Is there any other 
difference?



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

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Sergio Manzi]

On 2019-03-14 23:57, Martin Koppenhoefer wrote:
> There are indications that at least 2 other secret groups operating in osm 
> are suspicious about the plans for a new group and are planning to covf

Another tasteless and vile joke. Not that I was expecting anything better from 
you, Martin: tastless jokes are a clear sign of a lower IQ and a troubled 
personality by someone with the delusion of being superior to others.

Anyway, I see this as the last straw and I have decided to unsubscribe from the 
mailing list and leave the community: too much noise and bitching and I have 
more important things to do in my life.

I suppose you can congratulate yourself, Martin: you achieved what quite 
evidently was your goal, since day one.

Goodbye everybody.

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[marc marc]

Le 15.03.19 à 12:27, Hufkratzer a écrit :
> is that a good/sufficient reason to define a new relation type?

imho nearly no routing tools (nor foot nor bus) is currently able
to use a relation type=route with relations as child.
so that's a good reason to create/improve a doc if superrelation is 
needed for ex for routing (of course maybe some mapper need superroute 
only for the fun of having a relation that collect all other).

for ex how a "data user" can detect "it 's a superroute" <> "it's 2 
route with a shared segment" ?
for the moment, the trick is to notice that the name of the main 
relationship is close to the name of the children's relationships
and to know that the names of all these children's relationships
are fake names (which should therefore be removed/corrected).
there is for ex nothing called "European long distance path E4 - part 
France". it's an artificial name to descript how the relation is splited

maybe the tag network should be the same and/or the name (the country 
XYZ may move the a scope tag)
the main relation must/should/mustn't/shouldn't have all/some same tag 
as the child ?
all/a lot of child tag must move to the main relation only ? (that's 
what we do with MP : we don't duplicate alls tags to way + relation)
etc...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

The answer to your question is simple. The conretion
of opposite_lane depends on the traffic system you're
in, but cycleway:left and cycleway:right are globally
used tags, not limited to a specific jurisdiction.

In particular, :left and :right suffixes _do not_
depend on the traffic system in use, but rather on
the direction of the osm way (which is defined by
the order of its node list).


Regards,
cmuelle8

> On 15/03/2019 08:23, Charles MILLET wrote:
>
> Taginfo shows it is not the preferred method 979<3562
> 
> *=opposite_lane is/was well understood as far as I know (I am regularly 
> "teaching" OSM using the bicycle wiki page as reference).
> 
> Why using two tags when one works well, when the value opposite_lane 
> exists and the interpretation is the same?

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

This is not true, the namespace method has been
employed at least since May 2008, but propably
even before that date on which it was documented:

https://wiki.openstreetmap.org/wiki/Namespace

*:oneway is just an employment of this method,
documentation of a full key may be present, but
this is not an obligation.  If it is missing the
projection of the documentation to the unaffixed
version applies.


Regards,
cmuelle8

> On 15/03/2019 08:34, Charles MILLET wrote:
>
> It was introduce in may 2018 when opposite_lane was already well used 
> and described in the wiki. I don't see any process of validation but 
> correct me if I am wrong. I feel the wiki modification to introduce 
> cycleway:left=lane + cycleway:left:oneway=-1 has been forced through.
> 
> Charles

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

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Frederik Ramm]

Sergio,

and others who might be reading this and thinking it is "normal",

On 15.03.19 12:41, Sergio Manzi wrote:
> Another tasteless and vile joke.

It is ok to say that, even though I'd hope it is rarely necessary.

But it is definitely not ok to say

> Not that I was expecting anything better from you, Martin: tastless jokes are 
> a clear sign of a lower IQ and a troubled personality by someone with the 
> delusion of being superior to others.

Please keep such personal attacks to yourself, they have no place on our
mailing lists. You can frame your criticism as a criticism of opinions
or behaviour, but singling out an individual and making judgements about
their IQ our psyche is totally out of line.

> I have decided to unsubscribe from the mailing list and leave the community: 
> too much noise and bitching

Well thank you for adding on top of that. Great help.

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] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

+1 for your rationale by not being blinded by sheer numbers.
(if we are to go by the numbers there, we are stuck with the
oldest and most established tags ever, regardless of their
shortcomings)

-1 for your suspicion.  If you cannot live with a wiki being
changed, then use paper.  Wikis were meant to be edited.
They are here, to not have to use an eraser or whiteout if
an example is to be added or a mistake is to be fixed.

OT: The people stuck in their habit of continuously commenting
on things, longing to pertain the status quo regardless of
how ridiculous the state it is in, don't they look suspicious
too in your eyes?


Regards,
cmuelle8
 

> On 15/03/2019 08:50, althio wrote:
> 
> Whatever the preferred tagging method, both are used and both should be 
> documented in the wiki.
> At least for the sake of data users and definition of used tags.
> 
> The edit of the wiki looks suspicious. 

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

It also means that this software in turn
could dictate what the wiki has to document.

There are lots of people around deriving tag
meaning based on taginfo data.  If the wiki
doc is not in sync with their findings, it
is tempting to document the state empirically
observable.

In some cases, spare the one that caused this
thread, editing the wiki has less resistance
than e.g. trying to achieve consensus for a
mechanical edit (which is error prone even
if legitimate) to fix sloppy data.


Regards,
cmuelle8


> On Mar 15, 2019, 9:41 Mateusz Konieczny wrote:
> 
> It means that to count "how many people decided to use tag XYZ"
> all iD users and all StreetComplete users count as say 4 people

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 12:07:50PM +, marc marc wrote:
> Le 15.03.19 à 12:27, Hufkratzer a écrit :
> > is that a good/sufficient reason to define a new relation type?
> 
> imho nearly no routing tools (nor foot nor bus) is currently able
> to use a relation type=route with relations as child.
> so that's a good reason to create/improve a doc if superrelation is 
> needed for ex for routing (of course maybe some mapper need superroute 
> only for the fun of having a relation that collect all other).
> 
> for ex how a "data user" can detect "it 's a superroute" <> "it's 2 
> route with a shared segment" ?

waymarkedtrails uses the network tag as an indicator. With the
same network tag, the child is considered a segment. If the network
tag is different, then the child is considered a route on its own
that happens to be used by the superroute.

> maybe the tag network should be the same and/or the name (the country 
> XYZ may move the a scope tag)
> the main relation must/should/mustn't/shouldn't have all/some same tag 
> as the child ?
> all/a lot of child tag must move to the main relation only ? (that's 
> what we do with MP : we don't duplicate alls tags to way + relation)
> etc...

The disadvantage of all these proposals is that it is impossible
to figure out if a relation is a route or only part of a superroute
without looking at the parent. That information is much more
valuable than the information that a route is a 'superroute' (that's 
obvious anyway as soon as there is a relation member). So I'd
prefer seeing a dedicated tag added to relations that are just a segment.
'route_segment=yes', for example. Or even better, directly name the
sections, e.g. 'part=German section' or 'part=2. Etappe'. Then we can
get rid of the descriptive name tags.

Kind regards

Sarah

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

The oneway attribute, unaffixed or not, reflects the direction
a way may _legally_ be used in.  You're free to ignore it, but
may have to deal with consequences by law enforcement personnel.

Because in OSM each way has an inherent direction given by the
order of its node list (let it be D), it is a ternary attribute
allowing three values.  For a rather long time, it meant/means
that

- oneway=yes precepts usage along D
- oneway=-1 precepts usage opposite to D
- oneway=no does not precept a direction

Its namespace suffixed variants should by all have equivalent
interpretation.  By depending solely on D the interpretation
is indpendent of the left/right-handedness of a traffic system.


However, based on empirical data research people are about to
dilute the value of 'yes' to maybe mean -1 as well, depending
on ancillary conditions.  I strongly oppose such dilution for
the same reason I oppose using 'opposite_lane' as a value for
cycleway:right= or cycleway:left=


Regards,
cmuelle8


> On 15/03/2019 08:58, Charles MILLET wrote:
> 
> Isn't the tag or name space "oneway" made to define that a lane is 
> oneway or not ? In this case using cycleway:left means by default it is 
> oneway. So the name space ":oneway" is used to describe the direction.
> 
> Correct me if I am wrong.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Richard Fairhurst]

marc marc wrote:
> imho nearly no routing tools (nor foot nor bus) is currently 
> able to use a relation type=route with relations as child.

cycle.travel can.

I don't particularly care what's decided, but I would like it to be
consistent (which right now it certainly isn't), and personally I don't see
the need for type=superroute when you can just have relations as children of
type=route. I like Sarah's proposal for route_segment=yes.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

Oh, and how exactly do you explain, that it never
ever appeared in the tag description for cycleway:left
and cycleway:right ?

Even on Bicycle wiki page, these were _red_ links,
while all the other stuff had neatly been linked
to existing and valid tag descriptions.

The meaning of it has never been documented on
the wiki and only recently been derived based
on live data.  The tag recommendation on the
Bicycle wiki page is limited to pair with
imagery to discriminate the intended use
by example and fails to give a proper
description.

In practice mappers had to imply that the meaning
ought to be somehow, in an obscure way, similar
to the description that is present for cycleway=,
the unaffixed variant.

Red links, no proper documentation, and a usage
you need to guess solely on limited examples,
additionally limited to right hand traffic system
only are a lot of facts to conclude that this part
of the doc has been (and is) dubious, or more
loosely _meaningless_.

Sorry, but "completely untrue" is different. 


Regards,
cmuelle8

> On Mar 15, 2019, 09:09 Mateusz Konieczny wrote:
> 
> Claim that opposite_lane is a value that has no meaning with cycleway:left
> that appeared on Wiki (in edit description) is completely untrue.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

I like Sarah's proposal too, especially for walking routes. I'm not sure it
would work for complex PT routes, where routability is involved.

One issue: a route relation can be a route on it's own AND part of a longer
route (or node network), on any level of the hierarchy. segment=yes would
not cover that, I think?
And when naming parts, you'll have to cover the case that a route can be
part of multiple longer routes, the route itself may contain smaller parts
that are also part of multiple routes.
Parts can have any of the network tags.

This complication is not created by Sarah's idea, but I would like to see
that solved too.

Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst :

> marc marc wrote:
> > imho nearly no routing tools (nor foot nor bus) is currently
> > able to use a relation type=route with relations as child.
>
> cycle.travel can.
>
> I don't particularly care what's decided, but I would like it to be
> consistent (which right now it certainly isn't), and personally I don't see
> the need for type=superroute when you can just have relations as children
> of
> type=route. I like Sarah's proposal for route_segment=yes.
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> 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] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

I'm objecting right now and heavily so.
There are lots of mappers not continuously
reading the mailing list or that are active
in other forums, so I do not have to regret
that I have not been there in 2017 or 2018.

cycleway:right= and cycleway:left=  tags
are way older.  And no-one thought about
using "opposite_lane" as a value at the
time of their introduction.

This may also explain why you will not
find reference that explicitly _excludes_
that value.  Because "back in the days"
no-one would have ever thought that this
may become an issue one day.

The wiki was clear in that "lane" and
"track" values ought to be used.  No-one
had written up an exclusion list of values
not to use, because no-one had seen the
need for such thing.

If only two values are documented, you'd
expect that only two values are used, would
you not?  And in the case, that another value
ever were added, you'd expect that people
would think of the implications, discuss the
implications and modify the doc with the same
care it originally was written with.


Where are the wiki edits in 2017 of 2018 of the
wiki, documenting the results of the mailing
list discussions back then?  Are they limited to
placing red links aside limited example pics?


cycleway:right and cycleway:left are a lot older:

https://forum.openstreetmap.org/search.php?action=search&keywords=cycleway%3Aright&show_as=topics

The search returns five pages with a history
dating back to May 2008.  Use in the db may
even still be older than that.


Regards,
cmuelle8

> On 15/3/19, 09:49, Andrew Davidson wrote:
> 
> you'll find that several mappers suggest using opposite_lane and no-one 
> objecting to that.
> 

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

oneway:bicycle=no is indifferent to a specific lane object,
it only means that a specific mode of transportation has
an exemption from the value tagged using oneway=*

In fact, oneway:bicycle=no refers most prominently to oneways
that do not have a marked cycleway lane at all, e.g. case S1
in the osm wiki [1].

It is not an adequate replacement for the lane specific
tags and thus should not be mixed.


Regards,
cmuelle8

[1] https://wiki.openstreetmap.org/wiki/Bicycle#Miscellaneous


> On 15/3/19, 10:13, Andrew Davidson wrote:
> 
> oneway:bicycle=no => 70400
> 
> and looking at http://taghistory.raifer.tech/ oneway:bicycle was being 
> added at a rate of 120:1 to cycleway:left/right:oneway in the first half 
> of 2018.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 14:43, Peter Elderson  wrote:
> 
> I like Sarah's proposal too, especially for walking routes. I'm not sure it 
> would work for complex PT routes, where routability is involved. 


how can we state that a route is complete and also a segment of another route? 
Safest way would be a third relation with just the segment as only member for 
the “complete” route, but maybe it can be done more elegantly with 2 relations 
rather than 3?

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Volker Schmidt]

As the one who in a way triggered this discussion originally, a discussion
that has been abandoned without conclusion, I want to say that I had very
much preferred that the discussion be restarted *before *a one-sided wiki
change.
If two different methods are in use, we should document both, outlining
also their limitations.
I had suspended spending time on this, as I intended to introduce also
other combinations, like two-way cycle lanes (no physical separation) on
one side of the road, combined or segregated foot-cycle lanes on one side
of the road, and maybe others that I have forgotten about.
The more cycling-related infrastructure I map, the more odd solutions come
up, for which I would like to have consensus-based mapping solutions.

On Fri, 15 Mar 2019 at 15:07, "Christian Müller"  wrote:

> oneway:bicycle=no is indifferent to a specific lane object,
> it only means that a specific mode of transportation has
> an exemption from the value tagged using oneway=*
>
> In fact, oneway:bicycle=no refers most prominently to oneways
> that do not have a marked cycleway lane at all, e.g. case S1
> in the osm wiki [1].
>
> It is not an adequate replacement for the lane specific
> tags and thus should not be mixed.
>
>
> Regards,
> cmuelle8
>
> [1] https://wiki.openstreetmap.org/wiki/Bicycle#Miscellaneous
>
>
> > On 15/3/19, 10:13, Andrew Davidson wrote:
> >
> > oneway:bicycle=no => 70400
> >
> > and looking at http://taghistory.raifer.tech/ oneway:bicycle was being
> > added at a rate of 120:1 to cycleway:left/right:oneway in the first half
> > of 2018.
>
> ___
> 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] Superroutes - good, bad or ugly?

[seirra blake]

I can see *a lot* of shared routes in my area because most of the buses 
heavily use a star topography (everything must take you to a central 
station) as opposed to a hybrid mesh/star topography (everywhere has 
access to a service to a central station, but there are circular routes 
to allow quicker travel in some circumstances). for example my local 
service has one incredibly early train station detour (presumably for 
long distance commuters), the two main routes (incoming/outgoing) and a 
route that stops at the bus depot. all 4 of these routes share a large 
part of it and that's just one route number! such route segments could 
help shrink and simplify maintaining the relations a lot. for example if 
there's a detour due to roadworks, you don't have to edit the very large 
number of relations individually, (our bus station has around 20 bays, 
each taking multiple services...) just the shared child relations. I 
don't think we need a specially labelled super route relation, but 
perhaps we do need a way to tell the data user that a segment is shared. 
these are the problems I see:


1. where do the tags go?
2. do you need a separate one for each direction?
3. is type=super_route or similar the best idea?
4. how far can they nest?
5. a shared route is being used for public transport, should the stop
   positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

1. if a route is shared, tags should be minimal and only related to the
   physical route itself perhaps not even including the usual route tag
   (AFAIK wouldn't just about any route relation in existence define
   the route tag? so this would just be another pointer to the software
   that this isn't your regular route. but maybe it still is best to
   tag it, in which case maybe route=shared?), rather than things
   such as what bus routes it is part or anything, this can easily be
   seen simply by looking at parent relations
2. maybe use the roles forward/backward? I don't think these are used
   for much any more
3. what do we gain? I think this can more easily be solved by simply
   adding another tag such as shared=yes which can tell the software
   that there are route relations that are intended to be treated as
   just one big way. see below for a more detailed explanation.
4. I don't see a reason to limit the nesting, I imagine in most use
   cases, the benefit of sharing duplicate relation data probably
   outweighs any impact from processing nesting
5. if a shared route is used for both a numbered road route and public
   transport it's probably unfair on the road user that doesn't need
   them if they are included. also this would make it difficult to work
   out where to place it in a public transport V2 relation.. as they
   have stops at the top, ways at the bottom but this has both!

so here's an indented, somewhat simplified example of how it roughly 
would nest based on the idea of a public transport route, a cycle route 
and a road relation that share the same set of ways (_underlined_=can be 
shared in parent nesting level, *bold*=can be shared in nesting levels 
outside of the parent one, italic=the level at which main tagging should 
occur. for easier referencing each equivalent level of nesting has been 
assigned a letter):


___

/bus network///[A]/
/

   /route_master=bus /[B]
   //

   /route variant/ [C]

   _*route segments*_ [D]
   __

   _combined bus stop/way relation suitable for public
   transport v2_ [E]
   __

   _shared bus stop relation_ [F]_
   _

   _*shared way relation*_ [G]

/road network///[A]/
/

   /road /[C]

   _*shared way relation*_ [G]*
   *


/cycle network//**/[A]/*
*/

   /cycle route /[C]

   __

   __

   *_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (defaults to no)

[E/F/G]: route=shared (this is questionable in terms of benefits though)

_

notes:

[G] may be infinitely nested as required to prevent duplicate sets of 
ways (although this should rarely be required)


as you can see, this allows a lot of the data to be shared between the 
various types of relations, whilst also allowing current relation 
structure to remain the same, this is just an extra higher level of 
detail, where required. due to the way public transport relations are 
handled it may be required to even have every segment in [D] contained 
in a relation, however as cycle and road relations are purely made up of 
ways they may not need the same kind of treatment and be able to mix 
items from [G] with directly referenced ways. the separation of bus stop

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

I have actually done that, a "stub" containing one nwn hiking path which
also acts as the NL part of an iwn route. It was the only way to get the
tagging of names, international names, colours and osmc:symbols right.

On waymarkedtrails it works like a charm, but I'm less sure about OsmAnd.

Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 15:24 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 15. Mar 2019, at 14:43, Peter Elderson  wrote:
> >
> > I like Sarah's proposal too, especially for walking routes. I'm not sure
> it would work for complex PT routes, where routability is involved.
>
>
> how can we state that a route is complete and also a segment of another
> route? Safest way would be a third relation with just the segment as only
> member for the “complete” route, but maybe it can be done more elegantly
> with 2 relations rather than 3?
>
> Cheers, Martin
> ___
> 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] Superroutes - good, bad or ugly?

[Jo]

Good analysis Seirra,

I would not "reuse" route=road in other route=* relations though.
route=bicycle might share segments with route=foot/walking/hiking, but I'd
keep everything related to bus/trolley_bus and coach together in terms of
sharing of subroutes not mix it with other route types.

For public transport the biggest benefit will be ease of maintenance.

The way I see it route=bus relation should describe a single variation in
itinerary, and thus include all the stops for that variation. So in my view
the subroutes only contain ways.
I would create subroutes for each direction of travel, so no
forward/backward roles need to become involved. If the subroute would only
contain a single way, a subroute relation probably wasn't needed.

Paul Allen, I did read your objections to this, but that bus route is
wildly exceptional, whereas buses travelling along 'corridors', reusing the
same roads as the rest of the lines is very common (as that is where the
stops are, obviously).

Maybe I should try to create an example somewhere. Preferably a small
island

Polyglot

On Fri, Mar 15, 2019 at 3:38 PM seirra blake 
wrote:

> I can see *a lot* of shared routes in my area because most of the buses
> heavily use a star topography (everything must take you to a central
> station) as opposed to a hybrid mesh/star topography (everywhere has access
> to a service to a central station, but there are circular routes to allow
> quicker travel in some circumstances). for example my local service has one
> incredibly early train station detour (presumably for long distance
> commuters), the two main routes (incoming/outgoing) and a route that stops
> at the bus depot. all 4 of these routes share a large part of it and that's
> just one route number! such route segments could help shrink and simplify
> maintaining the relations a lot. for example if there's a detour due to
> roadworks, you don't have to edit the very large number of relations
> individually, (our bus station has around 20 bays, each taking multiple
> services...) just the shared child relations. I don't think we need a
> specially labelled super route relation, but perhaps we do need a way to
> tell the data user that a segment is shared. these are the problems I see:
>
>1. where do the tags go?
>2. do you need a separate one for each direction?
>3. is type=super_route or similar the best idea?
>4. how far can they nest?
>5. a shared route is being used for public transport, should the stop
>positions and bus stops be included with all the ways?
>
> so... what do we do? this is what I see as a solution:
>
>1. if a route is shared, tags should be minimal and only related to
>the physical route itself perhaps not even including the usual route tag
>(AFAIK wouldn't just about any route relation in existence define the route
>tag? so this would just be another pointer to the software that this isn't
>your regular route. but maybe it still is best to tag it, in which case
>maybe route=shared?), rather than things such as what bus routes it is part
>or anything, this can easily be seen simply by looking at parent relations
>2. maybe use the roles forward/backward? I don't think these are used
>for much any more
>3. what do we gain? I think this can more easily be solved by simply
>adding another tag such as shared=yes which can tell the software that
>there are route relations that are intended to be treated as just one big
>way. see below for a more detailed explanation.
>4. I don't see a reason to limit the nesting, I imagine in most use
>cases, the benefit of sharing duplicate relation data probably outweighs
>any impact from processing nesting
>5. if a shared route is used for both a numbered road route and public
>transport it's probably unfair on the road user that doesn't need them if
>they are included. also this would make it difficult to work out where to
>place it in a public transport V2 relation.. as they have stops at the top,
>ways at the bottom but this has both!
>
> so here's an indented, somewhat simplified example of how it roughly would
> nest based on the idea of a public transport route, a cycle route and a
> road relation that share the same set of ways (*underlined*=can be shared
> in parent nesting level, *bold*=can be shared in nesting levels outside
> of the parent one, italic=the level at which main tagging should occur. for
> easier referencing each equivalent level of nesting has been assigned a
> letter):
>
>
> ___
>
> *bus network* [A]
>
> *route_master=bus *[B]
>
> *route variant* [C]
>
> *route segments* [D]
>
> *combined bus stop/way relation suitable for public transport v2* [E]
>
> *shared bus stop relation* [F]
>
> *shared way relation* [G]
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
>

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Andy Townsend]

On 15/03/2019 11:41, Sergio Manzi wrote:

... I see this as the last straw ...


(just to add to what Frederik has said)

Can I recommend that all mailing lists work much better with an 
effective killfile at the client side?  That way you don't need to read 
anything by people who you don't think are being constructive.  If you 
think you've missed anything you can always visit 
https://lists.openstreetmap.org/listinfo/tagging and catch up.  "Take a 
break before replying" also often makes a lot of sense.


Best Regards,

Andy



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

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 16:01 Uhr schrieb Jo :

> For public transport the biggest benefit will be ease of maintenance.
>


+1, it will also be "lighter" in a way: the superroute relations = actual
bus routes, will have much slower increase of versions, it will only be the
segment relations who increase for every split of a highway.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

This seems to boil down to: You can put any sequence of connected ways in a
package (shared route segment) and use that package in any route to replace
these ways themselves.

You would need to allow all types of route relations to contain ways and
shared segment relations.

I'm not sure if you would need any special tag to indicate it's shared. If
it's used more than once, it's shared, right?

Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 15:38 schreef seirra blake <
sophietheopos...@yandex.com>:

> I can see *a lot* of shared routes in my area because most of the buses
> heavily use a star topography (everything must take you to a central
> station) as opposed to a hybrid mesh/star topography (everywhere has access
> to a service to a central station, but there are circular routes to allow
> quicker travel in some circumstances). for example my local service has one
> incredibly early train station detour (presumably for long distance
> commuters), the two main routes (incoming/outgoing) and a route that stops
> at the bus depot. all 4 of these routes share a large part of it and that's
> just one route number! such route segments could help shrink and simplify
> maintaining the relations a lot. for example if there's a detour due to
> roadworks, you don't have to edit the very large number of relations
> individually, (our bus station has around 20 bays, each taking multiple
> services...) just the shared child relations. I don't think we need a
> specially labelled super route relation, but perhaps we do need a way to
> tell the data user that a segment is shared. these are the problems I see:
>
>1. where do the tags go?
>2. do you need a separate one for each direction?
>3. is type=super_route or similar the best idea?
>4. how far can they nest?
>5. a shared route is being used for public transport, should the stop
>positions and bus stops be included with all the ways?
>
> so... what do we do? this is what I see as a solution:
>
>1. if a route is shared, tags should be minimal and only related to
>the physical route itself perhaps not even including the usual route tag
>(AFAIK wouldn't just about any route relation in existence define the route
>tag? so this would just be another pointer to the software that this isn't
>your regular route. but maybe it still is best to tag it, in which case
>maybe route=shared?), rather than things such as what bus routes it is part
>or anything, this can easily be seen simply by looking at parent relations
>2. maybe use the roles forward/backward? I don't think these are used
>for much any more
>3. what do we gain? I think this can more easily be solved by simply
>adding another tag such as shared=yes which can tell the software that
>there are route relations that are intended to be treated as just one big
>way. see below for a more detailed explanation.
>4. I don't see a reason to limit the nesting, I imagine in most use
>cases, the benefit of sharing duplicate relation data probably outweighs
>any impact from processing nesting
>5. if a shared route is used for both a numbered road route and public
>transport it's probably unfair on the road user that doesn't need them if
>they are included. also this would make it difficult to work out where to
>place it in a public transport V2 relation.. as they have stops at the top,
>ways at the bottom but this has both!
>
> so here's an indented, somewhat simplified example of how it roughly would
> nest based on the idea of a public transport route, a cycle route and a
> road relation that share the same set of ways (*underlined*=can be shared
> in parent nesting level, *bold*=can be shared in nesting levels outside
> of the parent one, italic=the level at which main tagging should occur. for
> easier referencing each equivalent level of nesting has been assigned a
> letter):
>
>
> ___
>
> *bus network* [A]
>
> *route_master=bus *[B]
>
> *route variant* [C]
>
> *route segments* [D]
>
> *combined bus stop/way relation suitable for public transport v2* [E]
>
> *shared bus stop relation* [F]
>
> *shared way relation* [G]
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
> *cycle route *[C]
>
> *shared way relation* [G]
>
>
> _
>
> potential new tags that may be required:
>
> [C]: shared=yes (defaults to no)
>
> [E/F/G]: route=shared (this is questionable in terms of benefits though)
>
>
> _
>
> notes:
>
> [G] may be infinitely nested as required to prevent duplicate sets of ways
> (although this should rarely be required)
>
> as you can see, this allows a lot of the data to be shared between the
> various types of relations, whilst also allowing cu

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Mateusz Konieczny]

Mar 15, 2019, 2:57 PM by cmu...@gmx.de:

> I'm objecting right now and heavily so.
> There are lots of mappers not continuously
> reading the mailing list or that are active
> in other forums, so I do not have to regret
> that I have not been there in 2017 or 2018.
>
> cycleway:right= and cycleway:left=  tags
> are way older.  And no-one thought about
> using "opposite_lane" as a value at the
> time of their introduction.
>
I am not so sure about this. Given that
it is :left :right suffix for cycleway tag it is not 
surprising that some continued to use values
from cycleway tag.


> The wiki was clear in that "lane" and
> "track" values ought to be used.  No-one
> had written up an exclusion list of values
> not to use, because no-one had seen the
> need for such thing.
>
Is it originally documented as open list,
inheriting cycleway values, excluding
some cycleway values, closed list
or left unclear?

If left unclear then I would not assume that
all agree with me.

> If only two values are documented, you'd
> expect that only two values are used, would
> you not?  And in the case, that another value
> ever were added, you'd expect that people
> would think of the implications, discuss the
> implications and modify the doc with the same
> care it originally was written with.
>
Well, I see noticeable use of 
opposite_lane in
https://taginfo.openstreetmap.org/keys/cycleway%3Aleft#overview 


And in general, Wiki documentation is missing many keys 
and values, even ones used 10 000+ times.

So for


> If only two values are documented, you'd
> expect that only two values are used, would
> you not?  
>
answer is "no".



> Where are the wiki edits in 2017 of 2018 of the
> wiki, documenting the results of the mailing
> list discussions back then?
>
In general, people unfortunately rarely
document mailing list discussions on wiki,
even in cases of a clear consensus.
What is quite weird, given that editing wiki has
usually much greater impact on tag usage
than commenting on mailing list.

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 16:36 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

>
> Where are the wiki edits in 2017 of 2018 of the
> wiki, documenting the results of the mailing
> list discussions back then?
>
> In general, people unfortunately rarely
> document mailing list discussions on wiki,
> even in cases of a clear consensus.
> What is quite weird, given that editing wiki has
> usually much greater impact on tag usage
> than commenting on mailing list.
>



+1, I also noticed this. Even if there is no consensus, it may be
interesting to add links to mailing list discussions from the wiki.

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

[Tagging] make a summary and/or "propage" mailing concensus in the wiki

[marc marc]

Le 15.03.19 à 16:34, Mateusz Konieczny a écrit :
> people unfortunately rarely
> document mailing list discussions on wiki,
> even in cases of a clear consensus.
> What is quite weird, given that editing wiki has
> usually much greater impact on tag usage
> than commenting on mailing list.

I agree with you and imho that should be improved/recommanded to do.
A summary for a very long thread may also be very usefull to :
- check/verify if a concensus exist and/or if the 2 visions are well 
understood
- link this summary in the wiki if needed
- allow people who are not interested in the message "flood" of some 
thread to still know the result

perhaps the original author of the subject is a person who can be summed 
up when he feels that the discussion has given him his answer. or on any 
other person motivated for this kind of "administrative work" but so useful
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Jan S]

Am 15. März 2019 09:17:31 MEZ schrieb Mateusz Konieczny 
:
>Mar 15, 2019, 7:37 AM by grimpeu...@gmail.com:
>
>>
>>
>> Am 15. März 2019 00:19:22 MEZ schrieb althio <>
>althio.fo...@gmail.com > >:
>> >Martin Koppenhoefer <> dieterdre...@gmail.com
>> > wrote:
>>
>>>My primary interest is in specifying the kind of
>>>police and facility, a generic amenity=police on top of that does not
>>>harm. If the new scheme becomes so widespread that every police station
>>>also has a more specific police=* tag, we can still decide to remove
>>>the amenity=police tags.
>>
>> That sounds reasonable. So we'd keep amenity=police as the general
>indicator of police facilities
>>
>Public-facing police facilities. For example police warehouse should
>not be tagged with it
>(and even if some are tagged this way I think that everybody would
>consider it as a tagging
>mistake).

I sense dissent here about the future use of amenity=police. Would it be a 
possible solution to keep amenity=police for public-facing police stations 
only, but invite mappers on the wiki to nevertheless add police=station, so 
that in the future the majority of police stations will hopefully also carry 
the police=station tag?

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

Re: [Tagging] Feature Proposal - RFC - police=*

[Markus]

On Fri, 15 Mar 2019 at 09:19, Mateusz Konieczny  wrote:
>
>> amenity=police would be reduced to indicate that the tag is used for all 
>> police facilities
>
> I am against changing meaning of an established tag (even if it has some 
> mistaggings).

+1

On Fri, 15 Mar 2019 at 17:17, Jan S  wrote:
>
> [...] Would it be a possible solution to keep amenity=police for 
> public-facing police stations only, but invite mappers on the wiki to 
> nevertheless add police=station, so that in the future the majority of police 
> stations will hopefully also carry the police=station tag?

+1

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Tobias Zwick]

Missed the earlier discussion.

I also always regarded cycleway=opposite, opposite_track, opposite_lane, 
opposite_share_busway etc. as the old deprecated method and oneway:bicycle=no + 
normal cycleway tag as the one that superceded it.

Same with cycleway:right=dual_lane/dual_track being superceded by or at least 
synonymous to cycleway:right=lane+cyleway:right:oneway=no.

Tobias 

Am 15. März 2019 01:35:51 MEZ schrieb Hubert87 :
>I also regard
>
>"cycleway:left=lane"
>"cycleway:left:oneway=-1"
>
>as the currently preferred method and have been mapping/tagging like 
>this for a while now.
>
>Just my two cents
>
>Hubert87
>
>
>Am 15.03.2019 um 00:12 schrieb althio:
>> Discussed: maybe there
>>
>https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
>> Decided : I don't know
>>
>>> Cmuelle introduces rather complex combinations of tags such as
>cycleway:left=lane + cycleway:left:oneway=-1, that should in his view
>be used instead of cycleway:left=opposite_lane.  Does anyone on this
>list know whether this change has been discussed anywhere, and where
>and when it has been decided that cycleway=opposite_lane is a "legacy
>tag" ? If so please point me at some references.
>> ___
>> 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] Feature Proposal - RFC - police=*

[marc marc]

Le 15.03.19 à 17:16, Jan S a écrit :
> I sense dissent here about the future use of amenity=police. Would it be a 
> possible solution to keep amenity=police for public-facing police stations 
> only, 

that's the current meaning.

> but invite mappers on the wiki to nevertheless add police=station, so that in 
> the future the majority of police stations will hopefully also carry the 
> police=station tag?

at the risk of repeating myself, some mappers disapprove of having to 
enter the same information twice because of the coexistence of 2 tags 
with the same meaning.
you can of course try your luck by submitting this idea grouped with the 
rest of your proposal... or you can separate this conflicting idea to 
increase the chances of adoption of the main part of your propal,
it's up to you (I'll separate).

anyway, even if it passes, it is unfortunately inevitable that the 2 
tags get out of sync and then the meaning gets worse than before:
if a mapper deletes the only-one tag from a police station,
his intention is clear, it's not more a police station.
if a mapper deletes only one of the 2 tags from a police station, has he 
done so because the police station is closed (and the other must also be 
deleted) or because he wants to delete one of the 2 duplicated schemes?

this "dual-schema" period is really painful, which is why I find it 
preferable that it be as short as possible.
in this perspective, I am in favor of first promoting all police=* who 
currently do not have a tag and once this scheme is well known/used,
do another operation to try to switch amenity=police to police=station 
(and, I repeat, do not underestimate the enormous resistance of some 
community members who think (imho wrongly) that frequent tags should be 
kept immutable for eternity.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Egil]

+1
Sarah would you be willing to write a proposal for this?
Cheers
pangoSE

Sarah Hoffmann  skrev: (15 mars 2019 14:03:28 CET)
>On Fri, Mar 15, 2019 at 12:07:50PM +, marc marc wrote:
>> Le 15.03.19 à 12:27, Hufkratzer a écrit :
>> > is that a good/sufficient reason to define a new relation type?
>> 
>> imho nearly no routing tools (nor foot nor bus) is currently able
>> to use a relation type=route with relations as child.
>> so that's a good reason to create/improve a doc if superrelation is 
>> needed for ex for routing (of course maybe some mapper need
>superroute 
>> only for the fun of having a relation that collect all other).
>> 
>> for ex how a "data user" can detect "it 's a superroute" <> "it's 2 
>> route with a shared segment" ?
>
>waymarkedtrails uses the network tag as an indicator. With the
>same network tag, the child is considered a segment. If the network
>tag is different, then the child is considered a route on its own
>that happens to be used by the superroute.
>
>> maybe the tag network should be the same and/or the name (the country
>
>> XYZ may move the a scope tag)
>> the main relation must/should/mustn't/shouldn't have all/some same
>tag 
>> as the child ?
>> all/a lot of child tag must move to the main relation only ? (that's 
>> what we do with MP : we don't duplicate alls tags to way + relation)
>> etc...
>
>The disadvantage of all these proposals is that it is impossible
>to figure out if a relation is a route or only part of a superroute
>without looking at the parent. That information is much more
>valuable than the information that a route is a 'superroute' (that's 
>obvious anyway as soon as there is a relation member). So I'd
>prefer seeing a dedicated tag added to relations that are just a
>segment.
>'route_segment=yes', for example. Or even better, directly name the
>sections, e.g. 'part=German section' or 'part=2. Etappe'. Then we can
>get rid of the descriptive name tags.
>
>Kind regards
>
>Sarah
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Skickat från min Android-enhet med k9.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

oh the idea is that [G] has type=route, but no route=* because it may be 
used in any form of route (with some 'common sense' of course); route 
does not apply until [C] so route=road would not get reused. there is 
actually a small error, [D/E] is the same and stays exclusively within 
public transport. unless you actively map an island I would hope you are 
joking. in case you weren't the context is that someone made a whole 
fake settlement on an actual island so it would render on the main page 
and someone had to revert a whole load of changesets. I can't imagine 
much friction from the local community if I make an example relation 
alongside the current one and add a note that until further notice 
although based on real data it's a proof of concept though. I'll reply 
to my own email and add a slightly more updated version (just of the 
example) addressing some of this, just to make sure it's clear what I 
meant. if you feel an example would help somewhat I'll make one too; it 
could be useful to see how renderers handle it now. let me know if you'd 
like a 'physical' example.


On 3/15/19 3:00 PM, Jo wrote:

Good analysis Seirra,

I would not "reuse" route=road in other route=* relations though. 
route=bicycle might share segments with route=foot/walking/hiking, but 
I'd keep everything related to bus/trolley_bus and coach together in 
terms of sharing of subroutes not mix it with other route types.


For public transport the biggest benefit will be ease of maintenance.

The way I see it route=bus relation should describe a single variation 
in itinerary, and thus include all the stops for that variation. So in 
my view the subroutes only contain ways.
I would create subroutes for each direction of travel, so no 
forward/backward roles need to become involved. If the subroute would 
only contain a single way, a subroute relation probably wasn't needed.


Paul Allen, I did read your objections to this, but that bus route is 
wildly exceptional, whereas buses travelling along 'corridors', 
reusing the same roads as the rest of the lines is very common (as 
that is where the stops are, obviously).


Maybe I should try to create an example somewhere. Preferably a small 
island


Polyglot

On Fri, Mar 15, 2019 at 3:38 PM seirra blake 
mailto:sophietheopos...@yandex.com>> wrote:


I can see *a lot* of shared routes in my area because most of the
buses heavily use a star topography (everything must take you to a
central station) as opposed to a hybrid mesh/star topography
(everywhere has access to a service to a central station, but
there are circular routes to allow quicker travel in some
circumstances). for example my local service has one incredibly
early train station detour (presumably for long distance
commuters), the two main routes (incoming/outgoing) and a route
that stops at the bus depot. all 4 of these routes share a large
part of it and that's just one route number! such route segments
could help shrink and simplify maintaining the relations a lot.
for example if there's a detour due to roadworks, you don't have
to edit the very large number of relations individually, (our bus
station has around 20 bays, each taking multiple services...) just
the shared child relations. I don't think we need a  specially
labelled super route relation, but perhaps we do need a way to
tell the data user that a segment is shared. these are the
problems I see:

 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the
stop positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

 1. if a route is shared, tags should be minimal and only related
to the physical route itself perhaps not even including the
usual route tag (AFAIK wouldn't just about any route relation
in existence define the route tag? so this would just be
another pointer to the software that this isn't your regular
route. but maybe it still is best to tag it, in which case
maybe route=shared?), rather than things such as what bus
routes it is part or anything, this can easily be seen simply
by looking at parent relations
 2. maybe use the roles forward/backward? I don't think these are
used for much any more
 3. what do we gain? I think this can more easily be solved by
simply adding another tag such as shared=yes which can tell
the software that there are route relations that are intended
to be treated as just one big way. see below for a more
detailed explanation.
 4. I don't see a reason to limit the nesting, I imagine in most
use cases, the benefit of sharing duplicate relation data
probab

Re: [Tagging] Superroutes - good, bad or ugly?

[Kevin Kenny]

On Fri, Mar 15, 2019 at 9:05 AM Sarah Hoffmann  wrote:
> The disadvantage of all these proposals is that it is impossible
> to figure out if a relation is a route or only part of a superroute
> without looking at the parent.

At the risk of beating a dead horse, mightn't this be an argument in
favour of having osm2pgsql (optionally) preserve relation information
at least for routes? If there were an easy place in PostGIS to look
for the information, then needing to look at the parent wouldn't have
to be a show-stopper. Otherwise, this sounds like an argument for
structuring the data around the limitations of downstream tools.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

yeah roughly so. in terms of mapping, no. as relations are on somewhat 
of a 'meta' level though, I considered it mostly due to the fact people 
seem to feel some sort of tag is needed. I (personally) wondered whether 
the use of type=route would require the use of a route tag no matter 
what (or I guess... should we just use a new type=shared? people seemed 
to preferably not want an entire new relation type though). but yeah the 
idea is essentially that the shared segments may be used in place of the 
identical set of ways independent of whatever the route wants to use 
them for. as it defeats the purpose for public transport somewhat if the 
bus stops/stop positions are still defined uniquely for each route the 
idea is that you can also make shared relations for those. the original 
idea was that you have a relation connecting two separate bus stop and 
way relations but after some thought... bus stops are always (unless 
there's a very extreme earthquake maybe? but I think if it's strong 
enough to physically switch bus stops we have more important things to 
worry about) attached to the same ways. I will upload a slightly updated 
version, just bear with me while I make sure I've checked all my emails 
and update it. I will reply to myself with it


On 3/15/19 3:22 PM, Peter Elderson wrote:


This seems to boil down to: You can put any sequence of connected ways 
in a package (shared route segment) and use that package in any route 
to replace these ways themselves.


You would need to allow all types of route relations to contain ways 
and shared segment relations.


I'm not sure if you would need any special tag to indicate it's 
shared. If it's used more than once, it's shared, right?


Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 15:38 schreef seirra blake 
mailto:sophietheopos...@yandex.com>>:


I can see *a lot* of shared routes in my area because most of the
buses heavily use a star topography (everything must take you to a
central station) as opposed to a hybrid mesh/star topography
(everywhere has access to a service to a central station, but
there are circular routes to allow quicker travel in some
circumstances). for example my local service has one incredibly
early train station detour (presumably for long distance
commuters), the two main routes (incoming/outgoing) and a route
that stops at the bus depot. all 4 of these routes share a large
part of it and that's just one route number! such route segments
could help shrink and simplify maintaining the relations a lot.
for example if there's a detour due to roadworks, you don't have
to edit the very large number of relations individually, (our bus
station has around 20 bays, each taking multiple services...) just
the shared child relations. I don't think we need a  specially
labelled super route relation, but perhaps we do need a way to
tell the data user that a segment is shared. these are the
problems I see:

 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the
stop positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

 1. if a route is shared, tags should be minimal and only related
to the physical route itself perhaps not even including the
usual route tag (AFAIK wouldn't just about any route relation
in existence define the route tag? so this would just be
another pointer to the software that this isn't your regular
route. but maybe it still is best to tag it, in which case
maybe route=shared?), rather than things such as what bus
routes it is part or anything, this can easily be seen simply
by looking at parent relations
 2. maybe use the roles forward/backward? I don't think these are
used for much any more
 3. what do we gain? I think this can more easily be solved by
simply adding another tag such as shared=yes which can tell
the software that there are route relations that are intended
to be treated as just one big way. see below for a more
detailed explanation.
 4. I don't see a reason to limit the nesting, I imagine in most
use cases, the benefit of sharing duplicate relation data
probably outweighs any impact from processing nesting
 5. if a shared route is used for both a numbered road route and
public transport it's probably unfair on the road user that
doesn't need them if they are included. also this would make
it difficult to work out where to place it in a public
transport V2 relation.. as they have stops at the top, ways at
the bottom but this has both!

so here's an indented, somewhat simplified example of how 

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

Let's do some research how "cycleway:left=opposite_lane"
entered the Bicycle wiki documentation.  The relevant edit
was made in June 2013 [1].

Before that, Bicycle documentation has lived 5 years
from its incarnation without recommending opposite_lane
in combination with cycleway:left or cycleway:right.

But its more intriguing /how/ the change was made. It
did not enter as an addition, but it rather changed a
recommendation that had previously looked like

{{Tag|cycleway|:=left||lane}} + {{Tag|oneway|:=bicycle||no}}

This lacks the explicit cycleway:left:oneway=-1, but apart
from that is in sync with the changes I have done on 13/03/19.
It shows that my edit has indeed been far more conservative
than what most people involved in the current discussion seem
to realize.

See [2] to find the full state the documentation has been in
for cases M3a and M3b at the end of June 2013, before the tag
cycleway:left=opposite_lane entered the page and diluted the
value set for that key.  [2] had still recommended/favoured
legacy cycleway=* over cycleway:{left,right}=*, which means
[1] did not only introduce "opposite_lane" as a value but also
moved the recommendation flag from the legacy alternative to
the suffixed variants.


At the beginning of July 2013 there were about 370 uses of
cycleway:left=opposite_lane according to [3], an overpass
attic query.  These uses piled up from 37 ways using the tag
at the beginning of 2012 [4].  To judge the growth rate one
has to put this in relation to the documented method in this
time period, given by [2].

These findings suggest, that the author of [1] based his/her
documentation change on empirical research on the data.  If
370 uses out-weighed the previous tagging scheme documented
at that time is in doubt, but at least we can state with
confidence that the wiki documentation did not change prior
to employment of the tag in the data.


Regards,
cmuelle8


[1] 
https://wiki.openstreetmap.org/w/index.php?title=Bicycle&diff=next&oldid=920716
[2] https://wiki.openstreetmap.org/w/index.php?title=Bicycle&oldid=920716
[3] http://overpass-turbo.eu/s/H1U
[4] http://overpass-turbo.eu/s/H1W
 
 

> On 15/3/19, 15:34, Mateusz Konieczny wrote:
> 
> Is it originally documented as open list,
> inheriting cycleway values, excluding
> some cycleway values, closed list
> or left unclear?
> 
> If left unclear then I would not assume that
> all agree with me.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

key: almost tagging should occur here | data may be reused in parent | 
data may be reused in parent and any 'adjacent' (with the same letter) 
parent

//

/public transport network///[A]/
/

   /route_master=public transport /[B]

   /route variant/ [C]

   _combined stop/way relation suitable for public transport
   v2_ [E]

   _*shared way relation*_ [G]


/road network///[A]/
/

   /road /[C]

   _*shared way relation*_ [G]*
   *


/cycle network//**/[A]/*
*/

   /cycle route /[C]

   __

   __

   *_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways, but 
the software probably should be able to work that out)


[E/F/G]: route=shared (this is considered in case type=route explicitly 
requires a route=* key)


_

notes:

 * [G] may be infinitely nested as required to prevent duplicate sets
   of ways (although this should rarely be required)
 * [G] may require names in some cases and should always require
   type=route, but should include no other tags unless it very
   specifically relates to only the members of the relation and can't
   be included in any parent relation (unicorns are probably more common)
 * [G] should almost always not be used for a single way unless it will
   assist in maintainability. if a
 * I don't believe route_master=public transport actually exists, but
   the same concept should work for any public transport
 * the route=* tag should not be required until you move up to [C],
   shared way relations and bus stop relations should be open to any
   route type to increase re-usability
 * as they are just a connected line of ways, shared way relations
   should be usable in either direction, the direction to use could be
   specified via a role. although reusable for routes going in the same
   direction, [E] will rarely be reusable for both directions of a
   route because it contains both platforms and stops, and platforms
   usually differ depending on direction.
 * if this becomes accepted it may become a good idea to specify a
   members limit for relations (at which point it should be split up).
   such ways should probably
 * I may consider adding a rough idea on perceived pros/cons, depending
   on demand
 * I may add a more visual version, depending on demand
 * I may add an actual example, depending on demand (if you wish to add
   your own as well, or an inspired version please base it heavily on
   reality if it is on main OSM. do not make any existing route
   relations unusable)

_

changelog:

#0

 * initial concept

#1

 * removed [D] and [F]. [D] was meant to be removed prior to sending,
   [F] is not required.
 * added a few more notes so it may be referred to on its own
 * the bus example applies to any public transport really, adjust
   language accordingly
 * warned against damaging existing relations' usability/the creation
   of fictional data
 * added extra details on a request if needed basis
 * added this changelog and relevant versioning to help people keep
   track. this should be traceable to the (unlabelled) version 0

special thanks:

 * you may request your name here and optionally credits for ideas you
   contributed (being kept in an opt in basis in case people don't want
   their names shown)

On 3/15/19 2:37 PM, seirra blake wrote:


I can see *a lot* of shared routes in my area because most of the 
buses heavily use a star topography (everything must take you to a 
central station) as opposed to a hybrid mesh/star topography 
(everywhere has access to a service to a central station, but there 
are circular routes to allow quicker travel in some circumstances). 
for example my local service has one incredibly early train station 
detour (presumably for long distance commuters), the two main routes 
(incoming/outgoing) and a route that stops at the bus depot. all 4 of 
these routes share a large part of it and that's just one route 
number! such route segments could help shrink and simplify maintaining 
the relations a lot. for example if there's a detour due to roadworks, 
you don't have to edit the very large number of relations 
individually, (our bus station has around 20 bays, each taking 
multiple services...) just the shared child relations. I don't think 
we need a  specially labelled super route relation, but perhaps we do 
need a way to tell the data user that a segment is shared. these are 
the problems I see:


 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the stop
positions and bus sto

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

When I start mapping a bus line, I have several route relations which
contain all the stops for each variation in itinerary.

When I add the ways, it would be nice to reuse subroute relations for the
parts where ways are shared between lines.

When I come back later and I want to compare whether the number of
variations for a line is still the same, I want to compare against
sequences of stops in the route relations, hence the reason why I would not
add the stops to the subroute segments. (Compare against data from the
operator or GTFS)

We also have 'express' lines that skip stops. if the stops are put in the
subroute relations, then they can not be reused for those lines.

As far as I'm concerned, the sequence of stops is the 'signature' defining
each variation in itinerary.

Polyglot

On Fri, Mar 15, 2019 at 6:55 PM seirra blake 
wrote:

> key: almost tagging should occur here | data may be reused in parent |
> data may be reused in parent and any 'adjacent' (with the same letter)
> parent
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *shared way relation* [G]
>
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
> *cycle route *[C]
>
> *shared way relation* [G]
>
>
> _
>
> potential new tags that may be required:
>
> [C]: shared=yes (to tell the software there is use of shared ways, but the
> software probably should be able to work that out)
>
> [E/F/G]: route=shared (this is considered in case type=route explicitly
> requires a route=* key)
>
>
> _
>
> notes:
>
>- [G] may be infinitely nested as required to prevent duplicate sets
>of ways (although this should rarely be required)
>- [G] may require names in some cases and should always require
>type=route, but should include no other tags unless it very specifically
>relates to only the members of the relation and can't be included in any
>parent relation (unicorns are probably more common)
>- [G] should almost always not be used for a single way unless it will
>assist in maintainability. if a
>- I don't believe route_master=public transport actually exists, but
>the same concept should work for any public transport
>- the route=* tag should not be required until you move up to [C],
>shared way relations and bus stop relations should be open to any route
>type to increase re-usability
>- as they are just a connected line of ways, shared way relations
>should be usable in either direction, the direction to use could be
>specified via a role. although reusable for routes going in the same
>direction, [E] will rarely be reusable for both directions of a route
>because it contains both platforms and stops, and platforms usually differ
>depending on direction.
>- if this becomes accepted it may become a good idea to specify a
>members limit for relations (at which point it should be split up). such
>ways should probably
>- I may consider adding a rough idea on perceived pros/cons, depending
>on demand
>- I may add a more visual version, depending on demand
>- I may add an actual example, depending on demand (if you wish to add
>your own as well, or an inspired version please base it heavily on reality
>if it is on main OSM. do not make any existing route relations unusable)
>
>
> _
>
> changelog:
>
> #0
>
>- initial concept
>
> #1
>
>- removed [D] and [F]. [D] was meant to be removed prior to sending,
>[F] is not required.
>- added a few more notes so it may be referred to on its own
>- the bus example applies to any public transport really, adjust
>language accordingly
>- warned against damaging existing relations' usability/the creation
>of fictional data
>- added extra details on a request if needed basis
>- added this changelog and relevant versioning to help people keep
>track. this should be traceable to the (unlabelled) version 0
>
> special thanks:
>
>- you may request your name here and optionally credits for ideas you
>contributed (being kept in an opt in basis in case people don't want their
>names shown)
>
> On 3/15/19 2:37 PM, seirra blake wrote:
>
> I can see *a lot* of shared routes in my area because most of the buses
> heavily use a star topography (everything must take you to a central
> station) as opposed to a hybrid mesh/star topography (everywhere has access
> to a service to a central station, but there are circular routes to allow
> quicker travel in some circumstances). for example my local service has one
> incredibly early train station detour (presumably for long distance

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Hubert87]

Hi again,

lets ignore the cycleway:left:oneway=-1 for a moment and just consider 
cycleway:left=lane vs cycleway:left=opposite_lane.


To me the main difference is, that cycleway:left=opposite_lane can only 
be used when the carriageway itself is a one way street (legally speaking).


because of that, opposite_lane is conditioned on and mixing two 
conceptional different physical objects (cycleway and carriageway), that 
are only represented as one osm way.


Remove oneway=yes (/form the carriageway/) and you need to change 
cycleway:left=opposite_lane into cycleway:left=lane, too.


Also, have you considered, how you would tag a dual-cycleway on the 
left-hand side of a one way carriageway?(eg cycleway:left=? + 
cycleway:left:oneway=no)



Yours

Hubert87

(P.S. I'm assuming right-hand-traffic)

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 19:42, Hubert87  wrote:
> 
> Also, have you considered, how you would tag a dual-cycleway on the left-hand 
> side of a one way carriageway?(eg cycleway:left=? + cycleway:left:oneway=no)


https://taginfo.openstreetmap.org/keys/cycleway%3Aleft%3Alanes

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Christian Müller]

First use of cycleway:left=opposite_lane appears
to be one in Böblingen near Stuttgart in November
2009 [1].  About one year later it was applied to
a geometry in the center of Paris [2].

Traces of cycleway:left:oneway=* date back to late
2010, north of Edinburgh [3], about two months after
the edit in Paris.


So both uses can be found in the data long before
June 2013, when opposite_lane suddenly was favoured
to be documented in the osm wiki, for whatever reason
that might have been.


Regards,
cmuelle8


[1] https://www.openstreetmap.org/api/0.6/way/44331705/history (version 1)
[2] https://www.openstreetmap.org/api/0.6/way/19729421/history (version 10)
[3] http://overpass-turbo.eu/s/H24
 
 

> On 15/3/19, 15:34, Mateusz Konieczny wrote:
> 
> Is it originally documented as open list,
> inheriting cycleway values, excluding
> some cycleway values, closed list
> or left unclear?
> 
> If left unclear then I would not assume that
> all agree with me.

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

The just-a-chain-of-ways relation doesn't have to be shared. It's
shareable, but the sharing really is of no consequence.

I think software needs a tag to control the selection for the purpose it
serves, OR allow any route relation without a type within all route types
it supports.

I would indeed go for an explicit label, just not "shared". Maybe "general"
or "chain" or "basic" or "segment", "fragment", "elementary", just not
something that says how it's going to be used.

Editors can keep their check that there MUST be a supported type tag, and
add that type=basic (or whatever word is chosen) can only have a single
consecutive ordered collection of ways. Other routes of any type should be
allowed to contain ways AND basic routes, apart from more complex checking
for particular cases such as PT variants.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

I can understand your concern. I did actually consider mentioning 
something about skipping stops.. but I forgot to, I spent a good few 
hours on the original, so I guess my thoughts got easily distracted. 
I'll make an example based on the real data to help illustrate the idea, 
but I'll also include an imaginary express version that only stops at a 
few major stops. provided everything goes as planned I'll link to a 
fairly realistic example in version 4 (I need version 3 to fix a mistake 
I made). I understand that you may not want to follow each version due 
to being busy or whatever, so until the example is ready any future 
version will be 3.x (so for example: 3.0,3.1,3.2...); this way you'll be 
able to Ctrl+f and search for '#4', if there's no #4 it isn't ready yet 
and so you won't waste your time reading through the changelog for it. 
as for seeing all the stops/being able to compare to official feeds, 
that may fall more under what the renderer is expected to do, as it 
should already be reading all the segments as one whole route.


On 3/15/19 6:30 PM, Jo wrote:
When I start mapping a bus line, I have several route relations which 
contain all the stops for each variation in itinerary.


When I add the ways, it would be nice to reuse subroute relations for 
the parts where ways are shared between lines.


When I come back later and I want to compare whether the number of 
variations for a line is still the same, I want to compare against 
sequences of stops in the route relations, hence the reason why I 
would not add the stops to the subroute segments. (Compare against 
data from the operator or GTFS)


We also have 'express' lines that skip stops. if the stops are put in 
the subroute relations, then they can not be reused for those lines.


As far as I'm concerned, the sequence of stops is the 'signature' 
defining each variation in itinerary.


Polyglot

On Fri, Mar 15, 2019 at 6:55 PM seirra blake 
mailto:sophietheopos...@yandex.com>> wrote:


key: almost tagging should occur here | data may be reused in
parent | data may be reused in parent and any 'adjacent' (with the
same letter) parent

/public transport network///[A]/
/

/route_master=public transport /[B]

/route variant/ [C]

_combined stop/way relation suitable for public
transport v2_ [E]

_*shared way relation*_ [G]


/road network///[A]/
/

/road /[C]

_*shared way relation*_ [G]*
*


/cycle network//**/[A]/*
*/

/cycle route /[C]

__

__

*_shared way relation_* [G]


_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways,
but the software probably should be able to work that out)

[E/F/G]: route=shared (this is considered in case type=route
explicitly requires a route=* key)


_

notes:

  * [G] may be infinitely nested as required to prevent duplicate
sets of ways (although this should rarely be required)
  * [G] may require names in some cases and should always require
type=route, but should include no other tags unless it very
specifically relates to only the members of the relation and
can't be included in any parent relation (unicorns are
probably more common)
  * [G] should almost always not be used for a single way unless
it will assist in maintainability. if a
  * I don't believe route_master=public transport actually exists,
but the same concept should work for any public transport
  * the route=* tag should not be required until you move up to
[C], shared way relations and bus stop relations should be
open to any route type to increase re-usability
  * as they are just a connected line of ways, shared way
relations should be usable in either direction, the direction
to use could be specified via a role. although reusable for
routes going in the same direction, [E] will rarely be
reusable for both directions of a route because it contains
both platforms and stops, and platforms usually differ
depending on direction.
  * if this becomes accepted it may become a good idea to specify
a members limit for relations (at which point it should be
split up). such ways should probably
  * I may consider adding a rough idea on perceived pros/cons,
depending on demand
  * I may add a more visual version, depending on demand
  * I may add an actual example, depending on demand (if you wish
to add your own as well, or an inspired version please base it
heavily on reality if it is on main OSM. do not make

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

maybe we can have roles to state whether the tags of the referenced object 
should apply to the relation or if only the geometry matters. These superroutes 
could be also useful for admin relations 

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Hubert87]

Interesting.

But I actually miss wrote. I meant a two-way cycleway.

Also, but OT, lanes-count should only be used for double tracked 
vehicles afaik. In contrast to the *:lanes=*|*|* scheme.



Am 15.03.2019 um 19:55 schrieb Martin Koppenhoefer:



sent from a phone

On 15. Mar 2019, at 19:42, Hubert87 > wrote:


Also, have you considered, how you would tag a dual-cycleway on the 
left-hand side of a one way carriageway?(eg cycleway:left=? + 
cycleway:left:oneway=no)



https://taginfo.openstreetmap.org/keys/cycleway%3Aleft%3Alanes

Cheers, Martin

___
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] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 20:20, Hubert87  wrote:
> 
> Also, but OT, lanes-count should only be used for double tracked vehicles 
> afaik. In contrast to the *:lanes=*|*|* scheme.


You have to distinguish lanes count on roads from that on cycle infrastructure. 
Admittedly, they are not many, around 5000 on cycleways currently.


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

Re: [Tagging] Feature Proposal - RFC - police=*

[Ferdinand Schicke]

Woudn’t  it be possibel to do an Automated edit where we add fixme:Police to 
all amenity Police this shoud Speed up the Adoption and allow for the 
Elimination of the amenity=Police.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

hmm... I'm not quite sure on what would be best. I do see your point in 
the case of just splitting very long ways there, they would not be 
'shared' at all. to the best of my knowledge type=* is intended to 
exclusively define the relation. in all circumstances that we have 
discussed, it still joins up to make a route, so perhaps its best not to 
change the relation type. the chain idea is a nice one, but that would 
make the smaller bits that join together... links. that may get 
confusing quite fast; or chain-links, which might sound a bit too much 
like we're talking about a physical chain.  part might be a good 
candidate, it's already there in the sense of building:part=*; so 
following similar convention we could have route:part=yes, that seems 
pretty intuitive; although we can probably go a step further and just do 
a combination of type=route and route=part, I'll probably use that in 
the example I make.


On 3/15/19 7:03 PM, Peter Elderson wrote:
The just-a-chain-of-ways relation doesn't have to be shared. It's 
shareable, but the sharing really is of no consequence.


I think software needs a tag to control the selection for the purpose 
it serves, OR allow any route relation without a type within all route 
types it supports.
I would indeed go for an explicit label, just not "shared". Maybe 
"general" or "chain" or "basic" or "segment", "fragment", 
"elementary", just not something that says how it's going to be used.


Editors can keep their check that there MUST be a supported type tag, 
and add that type=basic (or whatever word is chosen) can only have a 
single consecutive ordered collection of ways. Other routes of any 
type should be allowed to contain ways AND basic routes, apart from 
more complex checking for particular cases such as PT variants.


___
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] Superroutes - good, bad or ugly?

[seirra blake]

hmm maybe. version 4 will include a detailed example, once that is 
available feel free what would be missing for that purpose


On 3/15/19 7:19 PM, Martin Koppenhoefer wrote:

maybe we can have roles to state whether the tags of the referenced object 
should apply to the relation or if only the geometry matters. These superroutes 
could be also useful for admin relations

Cheers, Martin
___
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] Feature Proposal - RFC - police=*

[Mateusz Konieczny]

Mar 15, 2019, 8:25 PM by ferdi98...@gmail.com:

>
> Woudn’t  it be possibel to do an Automated edit where we add fixme:Police to 
> all amenity Police this shoud Speed up the Adoption and allow for the 
> Elimination of the amenity=Police.
>
>
In theory yes.

See https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct 


In practice it is highly unlikely that people would consider it as something 
desirable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

key: /almost all tagging should occur here/ | _data may be reused in 
parent_ | *data may be reused in parent and any 'adjacent' (with the 
same letter) parent*


/public transport network///[A]

   /route_master=public transport /[B]

   /route variant/ [C]

   _combined stop/way relation suitable for public transport
   v2_ [E]

   _*shared way relation*_ [G]

/road network///[A]

   /road /[C]

   _*shared way relation*_ [G]


/cycle network//**/[A]

   /cycle route /[C]

   *_shared way relation_* [G]

_

potential new use of tags that may be required:

[E/G]: type=route + route=part

_

notes:

 * [G] may be infinitely nested as required to prevent duplicate sets
   of ways (although this should rarely be required)
 * [G] may require names in some cases and should always require
   type=route, but should include no other tags unless it very
   specifically relates to only the members of the relation and can't
   be included in any parent relation (unicorns are probably more common)
 * [G] should almost always not be used for a single way unless it will
   assist in maintainability. if a
 * I don't believe route_master=public transport actually exists, but
   the same concept should work for any public transport
 * the route=* tag should not be required until you move up to [C],
   shared way relations and bus stop relations should be open to any
   route type to increase re-usability
 * as they are just a connected line of ways, shared way relations
   should be usable in either direction, the direction to use could be
   specified via a role. although reusable for routes going in the same
   direction, [E] will rarely be reusable for both directions of a
   route because it contains both platforms and stops, and platforms
   usually differ depending on direction.
 * if this becomes accepted it may become a good idea to specify a
   members limit for relations (at which point it should be split up).
   such ways should probably
 * I may consider adding a rough idea on perceived pros/cons, depending
   on demand
 * I may add a more visual version, depending on demand
 * example will be coming with version 4 (if you wish to add your own
   as well, or an inspired version please base it heavily on reality if
   it is on main OSM. do not make any existing route relations unusable)

_

changelog:

#2

 * fix mistake in key
 * add missing formatting to key
 * remove redundant reference to [F]
 * specify when example should be live
 * update potentially needed tags following discussion
 * remove mention of shared=yes, this does not need to be used in the
   newest version
 * reorder changelog so it's newest first

#1

 * removed [D] and [F]. [D] was meant to be removed prior to sending,
   [F] is not required.
 * added a few more notes so it may be referred to on its own
 * the bus example applies to any public transport really, adjust
   language accordingly
 * warned against damaging existing relations' usability/the creation
   of fictional data
 * added extra details on a request if needed basis
 * added this changelog and relevant versioning to help people keep
   track. this should be traceable to the (unlabelled) version 0

#0

 * initial concept

special thanks:

 * you may request your name here and optionally credits for ideas you
   contributed (being kept in an opt in basis in case people don't want
   their names shown)

On 3/15/19 5:54 PM, seirra blake wrote:


key: almost tagging should occur here | data may be reused in parent | 
data may be reused in parent and any 'adjacent' (with the same letter) 
parent


/public transport network///[A]/
/

/route_master=public transport /[B]

/route variant/ [C]

_combined stop/way relation suitable for public transport
v2_ [E]

_*shared way relation*_ [G]


/road network///[A]/
/

/road /[C]

_*shared way relation*_ [G]*
*


/cycle network//**/[A]/*
*/

/cycle route /[C]

__

__

*_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways, but 
the software probably should be able to work that out)


[E/F/G]: route=shared (this is considered in case type=route 
explicitly requires a route=* key)


_

notes:

  * [G] may be infinitely nested as required to prevent duplicate sets
of ways (although this should rarely be required)
  * [G] may require names in some cases and should always require
type=route, but should include no other ta

Re: [Tagging] Feature Proposal - RFC - police=*

[Lionel Giard]

I don't see why people would care that much about a tag that could be seen
as a sub-tag at first (look at all the chain of tag that we have like :
man_made=street_cabinet + street_cabinet=power + power=substation +
substation=minor_distribution). So someone don't like the
"amenity=police" + police=station, i don't understand the reason. And even
if we consider that we want to remove the amenity=police in the future,
that's just what has been done for others big tag chains, where the higher
tag is not always added as it is implicit.

Otherwise, i like this proposal, as it looks to be an improvement to the
current scheme as it add a way to differentiate all these type of police
structures.

Le ven. 15 mars 2019 à 20:44, Mateusz Konieczny  a
écrit :

>
> Mar 15, 2019, 8:25 PM by ferdi98...@gmail.com:
>
> Woudn’t  it be possibel to do an Automated edit where we add fixme:Police
> to all amenity Police this shoud Speed up the Adoption and allow for the
> Elimination of the amenity=Police.
>
> In theory yes.
>
> See https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> In practice it is highly unlikely that people would consider it as
> something desirable.
> ___
> 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] Superroutes - good, bad or ugly?

[Peter Elderson]

Looks good.

Vr gr Peter Elderson


Op vr 15 mrt. 2019 om 21:05 schreef seirra blake <
sophietheopos...@yandex.com>:

> key: *almost all tagging should occur here* | *data may be reused in
> parent* | *data may be reused in parent and any 'adjacent' (with the same
> letter) parent*
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *shared way relation* [G]
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
> *cycle route *[C]
>
> *shared way relation* [G]
>
>
> _
>
> potential new use of tags that may be required:
>
> [E/G]: type=route + route=part
>
>
> _
>
> notes:
>
>- [G] may be infinitely nested as required to prevent duplicate sets
>of ways (although this should rarely be required)
>- [G] may require names in some cases and should always require
>type=route, but should include no other tags unless it very specifically
>relates to only the members of the relation and can't be included in any
>parent relation (unicorns are probably more common)
>- [G] should almost always not be used for a single way unless it will
>assist in maintainability. if a
>- I don't believe route_master=public transport actually exists, but
>the same concept should work for any public transport
>- the route=* tag should not be required until you move up to [C],
>shared way relations and bus stop relations should be open to any route
>type to increase re-usability
>- as they are just a connected line of ways, shared way relations
>should be usable in either direction, the direction to use could be
>specified via a role. although reusable for routes going in the same
>direction, [E] will rarely be reusable for both directions of a route
>because it contains both platforms and stops, and platforms usually differ
>depending on direction.
>- if this becomes accepted it may become a good idea to specify a
>members limit for relations (at which point it should be split up). such
>ways should probably
>- I may consider adding a rough idea on perceived pros/cons, depending
>on demand
>- I may add a more visual version, depending on demand
>- example will be coming with version 4 (if you wish to add your own
>as well, or an inspired version please base it heavily on reality if it is
>on main OSM. do not make any existing route relations unusable)
>
>
> _
>
> changelog:
>
> #2
>
>- fix mistake in key
>- add missing formatting to key
>- remove redundant reference to [F]
>- specify when example should be live
>- update potentially needed tags following discussion
>- remove mention of shared=yes, this does not need to be used in the
>newest version
>- reorder changelog so it's newest first
>
> #1
>
>- removed [D] and [F]. [D] was meant to be removed prior to sending,
>[F] is not required.
>- added a few more notes so it may be referred to on its own
>- the bus example applies to any public transport really, adjust
>language accordingly
>- warned against damaging existing relations' usability/the creation
>of fictional data
>- added extra details on a request if needed basis
>- added this changelog and relevant versioning to help people keep
>track. this should be traceable to the (unlabelled) version 0
>
> #0
>
>- initial concept
>
> special thanks:
>
>- you may request your name here and optionally credits for ideas you
>contributed (being kept in an opt in basis in case people don't want their
>names shown)
>
> On 3/15/19 5:54 PM, seirra blake wrote:
>
> key: almost tagging should occur here | data may be reused in parent |
> data may be reused in parent and any 'adjacent' (with the same letter)
> parent
>
> *public transport network* [A]
>
> *route_master=public transport *[B]
>
> *route variant* [C]
>
> *combined stop/way relation suitable for public transport v2* [E]
>
> *shared way relation* [G]
>
>
> *road network* [A]
>
> *road *[C]
>
> *shared way relation* [G]
>
>
> *cycle network* [A]
>
> *cycle route *[C]
>
> *shared way relation* [G]
>
>
> _
>
> potential new tags that may be required:
>
> [C]: shared=yes (to tell the software there is use of shared ways, but the
> software probably should be able to work that out)
>
> [E/F/G]: route=shared (this is considered in case type=route explicitly
> requires a route=* key)
>
>
> _
>
> notes:
>
>- [G] may be infinitely nested as required to prevent 

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Graeme Fitzpatrick]

On Sat, 16 Mar 2019 at 01:36, Mateusz Konieczny 
wrote:

> In general, people unfortunately rarely
> document mailing list discussions on wiki,
> even in cases of a clear consensus.
> What is quite weird, given that editing wiki has
> usually much greater impact on tag usage
> than commenting on mailing list.
>

I think people may be worried that if they go in & edit *The Wiki *:-),  based
on their perception of the mailing list consensus, then they may be
starting an edit war with others who either didn't agree, or don't belong
to the list, so aren't aware of the discussion?

& also, as has been mentioned many times, the wiki is *not* the most
user-friendly thing to edit :-(

Thanks

Graeme

>
> ___
> 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] Feature Proposal - RFC - police=*

[Graeme Fitzpatrick]

On Sat, 16 Mar 2019 at 02:17, Jan S  wrote:

>
> Would it be a possible solution to keep amenity=police for public-facing
> police stations only, but invite mappers on the wiki to nevertheless add
> police=station, so that in the future the majority of police stations will
> hopefully also carry the police=station tag?
>

As I mentioned earlier though, rendering would also have to be changed, so
that the only things that renders with the Police icon is the actual
public-facing Police stations.

The Police warehouse, holding yard, vehicle maintenance facility, driver
training track, Academy, Mounted Police stables etc etc should not be
rendered with the Police icon, as they are not open to the public.

Thanks

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