Re: [Tagging] Green lanes (OT)

[Paul Johnson]

On Sun, Mar 17, 2019, 20:12 Mateusz Konieczny 
wrote:

>
>
>
> Mar 18, 2019, 12:48 AM by ba...@ursamundi.org:
>
>
>
> On Sun, Mar 17, 2019 at 5:33 PM Mateusz Konieczny 
> wrote:
>
> Note that bicycle only lanes are not included in lanes tag count (only
> full lanes are counted).
>
>
> Lets fix this error by omission already.  Not counting all lanes serves
> *nobody*.
>
> Redefining lanes tag from "count of full lanes" to "count of all lanes"
> while it is
> used 9 million times is also a poor idea.
>

The premise that bike lanes aren't lanes is an inherently flawed one to
start with.  Up there with defining routes as a ref=* tag on constitutant
ways, and yet, route relations are a thing with the need for tagging ref=*
waning.  The idea that this is an unfixible problem is short sighted.

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

Re: [Tagging] Green lanes (OT)

[Mateusz Konieczny]

Mar 18, 2019, 12:48 AM by ba...@ursamundi.org:

>
>
> On Sun, Mar 17, 2019 at 5:33 PM Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>> Note that bicycle only lanes are not included in lanes tag count (only full 
>> lanes are counted).
>>
>
> Lets fix this error by omission already.  Not counting all lanes serves > 
> nobody> . 
>
Redefining lanes tag from "count of full lanes" to "count of all lanes" while 
it is
used 9 million times is also a poor idea.

New tag like all_lanes or something similar would likely be a better idea.

https://taginfo.openstreetmap.org//search?q=lanes
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Green lanes (OT)

[Paul Johnson]

On Sun, Mar 17, 2019 at 5:33 PM Mateusz Konieczny 
wrote:

> Note that bicycle only lanes are not included in lanes tag count (only
> full lanes are counted).
>

Lets fix this error by omission already.  Not counting all lanes serves
*nobody*.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal Approved - boundary=aboriginal_lands

[Paul Johnson]

OK, all the tribal boundaries in Oklahoma are updated.  This will be handy
depending on how SCOTUS rules later this year on tribal issues as some of
these lines might become state lines.

On Sun, Mar 17, 2019 at 3:32 PM Paul Johnson  wrote:

> I'm currently working on conflating the boundaries in Oklahoma right now,
> got most of the northeastern ones handled.
>
> On Sat, Mar 16, 2019 at 11:13 PM Alan McConchie 
> wrote:
>
>> After a few months of discussion and refinement in the default OSM style
>> sheet, and then a few more weeks of waiting for the styles to percolate to
>> the rendering servers, we can now see aboriginal areas showing up on the
>> map! Please take a moment to check the map in any parts of the world you're
>> familiar with, to see if the aboriginal_lands and protect_class=24 features
>> are showing up as we expect them to, or if there are any obvious ones
>> missing.
>>
>> Again, thanks to everyone who help get this tag discussed, approved, and
>> finally added to the map!
>>
>> Alan
>>
>> > On Dec 13, 2018, at 4:20 PM, Alan McConchie 
>> wrote:
>> >
>> > The voting period for boundary=aboriginal_lands has now closed, and
>> there were 45 votes in favor and 7 against, so the tag has now been
>> approved.
>> >
>> > I created the new wiki page for the tag here:
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands
>> >
>> > The map rendering still needs a bit of discussion about colors (to
>> avoid color conflict with the same brown used by zoos and theme parks) but
>> this is not the place for that conversation. The github issue remains open
>> for debate here:
>> https://github.com/gravitystorm/openstreetmap-carto/issues/3520
>> >
>> > So what's next? It now appears that "boundary=aboriginal_lands" is
>> synonymous with "boundary=protected_area" + "protect_class=24", and both
>> tagging styles have roughly similar usage in the database. I'm curious to
>> see over time whether mappers start to use "boundary=aboriginal_lands" more
>> frequently, or if people keep using both. Perhaps at some point in the
>> future we can have a discussion about whether to deprecate the
>> "boundary=protected_area" + "protect_class=24" approach, or if we should
>> just keep supporting both methods in simultaneously. But I'm not in a hurry
>> to start that discussion right now.
>> >
>> >
>> > Thanks to everyone who took part in this discussion and who voted on
>> the proposal!
>> >
>> > Alan
>> >
>> >
>> >> On Nov 24, 2018, at 4:38 PM, Alan McConchie 
>> wrote:
>> >>
>> >> The tag boundary=aboriginal_lands has been discussed on-and-off for a
>> long time in OSM. I'd like to raise the topic one last time and hopefully
>> come to some consensus about it.
>> >>
>> >> The tag proposal on the wiki dates from 2008, but the original
>> proposal was from the user Sam Vekemans (username acrosscanadatrails) who
>> is no longer participating in OpenStreetMap, as far as I can tell. He never
>> moved the proposal to a vote, so the page has remained in the proposal
>> state all this time.
>> >>
>> >> Here's the proposal:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands
>> >>
>> >> (I've tried to updated the wiki page somewhat, but leaving the
>> discussion intact)
>> >>
>> >> In the following years, some people have started using that proposed
>> tag, mostly in Canada and somewhat in the United States.
>> >>
>> >> Here's the overpass query for boundary=aboriginal_lands:
>> http://overpass-turbo.eu/s/DV4
>> >>
>> >> There has also been extensive discussion over the years on the
>> boundary=aboriginal_lands page, and it seems like the consensus is that the
>> tag is necessary and better than any alternatives. But it was never voted
>> on as a proposal.
>> >>
>> >> In the intervening years, tagging native reservations with
>> boundary=protected_area + protect_class=24 has also gained popularity. This
>> tag combination seems to be popular in South America, Australia, and also
>> in parts of the United States. I can't find any evidence for why people
>> chose this tag combination instead of boundary=aboriginal_lands. It appears
>> that the tags are pretty much interchangeable. Most of the features in
>> Brazil however are tagged incorrectly for the renderer, mixing
>> leisure=nature_reserve with protect_class=24, so that the areas show up on
>> the default renderer with the nature reserve green style.
>> >>
>> >> Here's the overpass query for protect_class=24:
>> http://overpass-turbo.eu/s/DV5
>> >>
>> >> Wiki page for boundary=protected_area:
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
>> >>
>> >> In 2014, there were three messages on the tagging mailing list, from
>> Paul Johnson and Clifford Snow.
>> https://lists.openstreetmap.org/pipermail/tagging/2014-November/020160.html
>> But at that time, we didn't come any answers.
>> >>
>> >> There seems to be no argument about whether or not aboriginal areas
>> are important features that should be 

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

