Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Eugene Alvin Villar]

Thanks, Brian, for taking the lead on this. I generally agree with the
overall direction of the proposal. There's a lot of details on the proposal
page but I guess we can discuss them on the wiki talk page.

On Sun, Dec 20, 2020 at 10:58 PM Brian M. Sperlongano 
wrote:

> A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is
> now open for comments.
>
> This proposal:
>
>   1. Deprecates landuse=reservoir
>   2. Provides definitions for:
>  a. water=reservoir
>  b. water=lake
>  c. water=pond
>
> It is clear from various multiple discussions on this topic that there are
> still open questions from the original 2011 water=* proposal, as well as
> the exact definition of a reservoir, and how they differ from lakes and
> ponds.  Previous discussions indicated that there is community support for
> maintaining a distinction between lake and pond, rather than eliminating or
> merging these concepts.
>
> The definitions posed in this proposal were developed with the help of
> considerable community input over the last week, and I want to thank the
> numerous folks that collaborated on this.  The real world presents many
> edge cases that make it challenging to come up with clear definitions, but
> that should not prevent us from trying.
>
> The goal in these definitions is to *describe* rather than *prescribe* how
> reservoir, lake, and pond are actually tagged.  This necessarily involves
> some degree of subjectivity between the categories, and the proposed
> definitions leave it to mappers to make these subjective decisions when a
> body of water exhibits some characteristics of more than one of these terms.
>
> As this topic has been discussed ad nauseam for nearly a decade, I hope
> that this proposal, discussion, and subsequent vote will allow us to put
> this issue to rest, and/or document the level of community support that
> exists for different tagging schemes.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> ___
> 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] natural=fell not rendered, alternatives?

[Anders Torger]

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more specific 
landcover tags to be used. I don't think that (somewhat randomly) 
requiring detailed landcover is a good design choice. I think it would 
be better to have a defined hierarchy from more generic to more specific 
tags so the map can evolve. Taking the leap to high detail mapping 
directly makes covering the map very slow and sometimes inaccurate. Fell 
in particular is in parts so heavily speckled with slightly different 
covers it's hard to even see on the satellite photo what it is. You can 
have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an 
area. So I guess I make that heath then as it's dominant? That would 
however be more misleading than actually setting a more generic tag like 
natural=fell. Forcing detailed mapping where this is very difficult to 
do is not a good idea.


When we get to even higher altitude the growth disappear and we have 
just bare rock and scree so it becomes easier. It can at times be quite 
hard to differ between bare rock or scree though (the resolution of the 
satellite photos in the mountains is often not that great).


We already have more-generic-to-more-specific landcovers in other areas, 
you can provide wood without specifying tree type for example, or 
wetland without specifying type of wetland. (Parenthesis: going from 
more generic to more specific by adding additional specifying tags is an 
elegant design, I think it's a bit unfortunate that that design is mixed 
with a flat tag structure as well, but that's the way it is...).


It seems like a very odd design choice to require more detailed mapping 
in alpine areas where this is rather difficult. If we look into how 
official maps do it in Sweden and Norway they don't have specific 
landcovers above the tree line, they have just "fell", and in addition 
significant wetlands, plus waters and streams of course.


Fell indicates where we have bare mountain (above treeline), which is 
the key information outdoor goers need, plus waters and significant 
wetlands. Anyone that has been to these mountains know that once above 
the tree line the land cover is quite predictable, it's decided by 
altitude and steepness. At the fell altitude contour lines is key 
information, not if it's a patch of heath or bare rock, which rather 
just makes a map harder to read without providing valuable information.


So far I have tagged these areas with natural=fell. I'm thinking about 
adding bare_rock at high altitude (and scree only when clear and 
significant), but in the medium altitude where there is growth more 
detailed mapping becomes very difficult. Heath would be the most natural 
generic tag for that area, but then we loose the distinction that it's 
above the tree line, as there already is some heath areas below the tree 
line. Maybe adding an extra tag like "alpine=yes"? I suppose it won't 
render differently from normal heath on any renderer though so we still 
lose the rather significant tree line information in actual maps.


Suggestions are welcome.

/Anders

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Mateusz Konieczny via Tagging]

Dec 21, 2020, 08:18 by graemefi...@gmail.com:

>
> Thanks
>
> Graeme
>
>
> On Mon, 21 Dec 2020 at 16:44, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>> OSMF board is not spending hours on monitoring wiki pages.
>>
>> I am spending hours on monitoring wiki pages and noticed it only recently,
>> and only in a new proposal.
>>
>> Anyone may edit Wiki and many things are present there because noone
>> noticed what is written somewhere.
>>
>>> Somebody obviously considers that they should be noted there?
>>>
>> I am not against noting legal restrictions in some countries that may be 
>> dangerous for some mappers. But I am against implying that it is 
>> against OSM rules to map in China or map military bases in Russia/Israel/etc
>> or that it is unwanted.
>>
>
> The suggestion was made to me privately that this matter be raised via the 
> Legals list to get an official opinion or ruling, & if it is agreed that it 
> is a requirement, hopefully also an agreed wording for a "warning".
>
> I agree that that is probably the best option, but also consider that it 
> could be left until after the proposal is accepted or not, &, once again, it 
> would be done as part of a clean-up of the military pages.
>

At least I will vote against proposal that includes
"As always, if it is illegal in your country to map military establishments, 
please do not do so!".

I will certainly not demand breaking such law, or expect people to risk it. 
Especially
as such law is often present in countries where going against government is
especially risky.

But implying that it is also against OSM rules is not acceptable to me.

Mapping military bases in Israel, Russia, mapping anything in China/North Korea
etc should be welcomed in OSM if someone is doing this and wants that.

Though making people aware about risks is a  good idea.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Tomas Straupis]

2020-12-21, pr, 01:10 Clifford Snow rašė:
> Please refrain from calling out others as outlined in the Etiquette 
> Guidelines [1]

  Can you be more specific?

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

Thanks

Graeme


On Mon, 21 Dec 2020 at 16:44, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> OSMF board is not spending hours on monitoring wiki pages.
>
> I am spending hours on monitoring wiki pages and noticed it only recently,
> and only in a new proposal.
>
> Anyone may edit Wiki and many things are present there because noone
> noticed what is written somewhere.
>
> Somebody obviously considers that they should be noted there?
>
> I am not against noting legal restrictions in some countries that may be
> dangerous for some mappers. But I am against implying that it is
> against OSM rules to map in China or map military bases in
> Russia/Israel/etc
> or that it is unwanted.
>

The suggestion was made to me privately that this matter be raised via the
Legals list to get an official opinion or ruling, & if it is agreed that it
is a requirement, hopefully also an agreed wording for a "warning".

I agree that that is probably the best option, but also consider that it
could be left until after the proposal is accepted or not, &, once again,
it would be done as part of a clean-up of the military pages.

Thanks

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Mateusz Konieczny via Tagging]

Dec 21, 2020, 01:43 by graemefi...@gmail.com:

>
>
>
>
> On Mon, 21 Dec 2020 at 10:37, Martin Koppenhoefer <> dieterdre...@gmail.com> 
> > wrote:
>
>>
>> imagine you were mapping something, and it is legal in the place where you 
>> are, but illegal in Britain, so you can not do it. Or you are seeing things 
>> in country A and when you’re in country B you add them to OpenStreetMap 
>> (from memory), which is legal in country B but not in country A. You might 
>> be able to do it and still be arrested when going back to country A.
>>  
>>  People also said in the past we should adhere to European law because 
>> otherwise our dataset can not be used in the EU (e.g. with respect to 
>> copyright and fair use). I am not sure if after the Brexit this will still 
>> be the OpenStreetMap-Foundation policy, or whether they focus completely on 
>> British law, but I am sure that Chinese law has not been deemed relevant by 
>> past and present osmf boards.
>>
>
> I agree it's incredibly confusing, & a legal minefield (as well as 
> potentially a real one!), but if it's an issue, why haven't the "Warnings" 
> been deleted from the various military pages prior to this?
>
OSMF board is not spending hours on monitoring wiki pages.

