Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

This is probably a US-centric viewpoint, but I note that there is a general lack of tagging under the military= key to indicate the military branch associated with a military base. For example, we have military=naval_base, but no equivalent tagging for army, air force, amphibious, (dare I say

Re: [Tagging] Feature Proposal - RFC - Hazards

I want to address the points that were raised on crossings. As we already have highway=crossing, I have resisted adding new hazard=* values for crossing hazards, as that is properly the domain of the highway=crossing tag. For golf cart crossing, there is already an established tag combination

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

itutes a 'hazard'. > > > On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano > wrote: > >> I'd think that frost heaves (which are seasonal and conditions-based) >> versus permanent bumps are different. If there aren't objections, I'd >> propose both a hazard=bum

Re: [Tagging] Feature Proposal - RFC - Hazards

alues that people feel strongly about including". On Fri, Dec 4, 2020 at 2:56 PM Martin Koppenhoefer wrote: > sent from a phone > > > On 4. Dec 2020, at 17:42, Brian M. Sperlongano > wrote: > > > > I am thinking this case (crossing golfers) is more of a highway=crossing

Re: [Tagging] Feature Proposal - RFC - Hazards

I am thinking this case (crossing golfers) is more of a highway=crossing rather than a hazard? There appear to be no existing values of hazard for indicating crossing golfers to lean on here. On Fri, Dec 4, 2020 at 11:23 AM Niels Elgaard Larsen wrote: > Brian M. Sperlongano: > > Niel

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

I poked into the existing usages of hazard=landslide, and they seem to mostly be on hiking trails or at best track roads, rather than regular roads. I don't think anyone would quibble with tagging a landslide hazard on this [1] for example. [1]

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

On Thu, Dec 3, 2020 at 12:54 PM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > I am not exactly happy about "rock slide" as it seems weird to use it where > danger is primarily about individual rocks dropping, not about full scale > rock slide. > > Personally I would prefer

Re: [Tagging] Feature Proposal - RFC - Hazards (frost heave?)

unted, while other > locations get folding signage. As these are point features with varying > placement of signage, I would suggest mapping them as nodes on a roadway at > the heave position with something like hazard=frost_heave. Alternatively, > hazard=bump may be applicable to ot

[Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

Hello, I've made a number of updates to the "hazard" proposal [1] based on the input received. Thanks to those that offered comment and feedback so far during this RFC. I request community help on resolving feedback on the proposed tag hazard=rock_slide and deprecation of three values of

Re: [Tagging] Animal trails

On Wed, Dec 2, 2020 at 7:03 AM Martin Koppenhoefer wrote: > Am Di., 1. Dez. 2020 um 18:08 Uhr schrieb Brian M. Sperlongano < > zelonew...@gmail.com>: > >> +1, it's unreasonable for mappers to be mind readers about the intent of >> land managers. Either th

Re: [Tagging] Animal trails

On Tue, Dec 1, 2020 at 11:59 AM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > > Dec 1, 2020, 00:44 by dieterdre...@gmail.com: > > > Am Di., 1. Dez. 2020 um 00:39 Uhr schrieb Lukas Richert < > lrich...@posteo.net>: > > I wouldn't tag this as foot=no or access=no. There are

Re: [Tagging] Animal trails

Note that there is already an animal=* tag for describing things related to animals, so that probably shouldn't be overridden. Perhaps a combination of foot=no and animal=yes satisfies what we're describing? On Mon, Nov 30, 2020 at 4:16 PM Graeme Fitzpatrick wrote: > > > > On Tue, 1 Dec 2020

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

at 8:38 AM ael via Tagging wrote: > On Thu, Nov 26, 2020 at 04:01:09PM -0500, Brian M. Sperlongano wrote: > > On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging < > tagging@openstreetmap.org> > > wrote: > > > > > On Thu, Nov 26, 2020 at 09:11:25AM -0500, B

Re: [Tagging] Feature Proposal - RFC - Hazards

of the hazard key that I can find for an active military conflict zone, other than hazard=minefield. On Fri, Nov 27, 2020 at 8:28 AM Andy Townsend wrote: > > On 27/11/2020 04:25, Brian M. Sperlongano wrote: > > Assuming that the boundary of that area is reasonably permanent, my firs

Re: [Tagging] Feature Proposal - RFC - Hazards

www.retsinformation.dk/image.aspx?id=196668=CX316_8_82.png > https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_83.png > > Queue risk: > https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_44.png > > Dangerous intersections > https://www.retsinformation.d

Re: [Tagging] Feature Proposal - RFC - Hazards

Assuming that the boundary of that area is reasonably permanent, my first reaction is that this could be described by military=danger_area. However, that tag requires landuse=military as the primary tag, which probably isn't correct here. On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

: > Am Do., 26. Nov. 2020 um 17:48 Uhr schrieb Brian M. Sperlongano < > zelonew...@gmail.com>: > >> This is good feedback, and I would potentially toss another into the >> mix: hazard=erosion which has about 300 tags. Do we think these four tags >> (rock_sli

[Tagging] Feature Proposal - Vote Result - Special Economic Zone

The result of voting on the proposal "Special Economic Zone" is: 25 in favor 2 opposed 0 abstentions The two votes in opposition expressed a preference for the use of protect_class=23 for tagging these areas. The community consensus is to approve boundary=special_economic_zone and deprecate

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging wrote: > On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote: > > I am not opposed to including unsigned hazards > > There are a surprising number of abandoned open mineshafts in the far > West of England

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

This [1] testing site in my state opened back in July (five months ago) and is dedicated to COVID testing only. These sites[2] opened in May (seven months ago) and are still going strong. They are co-located with a pharmacy (usually in the parking lot). While they may be "temporary" as in "when

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

> > >- The use of hazard = >rock_slide > > >is more popular than several alternatives, >- which are essentially describing the same thing: a hazard

Re: [Tagging] Feature Proposal - RFC - Hazards (animals)

On Thu, Nov 26, 2020 at 2:25 AM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > >- Why hazard:animal and hazard:species is needed instead of animal and >species? > > I initially had it as just animal and species as you suggest. However, for hazards along a stretch of

Re: [Tagging] Feature Proposal - RFC - Hazards

I knew when I started this that it would be impossible to address every single possible hazard that may exist in the world. I tried to curate a list of the most popular hazards that people were actually actually tagging with the 28,000 existing usages of the hazard key, and that I felt I was able

Re: [Tagging] Feature Proposal - RFC - Hazards

I am not opposed to including unsigned hazards, if that's the consensus. I was trying to address anticipated concerns about tagging unverifiable things. For example, someone in a western country tagging a curve hazard on every instance of a bend in the road and not just the signed parts. On

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

Unless somebody has a crystal ball, it's at least plausible that these could be around for quite some time. If we're lucky and they go away quickly, it's easy enough to remove the tagging later. But, "indefinite duration" seems like a sufficient level of permanence for an OSM feature. On Wed,

[Tagging] Feature Proposal - RFC - Hazards

Comment is requested on the proposal "hazard", which describes hazardous or dangerous features. This tagging was first proposed in 2007, and I have adopted the proposal with permission from the original author. Thanks to the various folks that assisted in the development of this proposal prior

Re: [Tagging] coastline v. water

> there were some attempts to suggest universally mapping bays with polygons > rather than nodes previously: > > > https://lists.openstreetmap.org/pipermail/tagging/2014-October/thread.html#19775 > > which however never reached consensus because of the weighty arguments > against this idea and

Re: [Tagging] coastline v. water

e area of tidal channels (aka > tidal creeks) should be mapped with natural=coastline at their edges - see > https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map > and > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel > - most o

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

he bounding box of this object?" A consumer would need to traverse down through the hierarchy to compute the inner bounding boxes, which defeats the purpose of subdividing it in the first place. On Sun, Nov 22, 2020 at 1:44 PM Simon Poole wrote: > > Am 22.11.2020 um 17:35 sc

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

I agree. I removed such duplicate tagging from my area some time ago, and it has not affected anything. I even went so far as to draft a proposal to change that recommendation. https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members On Sun, Nov 22, 2020,

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

ichard Fairhurst > wrote: > >> [cross-posted to talk-us@ and tagging@, please choose your follow-ups >> wisely] >> >> Brian M. Sperlongano wrote: >> > It seems that we are increasingly doing things to simplify the >> > model because certain tooling can'

Re: [Tagging] surface=rock

We call them stone walls, but every so often a pedantist comes along and reminds us that they're actually stone fences. On Fri, Nov 20, 2020, 5:56 PM Paul Allen wrote: > On Fri, 20 Nov 2020 at 22:35, Graeme Fitzpatrick > wrote: > >> I was having similar thoughts just a couple of days ago,

Re: [Tagging] surface=rock

There is also an undocumented surface=stone, which I tend to thing is identical to bare_rock. Though I could see "rock" meaning a rougher surface than stone/bare_rock. On Fri, Nov 20, 2020, 5:22 PM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > > Nov 20, 2020, 23:14 by

Re: [Tagging] coastline v. water

This was fascinating reading. I do agree that we ought to have a definition for what gets tagged natural=coastline, and I think it's fine if that definition has some subjectivity. I would offer something as simple as: "The coastline should follow the mean high tide line. In some cases this

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

The classic case for a "source" tag is for imports. It's useful to know that something came from a TIGER import, or from some public database or wherever. I think source=* makes sense when the data is literally coming from some defined external place. On Tue, Nov 17, 2020 at 10:36 AM Dave F via

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

I don't map cycle routes, but the issue sounds similar to hiking routes and administrative boundaries. Long-distance hiking trails often traverse regular roads in between stretches of woods. So the trail's route relation is named "Such and Such long distance trail" or whatever, but the parts on

Re: [Tagging] Deprecate water=pond?

Is a water= tag even needed at all in these cases then? natural=water + name="Foobar Pond" seems to cover it. I'm not sure what specific added information is conveyed by "lake", "pond", or even "lake_pond". It's a natural body of water with a name. If we need tagging to indicate freshwater vs

Re: [Tagging] Deprecate water=pond?

ere it's not), "in most countries" (but not > everywhere) etc etc. > > I don't think most bodies of water can be tagged as pond or lake by any > common standard, in a way that all agree. Nor do I think that is a problem. > > Best, Peter Elderson > > > Op wo 11 nov.

Re: [Tagging] Deprecate water=pond?

On Wed, Nov 11, 2020 at 12:29 PM Peter Elderson wrote: > Everybody knows a difference, > If "everybody knows it", then let's define what that difference is and write it down. That is why this list exists. It is a bad idea to presume that different cultures and languages share a common

Re: [Tagging] Deprecate water=pond?

uot;what people call it" definition, then the distinction is purely redundant and worse may not translate appropriately into other languages which might have a different array of terms for such bodies of water. On Wed, Nov 11, 2020 at 8:30 AM Paul Allen wrote: > On Wed, 11 Nov 2

Re: [Tagging] Deprecate water=pond?

> > This doesn't seem like a good idea to me. The boundary between a lake and > a pond may be hard to measure sometimes, but that doesn't mean it is useful. > > In what way is this distinction useful? ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Deprecate water=pond?

Is it actually desirable to distinguish a "lake" from a "pond"? If so, what is the difference? Is it just that a body of water is named "XYZ Pond" versus "XYZ Lake"? If so, isn't water=pond versus water=lake derived from and redundant with name? Is there a conceivable scenario where a data

Re: [Tagging] Deprecate water=pond?

I normally use the name of the body of water, e.g. Foo Pond gets water=pond and Bar Lake gets water=lake. It's not clear to me that they have a distinction beyond customary naming, and in my area there are ponds bigger than lakes, though usually the lakes are larger. If there is no distinction

[Tagging] Feature Proposal - Voting - Special Economic Zone

The proposal for boundary=special_economic_zone is now open for voting. Thank you to those that have offered comments and feedback on this proposal. Community input has been incorporated into the current version of the proposal. Voting link:

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

I note that "visitation room" is a term that describes "A room designated in the funeral home for the deceased to lie before the funeral so that people can view the deceased." Conveniently, it carries no religious connotation. Some cursory searching indicates that this term is in use both in the

Re: [Tagging] Basic cartography features missing, why?

Welcome! If you do choose to go down the path of the proposal process, I would potentially be willing to assist in the proposal drafting. It is certainly a bunch of work to get a proposal through, but it's hard because it's worth doing. I have a proposal in process now and a few others

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

is too hard to describe, there is precedence in describing the service being provided. On Thu, Nov 5, 2020 at 8:43 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 5. Nov 2020, at 16:47, Brian M. Sperlongano > wrote: > > > > We use

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

That is clear and unambiguous terminology that is not religion-specific. I would support this. On Thu, Nov 5, 2020, 2:10 PM António Madeira via Tagging < tagging@openstreetmap.org> wrote: > In many modern places near cemeteries there's not a room, but several. > So, I would prefer

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

> > > amenity=deceased_viewing >> > > That almost works. But it's a verb not a noun, an activity not a place. > With additional words it could work, but it would be rather inelegantly > named. > We use amenity=ice_cream and not amenity=ice_cream_parlor, because "ice cream" is the amenity being

Re: [Tagging] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

Perhaps deceased_viewing then? If that's the actual amenity that we are describing? On Wed, Nov 4, 2020 at 6:20 PM Peter Elderson wrote: > place_of_mourning then? Just like place_of_worship? > > One could argue that this misses the point, because it's about viewing the > deceased and you can

Re: [Tagging] Update - RFC - Special Economic Zones

I appreciate the pointed questions offered here. See responses in-line: On Tue, Nov 3, 2020 at 4:37 AM Frederik Ramm wrote: > Hi, > > my opinion is that stuff that is not visible on the ground and not > meaningfully editable by mappers needs a very strong reason to be mapped > at all. > > 1.

Re: [Tagging] Update - RFC - Special Economic Zones

operation with Taiwan, and then you also have Qianhai > Special economic zone which is a service and industry themed zone within > the special economic zone of Shenzhen. > > Which of them should/shouldnt be tagged as special ecobomic zone? How to > differentiate between th

[Tagging] Update - RFC - Special Economic Zones

Folks: Last week I opened an RFC for the proposed new tag boundary=special_economic_zone. That announcement generated only minimal discussion, resulting in a minor change to the proposal to address the concern raised. I am sending this update to ensure that the community has adequate

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

nclude access to taxi dedicated infrastructure > too. This is quite legit and no beef with the companies wanting to be able > to model this to improve routing for their drivers and customers. > > Simon > Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano: > > In the United States

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

> > Actually I quite like "private_hire" as an access value. Are you suggesting access=private_hire as a tag? That would not be consistent with how taxi services are tagged. We don't use access=taxi, we use amenity=taxi + taxi=*. By that logic, the access tagging should use private_hire=*,

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

> Also private hire, which need to be booked in advance and have the same > access rights/restrictions on the public highway as a private car. For some > reason I cannot fathom, in London private hire are called minicabs. > > Uber and Lyft are legally private hire so whilst there may be a case for

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

In the United States at least, there is a very real difference in meaning between "rideshare" and "taxi" services when it comes *specifically* to access at airports. And I believe that is the intent of this proposal: how do I tag the special area in the airport where I must go in order to be

Re: [Tagging] Feature Proposal - RFC - Special Economic Zones

t 10:39 AM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 25. Oct 2020, at 15:24, Brian M. Sperlongano > wrote: > > > > The point is to provide a standard, non-cryptic, foundational tag for > such areas. Perhaps future proposals might further p

Re: [Tagging] Feature Proposal - RFC - Special Economic Zones

countries. On Sun, Oct 25, 2020 at 6:59 AM Martin Koppenhoefer wrote: > > > Am So., 25. Okt. 2020 um 05:34 Uhr schrieb Brian M. Sperlongano < > zelonew...@gmail.com>: > >> A special economic zone (SEZ) is an area in which the business and trade >> laws are different

[Tagging] Feature Proposal - RFC - Special Economic Zones

A special economic zone (SEZ) is an area in which the business and trade laws are different from the rest of the country. Only a small number of these areas are mapped so far, however, estimates put the total number of SEZ worldwide at between 2,700 and 10,000. The proposed tagging for these

Re: [Tagging] Should the tag proposal process force voters to vote for an option?

With the exception of the "plurality votes wins" aspect of this, it strikes me that this can largely be done today. Someone could post a wiki page with multiple alternatives and ask the community to vote/comment on different tagging schemes. Once a winner emerges, the author could then move that

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

On Tue, Sep 29, 2020 at 5:11 AM Warin <61sundow...@gmail.com> wrote: > We don't mapped parked vehicles unless they are 'permanent', same should > be adopted for fires, floods, earth quakes and volcanic eruptions. > > If there is no permanent effect then mapping it is at best a temporary > thing.

<    1   2