[Jan S]

Am 17. März 2019 22:38:30 MEZ schrieb marc marc :
>Le 17.03.19 à 11:23, Jan S a écrit :
>> it wasn't obvious which were police stations and which were other
>facilities. In the end, I used Google maps... So there is practical
>relevance.
>
>i'm in favor of police=* (execpt the double tag for the station)
>but it's not a food relevance to promote a new schema because some
>objet 
>are wrongly mapped.
>so ifsomeone make a mistake with police=*, did we new a 3nd schema ?
>or just fix the mistake in osm ?

The issue here was that there is no real way to tag police facilities other 
than stations. There's office=government and government=police, but that 
doesn't fit in many cases either. So we have mistagging due to a lack of 
alternatives and no good way of repairing the bad tags. That's why in this 
particular case a new scheme is the appropriate way.

Best, Jan

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

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

[Jan S]

Am 17. März 2019 21:47:03 MEZ schrieb Graeme Fitzpatrick 
:
>There are some extensive Police areas, rather than just buildings - as
>mentioned, the Academy, driver training area, Mounted Police stable,
>which
>would usually include paddocks & so on.
>

I think this is similar to universities. There, buildings and the campus are 
tagged as amenity=university. Even big police facilities won't be as big as 
some unis. So I don't see an issue in tagging the area of a facility as 
police=*. The military, on the contrary, has huge areas under their exclusive 
control. So there, a landuse=military tag makes sense.

>They would all be tagged as police=facilities, but how would they
>render,
>as they wouldn't / shouldn't have the Police icon on them?

In general I think, someone who's a better designer than me would have to come 
up with a specific icon or icons for police facilities that are not police 
stations.

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

Re: [Tagging] Green lanes (OT)

[Mateusz Konieczny]

Mar 17, 2019, 9:28 PM by ba...@ursamundi.org:

>
>
> On Sun, Mar 17, 2019 at 2:43 AM Andrew Davidson <> thesw...@gmail.com 
> > > wrote:
>
>> On 17/3/19 4:30 pm, Graeme Fitzpatrick wrote:
>>  > Or even
>>  > >> 
>> https://www.google.com/maps/@-28.0766007,153.4447888,3a,20.7y,49.91h,89.96t/data=!3m6!1e1!3m4!1s3dPlQ9YxNBm-7lRm4GOUPg!2e0!7i13312!8i6656
>>  
>> 
>>  > 
>>  > & back another 30 m's or so
>>  > 
>>  > >> 
>> https://www.google.com/maps/@-28.0767024,153.296,3a,27.3y,57.48h,86.03t/data=!3m6!1e1!3m4!1sj4MRicAAxp4hNWeZbBs-zg!2e0!7i13312!8i6656
>>  
>> 
>>  > Did somebody say something about marking lanes by the way!
>>  
>>  Don't worry...the green paint has magical protective properties.
>>  
>>  We have some beauties in Canberra:
>>  
>>  >> 
>> https://www.google.com/maps/@-35.3034635,149.1818641,3a,60y,295.56h,87.06t/data=!3m6!1e1!3m4!1sERm_fITufjNl0fb1g58vjw!2e0!7i13312!8i6656
>>  
>> 
>>  
>>  It's particularly fun to be cycling along in your little cycle lane 
>>  while cars rush by on both sides of you at 80 km/h.
>>  
>>
>
> Also a good example of a situation why it makes sense to include bicycle 
> lanes in the lane tagging scheme.
>
> lanes=7
> cycleway=lane
> bicycle:lanes=designated|yes|designated|yes|yes|yes|yes
> motor_vehicle:lanes=no|yes|no|yes|yes|yes|yes
> turn:lanes=left|left|through|through|through|right|right
>
Note that bicycle only lanes are not included in lanes tag count (only full 
lanes are counted).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal Approved - boundary=aboriginal_lands

[Clifford Snow]

I notice most of the tribal land in Washington State has been mapped. There
are some smaller reservations that need to be mapped. Plus it look like
some boundaries need to be adjusted, especially for Yakima and Colville.
There is also a large section of disputed land we have included in Yakima
Nation. I suppose we should map that as disputed land. Anyone up for the
challenge?

Missing Boundaries
Chehalis Reservation
Squaxin Island Reservation
Skokomish Reservation
Nisqually Reservation
Shoalwater Bay Indian Reservation
Quileute Reservation
Makah Indian Reservation - southern section is missing.
Kalispel Reservation.

I'll create a background layer in Mapbox that people can use to add the
reservations and improve the existing boundaries. I'll try to get something
up in the next few days.