I am spending hours on monitoring wiki pages and noticed it only recently,
and only in a new proposal.

Anyone may edit Wiki and many things are present there because noone
noticed what is written somewhere.

> Somebody obviously considers that they should be noted there?
>
I am not against noting legal restrictions in some countries that may be 
dangerous for some mappers. But I am against implying that it is 
against OSM rules to map in China or map military bases in Russia/Israel/etc
or that it is unwanted.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

On Mon, 21 Dec 2020 at 10:37, Martin Koppenhoefer 
wrote:

>
> imagine you were mapping something, and it is legal in the place where you
> are, but illegal in Britain, so you can not do it. Or you are seeing things
> in country A and when you’re in country B you add them to OpenStreetMap
> (from memory), which is legal in country B but not in country A. You might
> be able to do it and still be arrested when going back to country A.
>
> People also said in the past we should adhere to European law because
> otherwise our dataset can not be used in the EU (e.g. with respect to
> copyright and fair use). I am not sure if after the Brexit this will still
> be the OpenStreetMap-Foundation policy, or whether they focus completely on
> British law, but I am sure that Chinese law has not been deemed relevant by
> past and present osmf boards.
>

I agree it's incredibly confusing, & a legal minefield (as well as
potentially a real one!), but if it's an issue, why haven't the "Warnings"
been deleted from the various military pages prior to this?

Somebody obviously considers that they should be noted there?

Thanks

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

[Tagging] Feature Proposal - Voting - Rescue Stations

[Graeme Fitzpatrick]

Just to make sure everybody is aware, voting is now open on the
https://wiki.openstreetmap.org/wiki/Proposed_features/Rescue_Stations
proposal.

Any questions or comments are still welcome, either here, the original
Proposal thread (
https://lists.openstreetmap.org/pipermail/tagging/2020-December/056605.html)
or on the Talk page.

Thanks

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

[Tagging] Feature proposal - Voting - Pumping

[François Lacombe]

Dear all,

Following an appropriate refactoring of proposed pumping tagging done by
IanVG and I, this proposal is now open for voting until January 4.
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

Despite a complex classification, keep in mind that most of proposed tags
are optional and mappers will still be able to give simple information
about pumping means if they want to.

You may not be able to describe some pumps hidden in restricted areas.
Question asked during this vote is about tagging suitability to describe
pumps with public ground knowledge.

Thank you to ZeLonewolf, Mateusz, Volker, Joseph and Martin for their
involvement during second RFC phase.

All the best

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

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Graeme Fitzpatrick]

Thanks Andrew!

Done!

Graeme


On Mon, 21 Dec 2020 at 10:21, Andrew Harvey 
wrote:

> Per the Proposal Process at
> https://wiki.openstreetmap.org/wiki/Proposal_process#Voting it's normal
> to send a new email with the subject like "Feature Proposal - Voting -
> (Feature Name)" to the list.
>
> Many people might not be reading every email in the RFC thread, but do
> want to know when voting is open, so a new thread makes it more visible.
>
> On Sun, 20 Dec 2020 at 14:33, Graeme Fitzpatrick 
> wrote:
>
>>
>>
>>
>> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
>> wrote:
>>
>>> https://wiki.openstreetmap.org/wiki/Rescue_Stations
>>>
>>
>> Moved to voting.
>>
>> If you still have any comments or concerns, please raise them for
>> discussion, rather than just voting "No, because ..."!
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed feature - RFC - Military Bases

[Martin Koppenhoefer]

sent from a phone

> On 21. Dec 2020, at 00:49, Graeme Fitzpatrick  wrote:
> 
> I would hate for somebody to be potentially arrested on spying / espionage 
> charges for doing what we suggested :-(


imagine you were mapping something, and it is legal in the place where you are, 
but illegal in Britain, so you can not do it. Or you are seeing things in 
country A and when you’re in country B you add them to OpenStreetMap (from 
memory), which is legal in country B but not in country A. You might be able to 
do it and still be arrested when going back to country A.

People also said in the past we should adhere to European law because otherwise 
our dataset can not be used in the EU (e.g. with respect to copyright and fair 
use). I am not sure if after the Brexit this will still be the 
OpenStreetMap-Foundation policy, or whether they focus completely on British 
law, but I am sure that Chinese law has not been deemed relevant by past and 
present osmf boards.

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

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Andrew Harvey]

Per the Proposal Process at
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting it's normal to
send a new email with the subject like "Feature Proposal - Voting -
(Feature Name)" to the list.

Many people might not be reading every email in the RFC thread, but do want
to know when voting is open, so a new thread makes it more visible.

On Sun, 20 Dec 2020 at 14:33, Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
> wrote:
>
>> https://wiki.openstreetmap.org/wiki/Rescue_Stations
>>
>
> Moved to voting.
>
> If you still have any comments or concerns, please raise them for
> discussion, rather than just voting "No, because ..."!
>
> 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] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

On Mon, 21 Dec 2020 at 09:35, Martin Koppenhoefer 
wrote:

>
> is this referring to British law?
>

Not that I'm aware of (or Australian for that matter!), but I have seen
comments on various pages that it is illegal for people in both Israel &
Russia to map the location of military bases, &, of course, it's apparently
illegal to map anything in China.

I would hate for somebody to be potentially arrested on spying / espionage
charges for doing what we suggested :-(

Thanks

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Brian M. Sperlongano]

I agree with this interpretation.  sport=* should always be secondary to
some physical feature that is a location in some way related to the sport
(where it is played, where you can get lessons, a shop, etc).

On Sun, Dec 20, 2020 at 6:32 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. Dec 2020, at 22:45, Warin <61sundow...@gmail.com> wrote:
>
> Some examples;
>
> sportbowlsA place where you can play lawn bowls/lawn bowling.
>
> sportkitesurfingTo mark a spot for kitesurfing
>
> sportmultiA sports facility that is suitable for more than one
> sport
>
> sportracquetRacquetball facilities, such as racquetball courts
>
> sportscuba_divingTo mark a spot for scuba diving
>
> sportsurfingA spot for surfing.
>
>
>
> These do not describe the 'sport'/activity but state it is a
> 'place'/'spot' i.e. a physical thing.
>
>
>
> these descriptions are misguided and should be fixed. The tag “sport” is
> about a sport, it is a property, and unlike the wiki says, its presence
> does not even tell in every case that you can exercise the sport at an
> object with this tag. E.g.
> shop=sports
> sport=surfing
>
> The wiki is explicit: “ A sport should normally also be associated with a
> suitable physical feature where it is performed; often this is leisure
> =pitch
>  or leisure
> =trac
> 
>
>
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

[Graeme Fitzpatrick]

On Mon, 21 Dec 2020 at 09:32, Martin Koppenhoefer 
wrote:

> its presence does not even tell in every case that you can exercise the
> sport at an object with this tag. E.g.
> shop=sports
> sport=surfing
>

What would you suggest then for a shop that sells surfboards eg
https://www.google.com.au/maps/@-28.0770975,153.4431424,3a,75y,168.57h,84.72t/data=!3m6!1e1!3m4!1sw8FwnxP0v8kJgGpiKtZTFQ!2e0!7i16384!8i8192?hl=en

The wiki is explicit: “ A sport should normally also be associated with a
> suitable physical feature where it is performed; often this is leisure
> =pitch
>  or leisure
> =trac
> 
>

So that would suggest amenity=shooting_range would be a good choice?

Thanks

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Martin Koppenhoefer]

sent from a phone

> On 21. Dec 2020, at 00:28, Graeme Fitzpatrick  wrote:
> 
> There has been concern raised on the talk page over the "If it's illegal, 
> please don't map" warning that I included in the proposal.


is this referring to British law? 


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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Martin Koppenhoefer]

sent from a phone

> On 20. Dec 2020, at 22:45, Warin <61sundow...@gmail.com> wrote:
> 
> Some examples;
> 
> sportbowlsA place where you can play lawn bowls/lawn bowling.
> 
> sportkitesurfingTo mark a spot for kitesurfing
> 
> sportmultiA sports facility that is suitable for more than one 
> sport
> 
> sportracquetRacquetball facilities, such as racquetball courts
> 
> sportscuba_divingTo mark a spot for scuba diving
> 
> sportsurfingA spot for surfing.
> 
> 
> 
> 
> 
> These do not describe the 'sport'/activity but state it is a 'place'/'spot' 
> i.e. a physical thing.
> 