Clifford



Clifford

On Sun, Mar 17, 2019 at 1:33 PM Paul Johnson  wrote:

> I'm currently working on conflating the boundaries in Oklahoma right now,
> got most of the northeastern ones handled.
>
> On Sat, Mar 16, 2019 at 11:13 PM Alan McConchie 
> wrote:
>
>> After a few months of discussion and refinement in the default OSM style
>> sheet, and then a few more weeks of waiting for the styles to percolate to
>> the rendering servers, we can now see aboriginal areas showing up on the
>> map! Please take a moment to check the map in any parts of the world you're
>> familiar with, to see if the aboriginal_lands and protect_class=24 features
>> are showing up as we expect them to, or if there are any obvious ones
>> missing.
>>
>> Again, thanks to everyone who help get this tag discussed, approved, and
>> finally added to the map!
>>
>> Alan
>>
>> > On Dec 13, 2018, at 4:20 PM, Alan McConchie 
>> wrote:
>> >
>> > The voting period for boundary=aboriginal_lands has now closed, and
>> there were 45 votes in favor and 7 against, so the tag has now been
>> approved.
>> >
>> > I created the new wiki page for the tag here:
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands
>> >
>> > The map rendering still needs a bit of discussion about colors (to
>> avoid color conflict with the same brown used by zoos and theme parks) but
>> this is not the place for that conversation. The github issue remains open
>> for debate here:
>> https://github.com/gravitystorm/openstreetmap-carto/issues/3520
>> >
>> > So what's next? It now appears that "boundary=aboriginal_lands" is
>> synonymous with "boundary=protected_area" + "protect_class=24", and both
>> tagging styles have roughly similar usage in the database. I'm curious to
>> see over time whether mappers start to use "boundary=aboriginal_lands" more
>> frequently, or if people keep using both. Perhaps at some point in the
>> future we can have a discussion about whether to deprecate the
>> "boundary=protected_area" + "protect_class=24" approach, or if we should
>> just keep supporting both methods in simultaneously. But I'm not in a hurry
>> to start that discussion right now.
>> >
>> >
>> > Thanks to everyone who took part in this discussion and who voted on
>> the proposal!
>> >
>> > Alan
>> >
>> >
>> >> On Nov 24, 2018, at 4:38 PM, Alan McConchie 
>> wrote:
>> >>
>> >> The tag boundary=aboriginal_lands has been discussed on-and-off for a
>> long time in OSM. I'd like to raise the topic one last time and hopefully
>> come to some consensus about it.
>> >>
>> >> The tag proposal on the wiki dates from 2008, but the original
>> proposal was from the user Sam Vekemans (username acrosscanadatrails) who
>> is no longer participating in OpenStreetMap, as far as I can tell. He never
>> moved the proposal to a vote, so the page has remained in the proposal
>> state all this time.
>> >>
>> >> Here's the proposal:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands
>> >>
>> >> (I've tried to updated the wiki page somewhat, but leaving the
>> discussion intact)
>> >>
>> >> In the following years, some people have started using that proposed
>> tag, mostly in Canada and somewhat in the United States.
>> >>
>> >> Here's the overpass query for boundary=aboriginal_lands:
>> http://overpass-turbo.eu/s/DV4
>> >>
>> >> There has also been extensive discussion over the years on the
>> boundary=aboriginal_lands page, and it seems like the consensus is that the
>> tag is necessary and better than any alternatives. But it was never voted
>> on as a proposal.
>> >>
>> >> In the intervening years, tagging native reservations with
>> boundary=protected_area + protect_class=24 has also gained popularity. This
>> tag combination seems to be popular in South America, Australia, and also
>> in parts of the United States. I can't find any evidence for why people
>> chose this tag combination instead of boundary=aboriginal_lands. It appears
>> that the tags are pretty much interchangeable. Most of the features in
>> Brazil however are tagged incorrectly for the renderer, mixing
>> leisure=nature_reserve with protect_class=24, so that the areas show up on
>> the 

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

[marc marc]

Le 17.03.19 à 11:23, Jan S a écrit :
> it wasn't obvious which were police stations and which were other facilities. 
> In the end, I used Google maps... So there is practical relevance.

i'm in favor of police=* (execpt the double tag for the station)
but it's not a food relevance to promote a new schema because some objet 
are wrongly mapped.
so ifsomeone make a mistake with police=*, did we new a 3nd schema ?
or just fix the mistake in osm ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Graeme Fitzpatrick]

On Sun, 17 Mar 2019 at 21:44, Jan S  wrote:

>
> Okay, I think the police scheme is consolidating.
>

Yep, coming together nicely :-)


> I had included a new landuse=police tag, inspired in landuse=military. I'm
> not sure whether we really need that. I came to think that the police
> doesn't use land in the same way the military does for training grounds,
> huge shooting ranges, bomb dropping areas or even nuclear test sites. So as
> of now I tend to eliminate it from the proposal.
>

I don't know about that?

There are some extensive Police areas, rather than just buildings - as
mentioned, the Academy, driver training area, Mounted Police stable, which
would usually include paddocks & so on.

They would all be tagged as police=facilities, but how would they render,
as they wouldn't / shouldn't have the Police icon on them? I suppose you
could stretch things a bit to make them a University, racetrack &
farmland!, but not *really* appropriate!

They could all also be tagged as the landuse=government which was discussed
a few months ago (which I think is what Martin was suggesting?)

Thanks

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

Re: [Tagging] Feature Proposal Approved - boundary=aboriginal_lands

[Paul Johnson]

I'm currently working on conflating the boundaries in Oklahoma right now,
got most of the northeastern ones handled.

On Sat, Mar 16, 2019 at 11:13 PM Alan McConchie 
wrote:

> After a few months of discussion and refinement in the default OSM style
> sheet, and then a few more weeks of waiting for the styles to percolate to
> the rendering servers, we can now see aboriginal areas showing up on the
> map! Please take a moment to check the map in any parts of the world you're
> familiar with, to see if the aboriginal_lands and protect_class=24 features
> are showing up as we expect them to, or if there are any obvious ones
> missing.
>
> Again, thanks to everyone who help get this tag discussed, approved, and
> finally added to the map!
>
> Alan
>
> > On Dec 13, 2018, at 4:20 PM, Alan McConchie 
> wrote:
> >
> > The voting period for boundary=aboriginal_lands has now closed, and
> there were 45 votes in favor and 7 against, so the tag has now been
> approved.
> >
> > I created the new wiki page for the tag here:
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands
> >
> > The map rendering still needs a bit of discussion about colors (to avoid
> color conflict with the same brown used by zoos and theme parks) but this
> is not the place for that conversation. The github issue remains open for
> debate here:
> https://github.com/gravitystorm/openstreetmap-carto/issues/3520
> >
> > So what's next? It now appears that "boundary=aboriginal_lands" is
> synonymous with "boundary=protected_area" + "protect_class=24", and both
> tagging styles have roughly similar usage in the database. I'm curious to
> see over time whether mappers start to use "boundary=aboriginal_lands" more
> frequently, or if people keep using both. Perhaps at some point in the
> future we can have a discussion about whether to deprecate the
> "boundary=protected_area" + "protect_class=24" approach, or if we should
> just keep supporting both methods in simultaneously. But I'm not in a hurry
> to start that discussion right now.
> >
> >
> > Thanks to everyone who took part in this discussion and who voted on the
> proposal!
> >
> > Alan
> >
> >
> >> On Nov 24, 2018, at 4:38 PM, Alan McConchie 
> wrote:
> >>
> >> The tag boundary=aboriginal_lands has been discussed on-and-off for a
> long time in OSM. I'd like to raise the topic one last time and hopefully
> come to some consensus about it.
> >>
> >> The tag proposal on the wiki dates from 2008, but the original proposal
> was from the user Sam Vekemans (username acrosscanadatrails) who is no
> longer participating in OpenStreetMap, as far as I can tell. He never moved
> the proposal to a vote, so the page has remained in the proposal state all
> this time.
> >>
> >> Here's the proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands
> >>
> >> (I've tried to updated the wiki page somewhat, but leaving the
> discussion intact)
> >>
> >> In the following years, some people have started using that proposed
> tag, mostly in Canada and somewhat in the United States.
> >>
> >> Here's the overpass query for boundary=aboriginal_lands:
> http://overpass-turbo.eu/s/DV4
> >>
> >> There has also been extensive discussion over the years on the
> boundary=aboriginal_lands page, and it seems like the consensus is that the
> tag is necessary and better than any alternatives. But it was never voted
> on as a proposal.
> >>
> >> In the intervening years, tagging native reservations with
> boundary=protected_area + protect_class=24 has also gained popularity. This
> tag combination seems to be popular in South America, Australia, and also
> in parts of the United States. I can't find any evidence for why people
> chose this tag combination instead of boundary=aboriginal_lands. It appears
> that the tags are pretty much interchangeable. Most of the features in
> Brazil however are tagged incorrectly for the renderer, mixing
> leisure=nature_reserve with protect_class=24, so that the areas show up on
> the default renderer with the nature reserve green style.
> >>
> >> Here's the overpass query for protect_class=24:
> http://overpass-turbo.eu/s/DV5
> >>
> >> Wiki page for boundary=protected_area:
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
> >>
> >> In 2014, there were three messages on the tagging mailing list, from
> Paul Johnson and Clifford Snow.
> https://lists.openstreetmap.org/pipermail/tagging/2014-November/020160.html
> But at that time, we didn't come any answers.
> >>
> >> There seems to be no argument about whether or not aboriginal areas are
> important features that should be mapped. The only question is how to tag
> them.
> >>
> >> So the question is:
> >>
> >> Should we use the single tag boundary=aboriginal_lands for these areas?
> Or should we deprecate that tag (in other words, reject the proposal) and
> instead use boundary=protected_area + protect_class=24?
> >>
> >>
> >> I'd like to officially open the voting per

Re: [Tagging] Green lanes (OT)

[Paul Johnson]

On Sun, Mar 17, 2019 at 2:43 AM Andrew Davidson  wrote:

> On 17/3/19 4:30 pm, Graeme Fitzpatrick wrote:
> > Or even
> >
> https://www.google.com/maps/@-28.0766007,153.4447888,3a,20.7y,49.91h,89.96t/data=!3m6!1e1!3m4!1s3dPlQ9YxNBm-7lRm4GOUPg!2e0!7i13312!8i6656
> >
> > & back another 30 m's or so
> >
> >
> https://www.google.com/maps/@-28.0767024,153.296,3a,27.3y,57.48h,86.03t/data=!3m6!1e1!3m4!1sj4MRicAAxp4hNWeZbBs-zg!2e0!7i13312!8i6656
> > Did somebody say something about marking lanes by the way!
>
> Don't worry...the green paint has magical protective properties.
>
> We have some beauties in Canberra:
>
>
> https://www.google.com/maps/@-35.3034635,149.1818641,3a,60y,295.56h,87.06t/data=!3m6!1e1!3m4!1sERm_fITufjNl0fb1g58vjw!2e0!7i13312!8i6656
>
> It's particularly fun to be cycling along in your little cycle lane
> while cars rush by on both sides of you at 80 km/h.
>
>
Also a good example of a situation why it makes sense to include bicycle
lanes in the lane tagging scheme.