these descriptions are misguided and should be fixed. The tag “sport” is about 
a sport, it is a property, and unlike the wiki says, its presence does not even 
tell in every case that you can exercise the sport at an object with this tag. 
E.g.
shop=sports
sport=surfing

The wiki is explicit: “ A sport should normally also be associated with a 
suitable physical feature where it is performed; often this is leisure=pitch or 
leisure=trac


Cheers Martin 

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

Re: [Tagging] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

There has been concern raised on the talk page over the "If it's illegal,
please don't map" warning that I included in the proposal.

I put it there due to that issue being mentioned on several military
related pages, but also noticed that there are a few different wording of
it eg {{Key|military}} or landuse
=military
.

I did mention earlier that the military page needs a clean-up. When we do
that, it would be an ideal time to decide on a standard "warning" template
to go on all related pages.

Thanks

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

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Martin Koppenhoefer]

sent from a phone

> On 20. Dec 2020, at 22:50, Graeme Fitzpatrick  wrote:
> I can understand why a cyclist would like to know about them, but I'm not 
> sure how we'd map them? A way drawn along the side of the road, like a fence, 
> or added to the roads properties eg cycleway=lane + cycleway:rumble_strip=yes?


it could be done like lane tagging, see this example from the wiki:

lanes=3
oneway=yes
maxspeed:lanes=100|100|80
 in analogy:
if all dividers were rumble strips

rumble_strips=

if only the lateral borders of the carriageway were rumble strips:

rumble_strips=%||%

(to be read from left to right and in the direction of the OpenStreetMap way)


Cheers Martin 


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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Clifford Snow]

Tomas,
Please refrain from calling out others as outlined in the Etiquette
Guidelines [1]

[1] https://wiki.openstreetmap.org/wiki/Etiquette

Best,
Clifford

On Sun, Dec 20, 2020 at 12:38 PM Tomas Straupis 
wrote:

> 2020-12-20, sk, 17:59 Paul Allen rašė:
> > Too late, at least for iD.  Its authors have already decided to deprecate
> > landuse=reservoir.  All this proposal does is document the fact.
>
>   Strange sequence/logic tho:
>   1. iD brakes the rules, does something contrary to what
> OpenStreetMap/mappers do,
>   2. instead of fixing the offender - iD, Brian decides to bend the
> rules... ignoring the cartographic advantages of landuse=reservoir and
> impossibility to achieve "full rule of natural=water" in any near
> future as there are a lot of other tags to be massacred, not only
> landuse=reservoir. waterway=riverbank - 255K water=riverbank - 1K <-
> this even with iD once again lying about it being deprecated...
>
>   I hope this proposal will be ignored as the initial one ten years
> ago was. 20-30 people voting is nothing when we talk about tag with
> almost 400K and much longer usage.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Brian M. Sperlongano]

> Yes, but all proposals suggest a rendering scheme.
>

The proposal process wiki page says "Not a part of the proposals process as
such, but hints for the renderer maintainer will help them out. maybe a
description of an icon (refer Map Icons), or an example mock-up. Usually
may be safely omitted from proposal."

Remember that, at the end of the day, the output of a successful proposal
is a change to the wiki, no more, no less.  It is still up to mappers,
renderers, data consumers, editors, etc., to choose to adopt the changes
specified by an approved proposal.  In practice, approved proposals have a
strong influence on all of those user communities, but at the end of the
day, a wiki page is documentation, not legislation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Graeme Fitzpatrick]

On Sun, 20 Dec 2020 at 19:01, Martin Koppenhoefer 
wrote:

>
> On 20. Dec 2020, at 05:43, Graeme Fitzpatrick 
> wrote:
>
> The existing emergency 
> =disaster_response
> 
> will get a better definition to cover each countries Emergency Rescue /
> Civil Defence service/s
>
>
>
> which kind of places should get the tag? Garages and places where
> equipment is stored? Administrative offices? Training areas?
>

It does say: " The various emergency
=xxx

tags are intended to tag the base areas or buildings of various Emergency
Rescue groups as clearly observed. This tag is only intended to be used for
permanent features, not temporary locations eg in the field"

So pretty well all of the above, depending, of course, on what is at any
particular location. eg for this area, it would include the full fenced
area, with several buildings, carpark etc
https://www.openstreetmap.org/edit#map=19/-27.43264/153.00940, whereas
smaller units (usually in country areas) would be a shed only.

How does it relate to
> https://taginfo.openstreetmap.org/tags/emergency_service=technical ?
>
> and to https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
>

They would both be replaced by =disaster_response, which would be defined
as " each countries Emergency Rescue / Civil Defence service/" eg
Australian State Emergency Service (SES), US FEMA (Federal Emergency
Management Agency) etc

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Graeme Fitzpatrick]

On Sun, 20 Dec 2020 at 17:55, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> How objects tagged now with amenity=lifeboat_station should be tagged
> after this proposal passes?
>

They were a late addition after somebody pointed out that they exist. They
would be replaced by emergency=marine_rescue, which has already been
defined as groups " dedicated to the rescue of vessels &/or sailors at sea"

Also "The area of the Rescue base should render with the same pink colour
> as currently used for
> Police & Fire Stations, together with an "SOS" icon." is problematic as
> proposal process has no
> power to select any rendering in any map style.
>

Yes, but all proposals suggest a rendering scheme.

And in many renderers different (or none) styling is used for rendering
> this object anyway.
>

Which I hope would change?

Thanks

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

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Paul Johnson]

On Sun, Dec 20, 2020 at 4:00 PM Volker Schmidt  wrote:

> The OSM wiki page Traffic_calming defines
>
>- traffic_calming=rumble_strip
>
>
> as a structure that crosses the road. It also says explicitly:
> " Do not confuse with longitudinally placed rumble strips to alert drivers
> that they are leaving their lane, which are generally not mapped by OSM.
> (See rumble strips .)"
>
> Regarding the legal aspect of riding on the hard shoulder. I don't know
> the general rules in the US States, but I rode several hundred km on
> freeway hard shoulders in the western US that were explicitly signed as
> "cyclist use hard shoulder". If necessary I can check with my friends of
> Adventure Cycling Association - they are running a campaign to improve the
> situation regarding the danger posed by longitudinal rumbling strips in the
> US.
>

Bicycles *can* use hard shoulders, but this doesn't make the shoulder a
cycleway.  And shoulders that are open to bicycles and have been built or
rebuilt in the last decade or so will have gaps in the rumble strip
specifically to make it safer for bicycle traffic to get on or off the
shoulder safely.  There's usually 40-60 feet of rumble strip followed by a
10-15 foot long gap in a repeating pattern.  Pennsylvania has been
experimenting with buffered bike lanes, putting a rumble strip in the
buffer, but AFAICT, this is the only state that does this due to being the
only place with experimental approval to use a rumble strip on a bike lane.

But for just a generic hard shoulder on a freeway or highway?  cycleway=*
wouldn't apply at all.  Where signed as above where using the hard shoulder
is compulsory, then "no" would be a good value for all lanes in the
bicycle:lanes=* key along with bicycle=yes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Volker Schmidt]

The OSM wiki page Traffic_calming defines

   - traffic_calming=rumble_strip
   

as a structure that crosses the road. It also says explicitly:
" Do not confuse with longitudinally placed rumble strips to alert drivers
that they are leaving their lane, which are generally not mapped by OSM.
(See rumble strips .)"

Regarding the legal aspect of riding on the hard shoulder. I don't know the
general rules in the US States, but I rode several hundred km on freeway
hard shoulders in the western US that were explicitly signed as "cyclist
use hard shoulder". If necessary I can check with my friends of Adventure
Cycling Association - they are running a campaign to improve the situation
regarding the danger posed by longitudinal rumbling strips in the US.

On Sun, 20 Dec 2020 at 22:02, Paul Johnson  wrote:

>
>
> On Sun, Dec 20, 2020 at 10:27 AM Jeremy Harris  wrote:
>
>> On 20/12/2020 16:07, Volker Schmidt wrote:
>> > Is there a tagging scheme for these bicycle  killers
>> > ?
>> > I have encountered them on freeways and other major roads that allow
>> > cyclists, in the western States of the USA.
>>
>> How about
>>
>> cycleway = shoulder
>> shoulder:barrier = rumble_strip
>>
>
> I'm pretty sure a hard shoulder isn't actually a cycleway.
> ___
> 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] Continuous shoulder rumble strips (CSRS)

[Graeme Fitzpatrick]

On Mon, 21 Dec 2020 at 02:24, Seth Deegan  wrote:

> Those are known as rumble strips.
>
> The wiki has traffic_calming=rumble_strip:
> https://wiki.openstreetmap.org/wiki/Key:traffic_calming#Common_values
>

But the description for rumble strip on that page also says "Do not confuse
with longitudinally placed rumble strips to alert drivers that they are
leaving their lane, which are generally not mapped by OSM."

I can understand why a cyclist would like to know about them, but I'm not
sure how we'd map them? A way drawn along the side of the road, like a
fence, or added to the roads properties eg cycleway=lane +
cycleway:rumble_strip=yes?

& wouldn't we then have to include all the rumble strips between normal
traffic lanes?

Thanks

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Warin]

On 20/12/20 6:32 pm, Mateusz Konieczny via Tagging wrote:




Dec 20, 2020, 00:01 by 61sundow...@gmail.com:

On 20/12/20 6:45 am, Mateusz Konieczny via Tagging wrote:

Is there some good use for sport=shooting_range?

Or is it always preferable to use sport=shooting + leisure=pitch?

This is a request to review this edit

https://wiki.openstreetmap.org/w/index.php?title=Tag%3Asport%3Dshooting_range=revision=2074293=125712
that ended creating
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dshooting_range


The sport key should be used to indicate the activity .. not the
physical existence. Despite what the OSMwiki says though various
edits.

Where OSM Wiki claims that sport key alone indicates physical 
existence of something?
As far as I know it only describes that it specifies type/purpose of 
something like

leisure=pitch.



Look at the descriptions on https://wiki.openstreetmap.org/wiki/Key:sport


Some examples;

sport    bowls        A place where you can play lawn bowls/lawn bowling.

sport    kitesurfing        To mark a spot for kitesurfing

sport    multi        A sports facility that is suitable for more than 
one sport


sport    racquet        Racquetball facilities, such as racquetball courts

sport    scuba_diving        To mark a spot for scuba diving

sport    surfing        A spot for surfing.



These do not describe the 'sport'/activity but state it is a 
'place'/'spot' i.e. a physical thing.


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

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Paul Johnson]

On Sun, Dec 20, 2020 at 10:27 AM Jeremy Harris  wrote:

> On 20/12/2020 16:07, Volker Schmidt wrote:
> > Is there a tagging scheme for these bicycle  killers
> > ?
> > I have encountered them on freeways and other major roads that allow
> > cyclists, in the western States of the USA.
>
> How about
>
> cycleway = shoulder
> shoulder:barrier = rumble_strip
>

I'm pretty sure a hard shoulder isn't actually a cycleway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Brian M. Sperlongano]

Note that the shooting_range hazard is specifically about the zone in and
around a shooting range that you should avoid if you don't want to
accidentally encounter a stray bullet (the area of the hazard) rather than
as a tag for a shooting range itself.

On Sun, Dec 20, 2020 at 3:30 PM Jmapb  wrote:

> On 12/19/2020 5:16 PM, Martin Koppenhoefer wrote:
> > I agree with this, there’s a lot of abuse for “pitch”, and these are
> > not arguments for continuing the line, it’s never too late to learn
> > from past errors ;-)
> >
> > leisure=shooting_range might make sense? There are also 4000
> > military=range (is this about shooting? bombing? )
>
> I've been using leisure=sports_centre + sport=shooting for these,
> possibly combined with a building tag for an indoor range. Makes more
> sense to me to giving them a top-level leisure tag unlike all other sports.
>
> The value "shooting_range" is currently in use for the "hazard" key,
> though, and is part of the hazard=* proposal which is currently being
> voted in with flying colors. (
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard )
>
> J
>
>
> ___
> 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 - Reservoirs, lakes, and ponds

[Tomas Straupis]

2020-12-20, sk, 17:59 Paul Allen rašė:
> Too late, at least for iD.  Its authors have already decided to deprecate
> landuse=reservoir.  All this proposal does is document the fact.

  Strange sequence/logic tho:
  1. iD brakes the rules, does something contrary to what
OpenStreetMap/mappers do,
  2. instead of fixing the offender - iD, Brian decides to bend the
rules... ignoring the cartographic advantages of landuse=reservoir and
impossibility to achieve "full rule of natural=water" in any near
future as there are a lot of other tags to be massacred, not only
landuse=reservoir. waterway=riverbank - 255K water=riverbank - 1K <-
this even with iD once again lying about it being deprecated...

  I hope this proposal will be ignored as the initial one ten years
ago was. 20-30 people voting is nothing when we talk about tag with
almost 400K and much longer usage.

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Jmapb]

On 12/19/2020 5:16 PM, Martin Koppenhoefer wrote:

I agree with this, there’s a lot of abuse for “pitch”, and these are
not arguments for continuing the line, it’s never too late to learn
from past errors ;-)

leisure=shooting_range might make sense? There are also 4000
military=range (is this about shooting? bombing? )


I've been using leisure=sports_centre + sport=shooting for these,
possibly combined with a building tag for an indoor range. Makes more
sense to me to giving them a top-level leisure tag unlike all other sports.

The value "shooting_range" is currently in use for the "hazard" key,
though, and is part of the hazard=* proposal which is currently being
voted in with flying colors. (
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard )

J


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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Martin Koppenhoefer]

Am So., 20. Dez. 2020 um 17:13 Uhr schrieb Volker Schmidt :

> Martin, the former ones (
> http://www.valsassinanews.com/image/original/12663.jpg )  are "tables" (
> traffic_calming=table)  in OSM-speak - see
> https://wiki.openstreetmap.org/wiki/Key:traffic_calming.
> 
>
> I was referring to the latter ones as sausage-shaped.
>


right. Do you agree there are suspiciously often missing sections at
positions where it is convenient for all 2-wheeled vehicles that they are
missing? Do you think they are missing from the beginning, or someone
removes them after they have been put?

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 16:11, Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> I agree. To be called a "pillow", it would have to be soft and not rigid.
> IIRC there are traffic calming "pillows" that are filled with air and
> deflate, if you drive over them slowly, but remain inflated, if you drive
> over at speed.  I regret that I cannot find a reference to them at the
> moment.
>

https://en.wikipedia.org/wiki/Speed_bump#Dynamic_speed_bumps

Not what you were thinking of, but achieving the same end (the effect
depends on the speed of the vehicle):
https://www.matfoundrygroup.com/News%20and%20Blog/The_Future_of_Roads_Liquid_Speed_Bumps

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

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Jeremy Harris]

On 20/12/2020 16:07, Volker Schmidt wrote:

Is there a tagging scheme for these bicycle  killers
?
I have encountered them on freeways and other major roads that allow
cyclists, in the western States of the USA.


How about

cycleway = shoulder
shoulder:barrier = rumble_strip
--
Cheers,
  Jeremy

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

Re: [Tagging] Continuous shoulder rumble strips (CSRS)

[Seth Deegan]

Those are known as rumble strips.

The wiki has traffic_calming=rumble_strip:
https://wiki.openstreetmap.org/wiki/Key:traffic_calming#Common_values

There is no page for the tag though, differentiating the types of rumble
strips there are.

For examples, I’ve seen them on:
The side of a highway (short spaces between bumps)
There are also different types/designs for these:
https://safety.fhwa.dot.gov/roadway_dept/pavement/rumble_strips/rumble_types/


Before construction zones or other approaching features (longer spaces to
warn drivers)
https://commons.m.wikimedia.org/wiki/File:North_Luzon_Expressway_Rumble_Strips.jpg#mw-jump-to-license