lanes=7
cycleway=lane
bicycle:lanes=designated|yes|designated|yes|yes|yes|yes
motor_vehicle:lanes=no|yes|no|yes|yes|yes|yes
turn:lanes=left|left|through|through|through|right|right
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we still need cycleway=opposite?

[Christian Müller]

Yes, all of them, rationale:

For cycleway=opposite_track or cycleway=opposite_lane
you won't know which track or lane it refers to (or if
it refers to both), if two lanes or tracks accompany
the road.

cycleway=opposite (in the sense that no lane is marked
and no track exists, but cycling a oneway in opposite
direction allowed) is effectively the same as using
oneway:bicycle=no

Your concern about using one tag less:  I only agree
half the way that this is true, because

a) opposite_lane is not _a_ value, but rather a value
combination, it expresses (like the semicola based
approach) two different things in one value

b) If you strictly tag tracks explicitly, you can imply
that cycleway:left:oneway=-1  also means
cycleway:left=lane.

c) cycleway:left_lane:oneway=-1 or cycleway:left:lane:oneway=-1
also has all the information in one tag, but I personally do
not think that this should be a design goal.

Legal direction and cycleway type are conceptually to separate
things, why should they not be expressed using two tags?


Greetings

> On 03/17/19, 13:03, Markus wrote:
> >
> > I support discouraging both opposite* values.
> 
> I suppose you mean all three?
> 
> [..]
> 
> I personally find cycleway:left=opposite_lane much more comprehensible
> than cycleway:left=lane + cycleway:left:oneway=-1. In addition, you
> need one tag less.

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

Re: [Tagging] "satellit"

[bkil]

I agree that we should focus our mapping efforts primarily on landmark antennae.

Although, there could exist other reasons to map one. For example, I
map broadcast FM radio or TV masts even if they are only a few meters
high, as that helps listeners point their (directional) receiving
antennae. Mapping of WISP sector heads may help determine whether a
given provider will be available in a given flat. HAMs may also prefer
to share their location and channels used this way as a common good
for emergencies. Air traffic control frequencies and location may also
come in handy for hobby fliers.

Technically, there exist various differences between an antenna used
for transmission and one only used for reception. The main issue boils
down to power handling - the SWR of the whole line must be optimized
(tuners are also commonly used), all section must handle both the
amperage and the voltage without overheating or sparking, extra
caution must be exercised against corrosion, safety measures must be
in place for humans and other creatures, special permits must be
acquired, etc.

You can easily verify whether an antenna transmits and on what
frequency by using a drone with an SDR, triangulation from a distance,
or sometimes simply using a heat camera. Although the power supplies
and lines themselves can also be tell-tale, and you may be able to
read or identify certain model numbers from a distance with the right
binoculars.

Do you think that we should map antennae participating in open
community networks? I've seen people map wireless private cellular
backbone, and the latter feels much less serving public interest
compared to the former.

By the way, this looks like a hot topic:

mast / tower / communication_tower (again):
https://lists.openstreetmap.org/pipermail/tagging/2018-October/039556.html

Radio telescopes:
https://lists.openstreetmap.org/pipermail/tagging/2018-October/040198.html

antenna type:
https://lists.openstreetmap.org/pipermail/tagging/2018-November/041044.html

antenna use key to replace some of the antenna type:
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041207.html

On Thu, Mar 7, 2019 at 11:07 PM Warin <61sundow...@gmail.com> wrote:
>
> On 07/03/19 20:50, Martin Koppenhoefer wrote:
>
> Am Do., 7. März 2019 um 09:57 Uhr schrieb Joseph Eisenberg 
> :
>>
>> It's good that radio telescopes have been mentioned. While considering
>> this issue, you should also take a look at towers with
>> tower:type=communication and tower:construction=dish
>>
>> I'm not sure if it is sensible to tag a large satellite dish as a
>> "tower" but that is currently an option that has been used
>> occasionally.
>
>
>
> I'm also aware that a common recommendation is to tag them as towers, but I 
> would not see this as a good option, for "big/high structures" we could have 
> a basic distinction already in the main tag (and these tags are also already 
> used), e.g. cooling_tower, chimney, dish, lighthouse, bell_tower, 
> water_tower, flagpole etc. rather than cramming everything into a big 
> "pre-category", which isn't useful on its own anymore because of the very 
> broad scope.
> If a tower is a structure that is higher than wide, some dishes could fall 
> out. If you require a tower is a structure where people can go into or atop, 
> a requirement that isn't currently set but isn't completely unreasonable 
> either, dishes would also be excluded.
>
>
> A tower of a mast could be used for lighting, or an antenna. Or flags, or a 
> signal lamp ... https://en.wikipedia.org/wiki/International_Code_of_Signals
>
> The tag mast or tower should not be assumed to indicate the presence of 
> another feature.
> OSM guide - one feature = one OSM entry.
> So tag the mast/tower.. then add another entry for the antenna (or other 
> feature).
>
>
>
> ___
> 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=*

[Martin Koppenhoefer]

sent from a phone

> On 17. Mar 2019, at 12:42, Jan S  wrote:
> 
> I had included a new landuse=police tag, inspired in landuse=military. I'm 
> not sure whether we really need that. I came to think that the police doesn't 
> use land in the same way the military does for training grounds, huge 
> shooting ranges, bomb dropping areas or even nuclear test sites. So as of now 
> I tend to eliminate it from the proposal.


+1, IMHO we don’t need it, we tag the police grounds with the facility tags and 
the landuse is implicit (or implicitly shared with other stuff like government 
administration, airports or whatever)

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

Re: [Tagging] Do we still need cycleway=opposite?

[Mateusz Konieczny]

Mar 17, 2019, 10:50 AM by selfishseaho...@gmail.com:

> On Sun, 17 Mar 2019 at 09:09, Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>>
>> I like to use it to mark that given oneway:bicycle=no has no designated 
>> contraflow lane.
>>
>
> cycleway=no + oneway:bicycle=no is much clearer in my opinion.
>
> I support discouraging cycleway=opposite. This tag gets too often
> confused with cycleway=opposite_lane.
>
Using cycleway=no for this purpose is OK for me.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we still need cycleway=opposite?

[Markus]

On Sun, 17 Mar 2019 at 13:38, "Christian Müller"  wrote:
>
> I support discouraging both opposite* values.

I suppose you mean all three?

> Re-using oneway semantics is easy.  oneway is an established
> tag with established interpretation - if its meaning is not
> reshaped in an obscure way it is reusable in all its namespace
> variants with confidence and no frills.

I personally find cycleway:left=opposite_lane much more comprehensible
than cycleway:left=lane + cycleway:left:oneway=-1. In addition, you
need one tag less.

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

Re: [Tagging] Do we still need cycleway=opposite?

[Markus]

On Sun, 17 Mar 2019 at 12:22, Martin Koppenhoefer
 wrote:
>
> cycleway=opposite specifies a track (=distinct bicycle carriageway) whose 
> position and direction are opposite to the direction you would expect (e.g. 
> it is left for right traffic jurisdictions), right?

No, that's cycleway=opposite_track. cycleway=opposite is for
"situations where there is no dedicated contra-flow lane marked for
cyclists". [1]

> Would you add it in case the track is explicitly mapped? In other words, is 
> it a property of the road and independent from an explicitly mapped cycleway, 
> or is it either or?

If there's a separate carriageway for bicycles ("cycle track"), i tag
the road cycleway=separate. This is also what the wiki recommends. [1]

[1]: https://wiki.openstreetmap.org/wiki/Key:cycleway

___
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]

sorry, that mail 5min ago, was send by accident.

Am 17.03.2019 um 04:19 schrieb Andrew Davidson:

On 17/3/19 10:18 am, Hubert87 wrote:


No, not exactly the same: cycleway:[left|right|both|none]:oneway=no 
implies oneway:bicycle=no, but no vice versa.
cycleway:[left|right|both|none]:oneway=[-1] does not imply 

> oneway:bicycle=no (maybe oneway:bicycle=no -1)

Nice straw man you've made there. 


I resent that statement.

I didn't say that either of those forms of tagging imply the other. 


No, I did!

What I said was that both forms indicate that cyclists can ride in 
both directions and asked why should mappers be advised to use the 
more rare, less likely to be consumed, version when they both mean the 
same thing?


since there could be edge cases, where a cyclist could use the 
cycleway to get for B to A, but has no option to go from A to B.


Here is a crazy idea: how about oneway:bicycle=-1? 

I already hinted at that.
Nice and simple, saves you from having to add tags that indicate 
bicycles can't travel in the forward direction, and may actually be 
noticed by data consumers who are likely to be also be looking for 
oneway:bicycle=no.


True, but that argument of simplification can be made for a lot of tags, 
for example cycleway=track/lane => cycleway=yes.

You are losing Information.
And amusing you did mean shared_lane, it is kind of the default, and 
usually requires some kind marking to make able to map it.




Nope. I mean cycleway=shared as defined on the wiki page (from late 
2011 onward, so I didn't think it was such a new and radical idea). 
Could you provide a link? All I could find was 
https://wiki.openstreetmap.org/wiki/Key:cycleway
In Australia the only difference between cycleway=shared and 
cycleway=shared_lane can be one of these signs:
Road markings look the same to me, should be tagged the same in osm. 
Should be a subform of cycleway=shared_lane on first thoughts.


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

Re: [Tagging] Do we still need cycleway=opposite?

[Christian Müller]

I support discouraging both opposite* values.

Re-using oneway semantics is easy.  oneway is an established
tag with established interpretation - if its meaning is not
reshaped in an obscure way it is reusable in all its namespace
variants with confidence and no frills.

I'm also in favour of a better separation in the documentation
to cycleway related tags.  The doc should make it clear how
and why the concepts differ.  Judging from the mailing list
discussions most people do not seem to get the intention of
the different tagging schemes available, or more loosely even
tend to claim that there is no difference involved at all.

Another lesson learnt, is that a documented list of values
absolutely should be accompanied by a claim of whether that
list is open to additions or not.  For example, some tagging
schemes loose their descriptive power if the set of values
is overloaded with this and that and then whatnot.


Greetings


> On 03/17/19, 09:50, Markus wrote:
> 
> I support discouraging cycleway=opposite. This tag gets too often
> confused with cycleway=opposite_lane.

___
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]

Am 17.03.2019 um 04:19 schrieb Andrew Davidson:


Nice straw man you've made there. I didn't say that either of those 
forms of tagging imply the other.


___
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 or at best conditionally true.

oneway:bicycle=no tells you /nothing more/ than that bicycles
can pass in both directions of a oneway, but it does not tell
you /where/ in the street or /how/, nor about the degree of
safety doing so, i.e. if a lane is marked.

cycleway:[left|right|both|none]:oneway=[-1|no] is specific
about a marked lane or track, which means that the information
is less imprecise and that you can do a lot more with it when
using that data to render maps.