El El dom, dic. 20, 2020 a la(s) 10:09, Volker Schmidt 
escribió:

> Is there a tagging scheme for these bicycle  killers
> ?
> I have encountered them on freeways and other major roads that allow
> cyclists, in the western States of the USA. In theory there should be no
> problem, as the cyclist is supposed to be on the shoulder all the time, but
> in practice there are many situations where the shoulder is simply not
> usable, and so you have to cross over them and back to avoid the obstacles
> (in most cases a tyre carcass which sheds the dreaded bent-needle shaped
> tire flatteners for cyclists)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Volker Schmidt]

Martin, the former ones (
http://www.valsassinanews.com/image/original/12663.jpg )  are "tables" (
traffic_calming=table)  in OSM-speak - see
https://wiki.openstreetmap.org/wiki/Key:traffic_calming.


I was referring to the latter ones as sausage-shaped.

On Sun, 20 Dec 2020 at 17:02, Martin Koppenhoefer 
wrote:

> Am So., 20. Dez. 2020 um 16:11 Uhr schrieb Niels Elgaard Larsen <
> elga...@agol.dk>:
>
>> Martin Koppenhoefer:
>> > I thought they would make people drive slower, while retaining a
>> possibility for
>> > bicycles to pass in between.
>>
>> That is what the proposal says. But there is no way a bicycle could pass
>> between
>> those seen on the proposal page at anything near normal bicycling speed.
>
>
>
>
> in Italy common bumps are like these:
> http://www.valsassinanews.com/image/original/12663.jpg
> which do not pose a problem to cyclists at bicycle speed.
>
> and there are variations of these:
>
> http://www.terminalmilazzo.com/wp-content/uploads/2019/03/dosso-artificiale-300x169.jpg
> where quite often you can be lucky and one segment, to pass through by
> bike, is missing for reason or the other.
>
> 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 - Tag:traffic_calming=hillocky

[Peter Neale via Tagging]

I agree. To be called a "pillow", it would have to be soft and not rigid.  IIRC 
there are traffic calming "pillows" that are filled with air and deflate, if 
you drive over them slowly, but remain inflated, if you drive over at speed.  I 
regret that I cannot find a reference to them at the moment.
That is not what these seem to be.
"Deceleration Dots" / "Traffic Calming Dots" ??? 
Having said all that, someone seems to think that "speed cushions" can be made 
of concrete, despite "cushions" in normal GB English being just as soft as 
"pillows"  (Cushions on the sofa; pillows on the bed)
https://www.trafficchoices.co.uk/traffic-schemes/speed-cushions.shtml

Regards,Peter   
>Date: Sun, 20 Dec 2020 15:12:14 +
>From: Paul Allen 
>To: 80hnhtv4a...@bk.ru
>Cc: "Tag discussion, strategy and related tools"
>   
>Subject: Re: [Tagging] Feature Proposal - RFC -
>   Tag:traffic_calming=hillocky
>Message-ID:
>    
>Content-Type: text/plain; charset="utf-8"

>On Sun, 20 Dec 2020 at 14:55, <80hnhtv4a...@bk.ru> wrote:

>> traffic calming device often used in *Czech republic*
>>
>> I found this;
>> https://cs.wikipedia.org/wiki/Zpomalovac%C3%AD_pr%C3%A1h
>>
>> >
>>
>> Zpomalovací polštáře, = english, Deceleration pillows
>>

>"Pillow" in English would not be associated with that shape and
>rigidity.  This is a pillow:
>https://en.wikipedia.org/wiki/File:Average_White_Pillow.jpg

>I doubt any English speaker would look at one of those devices and
>describe it as a pillow.

>-- 
>Paul
-- next part --

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

[Tagging] Continuous shoulder rumble strips (CSRS)

[Volker Schmidt]

Is there a tagging scheme for these bicycle  killers
?
I have encountered them on freeways and other major roads that allow
cyclists, in the western States of the USA. In theory there should be no
problem, as the cyclist is supposed to be on the shoulder all the time, but
in practice there are many situations where the shoulder is simply not
usable, and so you have to cross over them and back to avoid the obstacles
(in most cases a tyre carcass which sheds the dreaded bent-needle shaped
tire flatteners for cyclists)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Martin Koppenhoefer]

Am So., 20. Dez. 2020 um 16:11 Uhr schrieb Niels Elgaard Larsen <
elga...@agol.dk>:

> Martin Koppenhoefer:
> > I thought they would make people drive slower, while retaining a
> possibility for
> > bicycles to pass in between.
>
> That is what the proposal says. But there is no way a bicycle could pass
> between
> those seen on the proposal page at anything near normal bicycling speed.




in Italy common bumps are like these:
http://www.valsassinanews.com/image/original/12663.jpg
which do not pose a problem to cyclists at bicycle speed.

and there are variations of these:
http://www.terminalmilazzo.com/wp-content/uploads/2019/03/dosso-artificiale-300x169.jpg
where quite often you can be lucky and one segment, to pass through by
bike, is missing for reason or the other.

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Paul Allen]

On Sun, 20 Dec 2020 at 15:29, Volker Schmidt  wrote:

>
>
>
> In addition, please consider that deprecated features are being flagged by
> editor sw on
>
saving any changeet that contains an deprecated tag, even if it has nothing
> to do
>
with your actual editing, this would be adding another contnued nuisance
> for mappers
>
(there are already others opf that type).
>

> Please don't do it
>

Too late, at least for iD.  Its authors have already decided to deprecate
landuse=reservoir.  All this proposal does is document the fact.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Volker Schmidt]

These objects need a new tag, not  a sub-tag of traffic_calming=bump (220k
uses), for the simple reason that it has a different effect on the road
users.
I have myself tagged many such sausage-shaped bumps with
traffic_calming=bump and no sub-tag. They slow down every vehicle, but are
not as particularly nasty to cyclists and, probably, motor cyclists as the
ones in the sample pictures.
If you were to create a sub-tag for the new ones, we would need to add a
dìfferent sub-tag to all the existing occurrences of .

Concerning the tagging:
If they are used only in a few countries, then we may want to use the term
used in one of these country, if  there is no British English term
available.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Paul Allen]

On Sun, 20 Dec 2020 at 15:05, Jeremy Harris  wrote:

> On 20/12/2020 14:42, Paul Allen wrote:
> > There may be many uncontrolled crossings (no lights, no
> > zebra markings) in built-up areas, mostly at junctions.  They
> > typically have a dropped curb with tactile paving of a
> > different colour (does that count as markings or not?).
>
> I use
>
> crossing=unmarked
> tactile_paving=yes
>
> for those.
>

That's probably as good as we have, for now.  I'd go with
tactile_paving=contrasted, if appropriate.  But it doesn't cover
priority.  Until I took a close look at the rules today, I didn't
realize that if it's at a junction then pedestrians crossing
have priority over vehicles turning into the junction (but
presumably not over vehicles turning out of the junction).
No, I'm not a dangerous driver who doesn't know the rules,
I'm a dangerous pedestrian.

That priority over vehicles turning into the junction
makes life easier at an otherwise difficult crossing
near me.  Maybe.  The crossing goes across a
one-way street, so I don't have to worry about cars
turning out of the junction (there aren't any).  But
the layout of the one way system means cars
coming from one direction are forced to turn into
it, so are they really turning into it or just keeping
in lane?  https://goo.gl/maps/JCpDmKtsyZcYSkVm7

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Alan Mackie]

On Sun, 20 Dec 2020 at 10:11, Niels Elgaard Larsen  wrote:

> Martin Koppenhoefer:
> >
> >
> > sent from a phone
> >
> >> On 19. Dec 2020, at 23:27, Brian M. Sperlongano 
> wrote:
> >>
> >> I understand that the purpose of them is simply to make noise when a
> car drives
> >> over them, as they don't slow you down in any appreciable way like a
> speed bump/hump.
> >
> >
> > I thought they would make people drive slower, while retaining a
> possibility for
> > bicycles to pass in between.
>
> That is what the proposal says. But there is no way a bicycle could pass
> between
> those seen on the proposal page at anything near normal bicycling speed.
>
> If you want to allow bicycle
>
> In Denmark we have a larger version of round speed bumps. Usually only 2
> or three in
> each direction.
>
>
> https://aarhus.lokalavisen.dk/aarhus_midt/2dzeno-Carsten-Hedegaard-Simonsen-kigger-ned-p%C3%A5-vejbump/alternates/LANDSCAPE_640/Carsten%20Hedegaard%20Simonsen%20kigger%20ned%20p%C3%A5%20vejbump
>
> They are named "pukkelbump" which translates as hump bumps.
>
> More informally they are called turtle bumps.
>
> So maybe we should call them hedgehog bumps and turtle bumps.
>
Maybe something a bit less 'literary' such as "=dome_array" or
"=rumble_domes" for the small ones and "=dome_bumps" for the larger
depending on whether you would expect them to alert the driver by vibration
or an abrupt bounce?

>
> > I guess these would be counted in?
> > https://www.durabump.com/ 
> >
> > Cheers Martin
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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 - Reservoirs, lakes, and ponds

[Volker Schmidt]

383 813
*landuse* 
*reservoir* 
334 450
*water* 
*reservoir* 
I think it does make no sense to deprecate a tag with 380k uses.
The two will stay with us in parallel for the entire lifetime off the OSM
database
As you rightly state that no automatic conversion should be used, any
atempt of manual editing is a waste of time.
In addition, please consider that deprecated features are being flagged by
editor sw on saving any changeet that contains an deprecated tag, even if
it has nothing to do with your actual editing, this would be adding another
contnued nuisance for mappers (there are already others opf that type).

Please don't do it

Volker

On Sun, 20 Dec 2020 at 15:58, Brian M. Sperlongano 
wrote:

> A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is
> now open for comments.
>
> This proposal:
>
>   1. Deprecates landuse=reservoir
>   2. Provides definitions for:
>  a. water=reservoir
>  b. water=lake
>  c. water=pond
>
> It is clear from various multiple discussions on this topic that there are
> still open questions from the original 2011 water=* proposal, as well as
> the exact definition of a reservoir, and how they differ from lakes and
> ponds.  Previous discussions indicated that there is community support for
> maintaining a distinction between lake and pond, rather than eliminating or
> merging these concepts.
>
> The definitions posed in this proposal were developed with the help of
> considerable community input over the last week, and I want to thank the
> numerous folks that collaborated on this.  The real world presents many
> edge cases that make it challenging to come up with clear definitions, but
> that should not prevent us from trying.
>
> The goal in these definitions is to *describe* rather than *prescribe* how
> reservoir, lake, and pond are actually tagged.  This necessarily involves
> some degree of subjectivity between the categories, and the proposed
> definitions leave it to mappers to make these subjective decisions when a
> body of water exhibits some characteristics of more than one of these terms.
>
> As this topic has been discussed ad nauseam for nearly a decade, I hope
> that this proposal, discussion, and subsequent vote will allow us to put
> this issue to rest, and/or document the level of community support that
> exists for different tagging schemes.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> ___
> 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 - Tag:traffic_calming=hillocky

[Tomáš Hurýn]

Thank you for the example. This could be another specific calming device - I 
really want the be notified by navigation when I ride motorbike 

20. prosince 2020 16:08:35 SEČ, Niels Elgaard Larsen  napsal:
>Martin Koppenhoefer:
>> 
>> 
>> sent from a phone
>> 
>>> On 19. Dec 2020, at 23:27, Brian M. Sperlongano
> wrote:
>>>
>>> I understand that the purpose of them is simply to make noise when a
>car drives 
>>> over them, as they don't slow you down in any appreciable way like a
>speed bump/hump.
>> 
>> 
>> I thought they would make people drive slower, while retaining a
>possibility for 
>> bicycles to pass in between.
>
>That is what the proposal says. But there is no way a bicycle could
>pass between 
>those seen on the proposal page at anything near normal bicycling
>speed.
>
>If you want to allow bicycle
>
>In Denmark we have a larger version of round speed bumps. Usually only
>2 or three in 
>each direction.
>
>https://aarhus.lokalavisen.dk/aarhus_midt/2dzeno-Carsten-Hedegaard-Simonsen-kigger-ned-p%C3%A5-vejbump/alternates/LANDSCAPE_640/Carsten%20Hedegaard%20Simonsen%20kigger%20ned%20p%C3%A5%20vejbump
>
>They are named "pukkelbump" which translates as hump bumps.
>
>More informally they are called turtle bumps.
>
>So maybe we should call them hedgehog bumps and turtle bumps.
>
>> I guess these would be counted in?
>> https://www.durabump.com/ 
>> 
>> Cheers Martin
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>
>
>-- 
>Niels Elgaard Larsen
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 14:55, <80hnhtv4a...@bk.ru> wrote:

> traffic calming device often used in *Czech republic*
>
> I found this;
> https://cs.wikipedia.org/wiki/Zpomalovac%C3%AD_pr%C3%A1h
>
> 
>
> Zpomalovací polštáře, = english, Deceleration pillows
>

"Pillow" in English would not be associated with that shape and
rigidity.  This is a pillow:
https://en.wikipedia.org/wiki/File:Average_White_Pillow.jpg

I doubt any English speaker would look at one of those devices and
describe it as a pillow.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Niels Elgaard Larsen]

Martin Koppenhoefer:



sent from a phone


On 19. Dec 2020, at 23:27, Brian M. Sperlongano  wrote:

I understand that the purpose of them is simply to make noise when a car drives 
over them, as they don't slow you down in any appreciable way like a speed bump/hump.



I thought they would make people drive slower, while retaining a possibility for 
bicycles to pass in between.


That is what the proposal says. But there is no way a bicycle could pass between 
those seen on the proposal page at anything near normal bicycling speed.


If you want to allow bicycle

In Denmark we have a larger version of round speed bumps. Usually only 2 or three in 
each direction.


https://aarhus.lokalavisen.dk/aarhus_midt/2dzeno-Carsten-Hedegaard-Simonsen-kigger-ned-p%C3%A5-vejbump/alternates/LANDSCAPE_640/Carsten%20Hedegaard%20Simonsen%20kigger%20ned%20p%C3%A5%20vejbump

They are named "pukkelbump" which translates as hump bumps.

More informally they are called turtle bumps.

So maybe we should call them hedgehog bumps and turtle bumps.


I guess these would be counted in?
https://www.durabump.com/ 

Cheers Martin

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




--
Niels Elgaard Larsen

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Jeremy Harris]

On 20/12/2020 14:42, Paul Allen wrote:

There may be many uncontrolled crossings (no lights, no
zebra markings) in built-up areas, mostly at junctions.  They
typically have a dropped curb with tactile paving of a
different colour (does that count as markings or not?).


I use

crossing=unmarked
tactile_paving=yes

for those.
--
Cheers,
  Jeremy

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[80hnhtv4agou--- via Tagging]

traffic calming device often used in  Czech republic
 
I found this;
https://cs.wikipedia.org/wiki/Zpomalovac%C3%AD_pr%C3%A1h
 
https://www.google.com/search?client=opera=Zpomalovací+polštáře=opera=UTF-8=UTF-8
 
https://cs.wikipedia.org/wiki/Zpomalovací_práh#/media/Soubor:Zpomalovací_polštáře.jpg
 
Zpomalovací polštáře, = english,  Deceleration pillows   
>Sunday, December 20, 2020 6:48 AM -06:00 from Paul Allen :
> 
>On Sun, 20 Dec 2020 at 12:32, Brian M. Sperlongano < zelonew...@gmail.com > 
>wrote:
>>  
>>>"Hillock" is quite common in British English
>> 
>>To describe a traffic control device?
>> 
>It is not the first word that came to my mind when I saw a picture of them.
>Not the second, either.  Maybe the 49th.
> 
>The first word was "molehills."  The second was "mounds."  The third was
>"dalek."  And I'm no longer sure that "mounds" is suitable.
> 
>--
>Paul
> 
>___
>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] Feature Proposal - RFC - Reservoirs, lakes, and ponds