For the general aspect you've selected to talk about your
findings are true, but this is one among many uses of the
data, read: a selective interpretation of data.


Greetings


> On 03/16/19, 22:43, Andrew Davidson wrote:
> An: "Tag discussion, strategy and related tools" , 
> "Martin Koppenhoefer" 
> Betreff: Re: [Tagging] Wild changes to wiki pages changing the cycleway 
> tagging scheme
>
> How are they different? If I have a oneway=yes way:
> 
> A--->B
> 
> oneway:bicycle=no tells me that bicycles can pass along this way A->B 
> and B->A
> 
> exactly the same case if there is any of the tags:
> cycleway:[left|right|both|none]:oneway=[-1|no]
> 
> 
> They tell me the same thing. The point of this discussion is what the 
> *preferred* method should be not how many different ways there are to 
> tag the same piece of information.

___
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]

What are you gonna do with the *=track cases then?
Imho your approach would mean to generally discourage
cycleway*=* and generally represent cycleway tracks
using a separate geometry.

In the case where cycleway tracks are separated merely
by a curb, this may be unsatisfactory as well.  If the
geometric objects run very close in parallel, people
will argue in reverse, that there is no need for the
separate geometry and reclaim the tagging variant in
use now.


Greetings
 

> On 03/16/19, 19:20, Paul Johnson wrote:
> 
> I'd honestly rather see bicycle tagging as part of the general lane tagging
> scheme more widely adopted, since there may be more than one bicycle lane
> each direction, and it's placement within the roadway may not necessarily
> be the edge of the road.

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

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

[Jan S]

Okay, I think the police scheme is consolidating.

I had included a new landuse=police tag, inspired in landuse=military. I'm not 
sure whether we really need that. I came to think that the police doesn't use 
land in the same way the military does for training grounds, huge shooting 
ranges, bomb dropping areas or even nuclear test sites. So as of now I tend to 
eliminate it from the proposal.

This would likely be the last question I'd raise. We could then soon go to a 
vote :)

Best, Jan

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

Re: [Tagging] Do we still need cycleway=opposite?

[Martin Koppenhoefer]

sent from a phone

> On 17. Mar 2019, at 10:50, Markus  wrote:
> 
> I support discouraging cycleway=opposite. This tag gets too often
> confused with cycleway=opposite_lane.


cycleway=opposite specifies a track (=distinct bicycle carriageway) whose 
position and direction are opposite to the direction you would expect (e.g. it 
is left for right traffic jurisdictions), right? Shouldn’t this be either 
cycleway:left, :right or :both? The meaning depends on the road being oneway or 
not?
Would you add it in case the track is explicitly mapped? In other words, is it 
a property of the road and independent from an explicitly mapped cycleway, or 
is it either or?

Or does it include both, tracks and lanes? There is also some usage of 
opposite_track.

IMHO the default should be cycleway=no 

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

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

[Jan S]

Am 16. März 2019 20:09:05 MEZ schrieb Mateusz Konieczny 
:
>Some police facilities will remain mistagged, no matter tagging scheme.
>
>Have you already fixed such objects or opened OSM notes mentioning
>mistaggings?

No. I wouldn't have known which other tags could've been applied. That's why I 
decided to make the proposal and define tags first.

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

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

[Jan S]

Am 16. März 2019 23:18:38 MEZ schrieb Joseph Eisenberg 
:
>The key “police” is not currently on the list of features that import
>as a
>polygon in osm2pgsql, when mapped as a closed way.
>
>So renderers and other database users that rely on osm2pgsql will need
>to
>add the “police” key to the lua transformations list and reimport the
>database.
>
>This is easy for cartographers that make insividual maps, but it’s a
>major
>undertaking for the main OSM servers, which is only done every couple
>of
>years. So it will take some time before any objects tagged
>“police=station”
>without an “amenity” tag could be rendered on the Standard map layer on
>OSM.
>
>This shouldn’t be a problem for things like warehouses, non-public
>offices,
>vehicle impound facilities etc. But it requires patience for police
>stations.

Good point. I hope this transition period can be provided by double tagging 
police stations for a while at least.

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

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

[Jan S]

Am 17. März 2019 00:56:42 MEZ schrieb Warin <61sundow...@gmail.com>:
>On 17/03/19 03:15, Martin Koppenhoefer wrote:
>>
>>
>>
>>
>> sent from a phone
>> On 16. Mar 2019, at 15:53, Jan S > > wrote:
>>
>>> So you basically can't rely on OSM to find a police station in case 
>>> of an emergency.
>>
>>
>> let us not overemphasize the emergency in this context. In an urgent 
>> emergency you would expect the police to come to you rather than the 
>> opposite.
>
>If you are being assaulted, it is better to run towards the police 
>rather than away.

The other day I was abroad and a window of my car was broken and a bag stolen. 
I needed to go to a police station and ran into the issue that there were 
several amenity=police facilities around and it wasn't obvious which were 
police stations and which were other facilities. In the end, I used Google 
maps... So there is practical relevance.

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

Re: [Tagging] Do we still need cycleway=opposite?

[Markus]

On Sun, 17 Mar 2019 at 09:09, Mateusz Konieczny  wrote:
>
> I like to use it to mark that given oneway:bicycle=no has no designated 
> contraflow lane.

cycleway=no + oneway:bicycle=no is much clearer in my opinion.

I support discouraging cycleway=opposite. This tag gets too often
confused with cycleway=opposite_lane.

Regards

Markus

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

Re: [Tagging] Do we still need cycleway=opposite?

[Mateusz Konieczny]

I like to use it to mark that given oneway:bicycle=no has no designated 
contraflow lane.

This way all oneway:bicycle=no have either cycleway=opposite or 
cycleway=opposite_lane
or are waiting for survey.


Mar 17, 2019, 8:37 AM by thesw...@gmail.com:

> On 17/3/19 10:42 am, Martin Koppenhoefer wrote:
>
>> I didn’t know this tag, historically the cycleway tags were used for bicycle 
>> infrastructure, seems people are working to change this.
>>
>
> I didn't say I liked the cycleway=shared tag. There are a lot of highways in 
> Australia tagged with this and I wouldn't ride on any of them. I'm assuming 
> that routers should treat them the same as cycleway=no.
>
> This does raise the question: do we still need the cycleway=opposite tag? Is 
> there some characteristic of the street that is not captured by just the 
> bicycle:oneway=no tag?
>
> A question for the Euromappers I think (haven't seen a "cycle plug" in 
> Australia).
>
> ___
> 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] Status of oneway=cw oneway=ccw

[s8evq]

Thanks everybody for the input. I try to summarize the discussion so far as 
following. Please reply if I misunderstood some arguments.

- Not many are in favor of oneway=cw / oneway=ccw to indicate the actual 
direction. This is currently in the wiki but is hardly in use (about 5 times in 
total). I will go forward and remove this from the wiki. OK?

-  Once established is that a route should only be done in one direction with 
an appropriate tag, it's up to the data consumer to guess what direction 
(counterclockwise or clockwise) that actually is. This can be done based on the 
order of the members in the relations.

- The above can contain ambiguity when a relation contains less then three 
members. Possible solution is to split ways to avoid ambiguity, forbid one-way 
routes of fewer than three members, or disambiguate with 'forward' or 
'backward' roles on the ways.

- One question that remains open is how to tag. On the one hand oneway=yes is 
currently in use with 1.2K relations. On the other had, the argument can be 
made that oneway=yes should be reserved to legal prescriptions and not just 
recommendations. Alternatives that came forward are: bidirectional=no, 
signed_oneway=yes, oneway=signposted, oneway=recommended, oneway=signed


And one more thing I noticed: oneway=yes is currently used for route=hiking and 
route=walking. What about route=bicycle. The same problem exists there for a 
lot of the network=lcn routes. But the wiki doesn't mention anything. I think 
the same logic applies there, or not?

On Fri, 15 Mar 2019 00:09:22 +0100, Hufkratzer  wrote:

>It is indeed interesting to store that the signs work only for one 
> direction,
> therefore oneway=yes/no is documented for hiking routes
> - in https://wiki.openstreetmap.org/wiki/Hiking#Tags_of_the_relation 
> since Jan. 2013
> - in 
> https://wiki.openstreetmap.org/wiki/Tag:route=hiking#Tags_of_the_relation 
> since 
> Mar. 2016
> and we already have 1.2k relations with oneway=yes
> and zero with oneway=signed, bidirectional=no or signed_oneway=yes.
> 
> On 14.03.2019 21:31, Volker Schmidt wrote:
>  > I second Martin. No "oneway" key in this case.
>  > On Thu, 14 Mar 2019 at 21:18, Martin Koppenhoefer 
>  wrote:
>  >
>  >
>  >
>  > sent from a phone
>  >
>  > > On 14. Mar 2019, at 11:43, Sarah Hoffmann  wrote:
>  > >
>  > > or oneway=signed if you think it clashes with the legal
>  > > restriction tags).
>  >
>  >
>  > or bidirectional=no
>  > or signed_oneway=yes
>  >
>  > it shouldn’t be a value of the “oneway” key, there’s nothing 
> preventing you from doing the route in the counterdirection, especially 
> if you are with a map from OpenStreetMap ;-)
>  >
>  > Yes, it could be interesting to store that the signs work only 
> for one direction, but this is very different from a oneway.
>  >
>  >
>  > 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

[Tagging] Green lanes (OT)

[Andrew Davidson]

On 17/3/19 4:30 pm, Graeme Fitzpatrick wrote:

Or even
https://www.google.com/maps/@-28.0766007,153.4447888,3a,20.7y,49.91h,89.96t/data=!3m6!1e1!3m4!1s3dPlQ9YxNBm-7lRm4GOUPg!2e0!7i13312!8i6656

& back another 30 m's or so

https://www.google.com/maps/@-28.0767024,153.296,3a,27.3y,57.48h,86.03t/data=!3m6!1e1!3m4!1sj4MRicAAxp4hNWeZbBs-zg!2e0!7i13312!8i6656
Did somebody say something about marking lanes by the way!


Don't worry...the green paint has magical protective properties.

We have some beauties in Canberra:

https://www.google.com/maps/@-35.3034635,149.1818641,3a,60y,295.56h,87.06t/data=!3m6!1e1!3m4!1sERm_fITufjNl0fb1g58vjw!2e0!7i13312!8i6656

It's particularly fun to be cycling along in your little cycle lane 
while cars rush by on both sides of you at 80 km/h.


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

[Tagging] Do we still need cycleway=opposite?

[Andrew Davidson]

On 17/3/19 10:42 am, Martin Koppenhoefer wrote:


I didn’t know this tag, historically the cycleway tags were used for bicycle 
infrastructure, seems people are working to change this.



I didn't say I liked the cycleway=shared tag. There are a lot of 
highways in Australia tagged with this and I wouldn't ride on any of 
them. I'm assuming that routers should treat them the same as cycleway=no.


This does raise the question: do we still need the cycleway=opposite 
tag? Is there some characteristic of the street that is not captured by 
just the bicycle:oneway=no tag?


A question for the Euromappers I think (haven't seen a "cycle plug" in 
Australia).


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