[Brian M. Sperlongano]

A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is now
open for comments.

This proposal:

  1. Deprecates landuse=reservoir
  2. Provides definitions for:
 a. water=reservoir
 b. water=lake
 c. water=pond

It is clear from various multiple discussions on this topic that there are
still open questions from the original 2011 water=* proposal, as well as
the exact definition of a reservoir, and how they differ from lakes and
ponds.  Previous discussions indicated that there is community support for
maintaining a distinction between lake and pond, rather than eliminating or
merging these concepts.

The definitions posed in this proposal were developed with the help of
considerable community input over the last week, and I want to thank the
numerous folks that collaborated on this.  The real world presents many
edge cases that make it challenging to come up with clear definitions, but
that should not prevent us from trying.

The goal in these definitions is to *describe* rather than *prescribe* how
reservoir, lake, and pond are actually tagged.  This necessarily involves
some degree of subjectivity between the categories, and the proposed
definitions leave it to mappers to make these subjective decisions when a
body of water exhibits some characteristics of more than one of these terms.

As this topic has been discussed ad nauseam for nearly a decade, I hope
that this proposal, discussion, and subsequent vote will allow us to put
this issue to rest, and/or document the level of community support that
exists for different tagging schemes.

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Paul Allen]

On Sun, 20 Dec 2020 at 13:57, ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

>
> From reading all these comments, it is clear a "crossing=priority" is not
> a good tag. In many places, pedestrians always have priority at
> intersections even if there is no crossing. The "crossing=priority",
> however, assumed that the crossing is marked (if it gives priority). This
> is because of my experience in the UK.
>

Even in the UK it's not quite that simple.

At light-controlled crossings, vehicles must stop on red whether there are
pedestrians or not.  On flashing amber, vehicles must give way to
pedestrians but may proceed with caution if there are no pedestrians.
Even on green, vehicles must give way to pedestrians still on the
crossing (there shouldn't be any, but if there are...)

At zebra crossings, vehicles must slow down if pedestrians are
waiting to cross.  However, vehicles do not have to give way to
pedestrians until they move onto the crossing (this contrasts
with priorities in other countries where pedestrians waiting
to cross but have not yet stepped onto the crossing have priority).

There may be many uncontrolled crossings (no lights, no
zebra markings) in built-up areas, mostly at junctions.  They
typically have a dropped curb with tactile paving of a
different colour (does that count as markings or not?).
Cars have priority (pedestrians must wait for a gap in
traffic) but once a pedestrian has started to cross,
the pedestrian has priority over traffic turning
into the junction.

Crossing is legal elsewhere (unlike some jurisdictions)
but pedestrians are advised to use a controlled crossing
if there is one nearby.  Pedestrians do not have
priority even when they're on the road but motorists
are required to try to avoid running over pedestrians.

There are probably cases I've missed.

Pedestrian priority isn't a simple yes/no.

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[ipswichmapper--- via Tagging]

Hello everyone,

I haven't really explained myself since I cancelled this proposal 7 days ago. 
However, just now this proposal was mentioned on WeeklyOSM, so I just want to 
clarify why I have cancelled this proposal.

>From reading all these comments, it is clear a "crossing=priority" is not a 
>good tag. In many places, pedestrians always have priority at intersections 
>even if there is no crossing. The "crossing=priority", however, assumed that 
>the crossing is marked (if it gives priority). This is because of my 
>experience in the UK. 

Furthermore, there seems to be much bigger structural problems with the current 
"crossing" tagging scheme. Therefore, a proposal to improve crossing should be 
more detailed and make more improvements.

My proposal was hacked together in about an hour, mainly because I wanted to 
see how to create proposals, but also because I thought this was a simply issue 
with the current tagging that could quickly be fixed. 

I don't have time to create a new, more detailed crossing proposal, but if 
anyone does, here is what should be done:

- A separate tag for priority e.g. "crossing:priority=yes", where yes indicates 
those who are using the crossing have immediate priority over those who are on 
the road.
- Potentially depreciating "crossing=uncontrolled" (but this would require 
"crossing=marked" and "crossing=unmarked" to be crystal clear.
- Making it clear what "crossing=marked" means. For example, does there need to 
be marking on the road? Or is tactile paving on the sidewalk considered 
"marked"?
- add additional tags to describe more of a crossing, for example 
"crossing:belisha_beacon=*", "crossing:kerb_extension", 
"crossing:buffer_marking" etc.
(see: 
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Fu%C3%9Fwege#Gehwegvorstreckung
 )
- What should be considered a crossing? If it is unmarked, is it a crossing at 
all? (Should all intersections be tagged as "unmarked crossings"? Are places 
with traffic islands (no kerbs) where people frequently cross considered as 
crossings even though they have no marking & no kerbs?)

All of these things (AND MORE) need to be considered properly when creating a 
new crossing proposal. 

If anyone has the time to do something like this, that would be great.

Thanks,
IpswichMapper
-- 
 


13 Dec 2020, 19:25 by tagging@openstreetmap.org:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority 
> 
>
> Here is my first proposal for a tag to describe pedestrian crossings where 
> the pedestrian has right of way over all vehicles on the road from the moment 
> they have indicated their intent to cross. I created this because 
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the 
> proposal for more details.
>
> Thanks,
> IpswichMapper
>

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[ael via Tagging]

On Sun, Dec 20, 2020 at 07:30:26AM -0500, Brian M. Sperlongano wrote:
> > "Hillock" is quite common in British English
> 
> 
> To describe a traffic control device?

No.

ael


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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 12:32, Brian M. Sperlongano 
wrote:

>
> "Hillock" is quite common in British English
>
>
> To describe a traffic control device?
>
> It is not the first word that came to my mind when I saw a picture of them.
Not the second, either.  Maybe the 49th.

The first word was "molehills."  The second was "mounds."  The third was
"dalek."  And I'm no longer sure that "mounds" is suitable.

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Brian M. Sperlongano]

> "Hillock" is quite common in British English


To describe a traffic control device?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Paul Allen]

On Sun, 20 Dec 2020 at 11:52, Peter Elderson  wrote:

> I'd say they are small mounds.
>

Talk to an archaeologist and mounds can be quite large.  Talk to
a baseball player and mounds are smaller than archaeological
mounds but still quite a bit larger than these speed bumps.

>
> Hillock sounds too, er, hilly.
>

Indeed.  Hillocks are small hills.  Bigger than mounds.

Sadly, the manufacturers and purveyors of these things haven't
come up with a name for this particular type of speed bump,
other than proprietary, trademarked names like "Dura-bump,"
and we can't use trademarked names when they are
available from more than one manufacturer under
different trademarked names.

Even if we decide that "hillock" is a suitable description
the tag should be "hillocks" not "hillocky."  A noun, not an
adjective.  Plural because it takes more than one of them to
constitute a traffic calming measure.

They still look about the size and shape of molehills to me.
I suspect that "molehill" will enter the vernacular as a
way of referring to them - if they look like molehills...

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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Peter Elderson]

I'd say they are small mounds.

Hillock sounds too, er, hilly.

Peter Elderson


Op zo 20 dec. 2020 om 11:39 schreef ael via Tagging <
tagging@openstreetmap.org>:

> > I'm uncomfortable with hillock/hillocky as a value.
>
> "Hillock" is quite common in British English, not that I am comfortable
> using it as a tag.
>
> ael
>
>
> ___
> 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 - Tag:traffic_calming=hillocky

[Yves via Tagging]

Maybe it's time to create a sub-category of traffic_calming=bump with another 
tag for the peace of mind of data consumer and not bridle too much (though I 
think it is not possible) the creativity of traffic calming features creators?
Yves 

Le 20 décembre 2020 11:42:56 GMT+01:00, "Tomáš Hurýn"  a 
écrit :
>ok, so we can call value fo this tag: circle_humps. What do you all think of 
>it?
>
>Dne neděle 20. prosince 2020 0:31:07 CET, 80hnhtv4agou--- via Tagging 
>napsal(a):
>> Round Circle Speed Humps
>> 
>> >Saturday, December 19, 2020 5:29 PM -06:00 from Paul Allen
>> >: 
>> >
>> >On Sat, 19 Dec 2020 at 23:19, 80hnhtv4agou--- via Tagging < 
>tagging@openstreetmap.org > wrote:
>> >>https://streetsolutionsuk.co.uk/collections/speed-ramps/products/round-yel
>> >>low-circle-speed-humps-50mm?variant=19772633645113>
>> > 
>> >That didn't take me where you intended.  I had to navigate from where I
>> >ended up to those things.  Ended up at the URL you gave, but couldn't get
>> >there directly.  It calls them speed bumps.  Which doesn't answer my
>> >original question of whether the word "bumb" in the proposal was a typo or
>> >yet another kind of traffic calming device.
>> > 
>> >It also doesn't directly answer if these function in the same way as
>> >rumble strips or as speed bumps, but from the name I'd guess
>> >they're not an alternative to rumble strips.
>> > 
>> >--
>> >Paul
>> > 
>> 
>>  
>>  
>>  
>>  
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Tomáš Hurýn]

ok, so we can call value fo this tag: circle_humps. What do you all think of it?

Dne neděle 20. prosince 2020 0:31:07 CET, 80hnhtv4agou--- via Tagging napsal(a):
> Round Circle Speed Humps
> 
> >Saturday, December 19, 2020 5:29 PM -06:00 from Paul Allen
> >: 
> >
> >On Sat, 19 Dec 2020 at 23:19, 80hnhtv4agou--- via Tagging < 
tagging@openstreetmap.org > wrote:
> >>https://streetsolutionsuk.co.uk/collections/speed-ramps/products/round-yel
> >>low-circle-speed-humps-50mm?variant=19772633645113>
> > 
> >That didn't take me where you intended.  I had to navigate from where I
> >ended up to those things.  Ended up at the URL you gave, but couldn't get
> >there directly.  It calls them speed bumps.  Which doesn't answer my
> >original question of whether the word "bumb" in the proposal was a typo or
> >yet another kind of traffic calming device.
> > 
> >It also doesn't directly answer if these function in the same way as
> >rumble strips or as speed bumps, but from the name I'd guess
> >they're not an alternative to rumble strips.
> > 
> >--
> >Paul
> > 
> 
>  
>  
>  
>  


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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Tomáš Hurýn]

I was thinking a lot about it. But bump is not so appropriate fot this kind of 
device bacuase it has specific qualities.

Dne neděle 20. prosince 2020 1:06:33 CET, Graeme Fitzpatrick napsal(a):
> On Sun, 20 Dec 2020 at 09:32, Paul Allen  wrote:
> > It calls them speed bumps.
> 
> Yep, it seems like these are just a variety of speed bump
> https://wiki.openstreetmap.org/wiki/Key:traffic_calming & =bump.
> 
> The existing definition is more or less OK in that it includes
> 
> Thanks
> 
> Graeme


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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[ael via Tagging]

> I'm uncomfortable with hillock/hillocky as a value.

"Hillock" is quite common in British English, not that I am comfortable
using it as a tag.

ael


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

Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Tomáš Hurýn]

That is definitelly not rumble_strip, a car has to slow down to pass this 
device. It's not just 
about the noice.

Dne sobota 19. prosince 2020 23:24:58 CET, Brian M. Sperlongano napsal(a):
> I've seen these in the US also, but I never knew what they were called.  I
> understand that the purpose of them is simply to make noise when a car
> drives over them, as they don't slow you down in any appreciable way like a
> speed bump/hump.
> 
> We already have a tag for "a traffic calming device that makes noise when a
> car drives over it", which is a rumble strip
> (see: traffic_calming=rumble_strip).  Note, I am talking about the kind
> that go all the way across the road, and not the kind in the shoulder of
> the road that make noise when you veer out of your lane.
> 
> I usually think of rumble strips as grooves in the road, but it strikes me
> that these micro-speed-bump things are essentially the same thing -- they
> make noise when a car goes over it to alert the driver of something.
> 
> I'm uncomfortable with hillock/hillocky as a value.  Cursory searches seem
> to indicate that this isn't a term in use, in any flavor of English.
> 
> On Sat, Dec 19, 2020 at 5:08 PM Martin Koppenhoefer 
> wrote:
> > sent from a phone
> > 
> > > On 19. Dec 2020, at 22:53, Jeremy Harris  wrote:
> > > 
> > > traffic_calming=multi_bump  ?
> > 
> > or
> > traffic_calming=mini_bumps ?
> > 
> > when they come up with something smaller that could still be micro_bumps
> > ;-)
> > 
> > 
> > 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 - Tag:traffic_calming=hillocky

[Tomáš Hurýn]

Thank you, the description is more appropriate now.

Dne sobota 19. prosince 2020 20:43:00 CET, Mateusz Konieczny via Tagging 
napsal(a):
> Thanks for documenting this new value!
> 
> I edited page in attempt to provide more specific definition
> (based on photos).
> 
> To author of a proposal: feel free to revert my edit or change it
> or do something else with it
> 
> I wonder whatever there is even a British English name for that
> (or is hillocky an UK name?)
> 
> Dec 19, 2020, 19:23 by thur...@gmail.com:
> > Hi,
> > 
> > 
> >   I would like introduce traffic calming device not present in the list of
> > devices.
> > 
> > 
> > 
> > Definition: A traffic calming device with specific qualities
> > 
> > 
> > 
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%
> > 3Dhillocky>  
> > 
> > 
> > 
> > 
> > Regards,
> > 
> > 
> > Tomas Huryn


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

Re: [Tagging] Tagging sewage treatment basins

[Minh Nguyen]

Vào lúc 09:42 2020-12-18, Martin Koppenhoefer đã viết:
Am Fr., 18. Dez. 2020 um 12:32 Uhr schrieb Paul Allen 
>:


I'm not entirely happy with natural=water being applied to either sewage
treatment or slurry.  Neither are natural and neither store water.



neither am I, not for the question of how "natural" they are (ship has 
sailed) but because I would not consider "slurry" to be "water", 
although they contain mostly water (looking at the parts) - 10% sulfuric 
acid is also mostly water. Milk is also mostly water, as is beer.


I'm glad I'm not alone in stubbornly avoiding the troll-tagging of 
tailing ponds and pig lagoons as natural=water. I'm fine with putting 
most reservoirs under natural=water, but this tag doesn't have to hold a 
monopoly on bodies of liquid. After all, clorinated pool water is mostly 
water, but we use leisure=swimming_pool as has been mentioned. A marsh 
is mostly covered by naturally collecting water, but there's 
natural=wetland and a whole wetland=* tagging scheme for that.


Most paper maps I've come across have treated bodies of water as 
distinct from bodies of other liquids, if they show the latter at all. 
For example, the USGS topographic maps cited earlier in this thread make 
no distinction between natural lakes and dammed reservoirs, but tailing 
ponds have completely different symbology. [1] If a renderer were 
unprepared to give special treatment to tailing ponds, I personally 
think it would be better for the renderer to omit them than to render 
them as bodies of water. That might require an altogether different 
primary tag like man_made=reservoir, since it's so common to render 
landuse=reservoir just like natural=water.


landuse=reservoir is an unintuitive tag for water-filled reservoirs, 
anyways. The pedant in me wants to double-map a reservoir as two areas: 
a landuse=reservoir area for the land underneath and a coincident, 
connected natural=water area for the H2O above it. But people complain 
about connecting landuse areas to other features, so I'll have to wait 
until April Fool's Day. ;-)


[1] 
https://pubs.usgs.gov/gip/TopographicMapSymbols/topomapsymbols.pdf#page=4


--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

[Martin Koppenhoefer]

sent from a phone

> On 20. Dec 2020, at 05:43, Graeme Fitzpatrick  wrote:
> 
> The existing emergency=disaster_response will get a better definition to 
> cover each countries Emergency Rescue / Civil Defence service/s


which kind of places should get the tag? Garages and places where equipment is 
stored? Administrative offices? Training areas? 


How does it relate to 
https://taginfo.openstreetmap.org/tags/emergency_service=technical ?

and to https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
?


Cheers Martin 

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