Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

> yes, but motorway is an exception because it is usually defined by signs > rather than characteristics (e.g. if the signs are missing but it looks and > feels like, we use motorroad=yes in some countries) Iknow you said 'usually' but this sounds like a very European perspective to me. We have

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

On Thu, Jun 22, 2023, 8:08 AM Illia Marchenko wrote: > But "freeway" is de facto equivalent of motorway, right? > Freeway is a colloquial term that's only used in some parts of the country and only signed as such in some states and often inconsistently. I assure you that the on the ground situat

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

un 22, 2023, 8:28 AM Greg Troxel wrote: > "Brian M. Sperlongano" writes: > > > On Thu, Jun 22, 2023, 8:08 AM Illia Marchenko < > illiamarchenk...@gmail.com> > > wrote: > > > >> But "freeway" is de facto equivalent of motorway, righ

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

I don't see the current usage to be a problem. On Sun, Jul 2, 2023, 2:19 PM Asa Hundert wrote: > I want this amenable to consumers. If I were to propose an attribute > to the other tag, I'd have to propose to deprecate the uses on areas > that allows for such atrocities as "amenity=lounger; surf

[Tagging] [RFC] Feature Proposal - Intentionally omitted name tags

Hello, Comment is requested on a proposal to introduce two tags to indicate the reason why a name=* tag has been omitted from a feature: https://wiki.openstreetmap.org/wiki/Proposal:Omitted_name_tag Please provide feedback here, on the wiki talk page, or on the Community Forum thread that I have

Re: [Tagging] [RFC] Feature Proposal - Intentionally omitted name tags

On Sun, Jul 30, 2023 at 12:08 PM Marc_marc wrote: > did we need to have this thread again and again ? > [...] Regards, > Marc > What do you believe should go into the name tag of the bodies of water known in French as océan Atlantique or the body of water known as Itämeri in Finnish? __

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

This isn't really appropriate data for OSM, sorry. On Sun, Aug 6, 2023, 3:21 PM NickKatchur via Tagging < tagging@openstreetmap.org> wrote: > Hello, > > > I have developed a proposal to indicate the availability of cell phone > service at nodes and areas, > https://wiki.openstreetmap.org/wiki/Pro

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

No, this does not fix it. The fundamental thing that you're trying to map here simply doesn't belong in OSM, the proposal will not pass, and I would advise you to stop wasting your time and everyone else's on it. OpenStreetMap is a database of verifiable facts, not scientific measurements, and th

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

On Thu, Aug 10, 2023, 6:28 AM Marc_marc wrote: > with this argument, you'd have to remove all the shop= office=* craft=*, > Nonsense. Everyone knows what a craft=brewery is. It's not volatile at all. They either make beer or they don't. Cell reception is ephemeral. > let's also remove maxs

Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch. So I'm really not even sure why we're discussing it beyond the fact that we're all nerds about this s

Re: [Tagging] Highway classification in Antarctica

I'm sure the answer to this question... CRITICAL ... to many data consumers... Anyways: This: https://www.openstreetmap.org/way/1159748452 seems fine, if you can convince me that it's actually a road. Clearly the most significant road in the area... It's essentially the only road *grin* between

Re: [Tagging] Highway classification in Antarctica

On Thu, Apr 25, 2024 at 10:13 AM Christoph Hormann wrote: > [...] you can try to record semantically meaningful information about the > geographic reality. > > [...] Even more clear in that regard is the use of secondary tags like > snowmobile=yes, ice_road=yes, surface=ice. I don't think anyon

Re: [Tagging] Highway classification in Antarctica

On Sat, Apr 27, 2024 at 9:01 PM Fernando Trebien wrote: > "a road of highest importance, forming the main road network there, > should be highway=trunk" [1] > "highway=trunk: The most important roads in a country's system that > aren't motorways." [2] > > The comments here suggest that for a rura

Re: [Tagging] [RFC] Feature Proposal - Deprecate crossing=zebra in favor of crossing:markings

> > Usage of crossing=zebra peaked in 2019 and has been pretty much flat > since then. The crossing:markings tag first appeared in 2023 and has > grown rapidly; at the current pace, the specific combination of > "crossing=uncontrolled, crossing:markings=zebra" is probably going to > have double th

Re: [Tagging] Tar sands tagging

If there is in fact a tailings pond there (and not something else mis-tagged as one), there is a tag man_made=tailings_pond specifically for that which was the subject of a 2021 proposal. https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtailings_pond https://wiki.openstreetmap.org/wiki/Proposal:

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

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

[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 area

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

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

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

> > 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=*, and

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

and similar, this might include 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: > &

[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 opportunity

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

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. Ar

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 mo

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 of

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 amenity=place_

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] 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 (hopefull

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

[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: https://wiki.openstreetmap.org/wiki/Proposed_features/

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 be

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 cons

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 ht

Re: [Tagging] Deprecate water=pond?

If we are going with a "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

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 underst

Re: [Tagging] Deprecate water=pond?

ally"(except where 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 Elderso

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 br

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 t

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

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 diete

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

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

2, 2020 at 5:29 AM Richard 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

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, 11:3

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

ot;what is the 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.2

Re: [Tagging] coastline v. water

ay - all of which are mapped as outside of the > natural=coastline. > > > > > > Also please consider that the community here approved the proposal for > waterway=tidal_channel which said that the area of tidal channels (aka > tidal creeks) should be mapped with natural=c

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 beca

[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 to

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

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

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 (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 r

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 th

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 t

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 which ar

[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 prote

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

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 wrote

Re: [Tagging] Feature Proposal - RFC - Hazards

316_8_54.png > > low airplanes and helicopters: > https://www.retsinformation.dk/image.aspx?id=196668&img=CX316_8_82.png > https://www.retsinformation.dk/image.aspx?id=196668&img=CX316_8_83.png > > Queue risk: > https://www.retsinformation.dk/image.aspx?id=196668&img=CX316_8_44.png > &g

Re: [Tagging] Feature Proposal - RFC - Hazards

sting usages 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 permane

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

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 at

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 man

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 the pu

[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 hazard:

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

permanently mounted, 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 appl

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 "f

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] https://commons.wikimedia.org/wiki/File:Landslide_ar

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] Feature Proposal - RFC - Hazards

ave high existing usage plus values 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 golf

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

what constitutes 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

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 hig

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 spac

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

Yes, and while we're at it, let's throw in multinational bases as well: https://en.wikipedia.org/wiki/NATO_Air_Base_Geilenkirchen On Sun, Dec 6, 2020 at 11:17 AM Paul Allen wrote: > On Sun, 6 Dec 2020 at 16:01, Brian M. Sperlongano > wrote: > >> This is probably a US

[Tagging] RFC - Hazards - Pedestrian hazard

The hazard proposal [1] currently proposes hazard=cyclists as a way to tag a signed area in which motorists should watch for or share the road with cyclists. Note that this is explicitly different from a cyclist crossing, which is currently covered by highway=crossing. It was suggested by a comme

Re: [Tagging] RFC - Hazards - Pedestrian hazard

The largest existing use of hazard=cyclists is in Germany. There is no Google StreetView in Germany, but from the small number examples [1] I looked at, it seems like this tag is being used for "cyclists in the road" hazards and not "cyclist crossings". There were only 10 usages of the tag (out o

Re: [Tagging] RFC - Hazards - Pedestrian hazard

mIDPxhg [2] https://www.mapillary.com/app/?lat=53.50421582735714&lng=14.477556379223921&z=17&focus=photo&pKey=aaBuvm_A9utc1PYDRyGyXw&x=0.5085941428184124&y=0.5962547075134255&zoom=0 On Sun, Dec 6, 2020 at 6:45 PM Martin Koppenhoefer wrote: > > > sent from a phone > >

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

I fixed that for you, it should just be status=proposed, and the template does the rest of the magic! On Mon, Dec 7, 2020 at 7:26 PM Graeme Fitzpatrick wrote: > > > > On Tue, 8 Dec 2020 at 10:19, Graeme Fitzpatrick > wrote: > >> >> I have just posted a new proposal re Military Bases: >> https:/

[Tagging] RFC - Hazards - 2 Week Update & RFC Summary

Thanks to all who have spilled much ink and provided extensive comment on this proposal[1] -- the feedback is deeply appreciated as it increases confidence that the proposal reflects community consensus. The hazard tag has attracted an additional 2,000 usages just over the course of this RFC, and

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

ns_(44651781425).jpg [2] https://commons.wikimedia.org/wiki/File:NYS_NYW4-14.svg On Wed, Dec 9, 2020 at 8:37 AM Paul Allen wrote: > On Wed, 9 Dec 2020 at 13:13, Brian M. Sperlongano > wrote: > > Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall >> > > Kev

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

> I'd suggest fallen_rock and low_flying_aircraft as tag values based upon > the common case but have the proposal mention their secondary application. > I actually have low_flying_aircraft in the proposal as a value, though I just discovered that there is a more common value in use, "air_traffic"

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

> Here are the ones that I think are worth considering: > >- Opening or swing bridge ahead > > This is already covered by the approved tag bridge:movable and its various sub-keys that describe different types of movable bridges. There were no existing usages I could find under the hazard key,

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

> > We have examples in the UK, even on major roads like the A346 between > Marlborough and Swindon. I don't think they are tagged. > with sophisticated routers issuing an alarm on approach might be > something in the future. These dips are clearly signed. > You've just convinced me that this I

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

"Service" is the right term for what is being described (e.g. army, navy, air force, etc), and is consistent with UK terminology[1]. However, it also assumes that every country's military forces are neatly grouped into these categories. The Chinese military is particularly complex - the Chinese n

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

> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army >> use "military service" >> > sometimes too, and mention the overall "British Armed Services", "Her >> Majesty's Naval Service", etc. >> > > The same goes for the dialect spoken by that page's author. > > However, whilst onl

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

> > > Services often cross functions; for example, the US Army operates air >> fields[2]. Tagging this military_service=army would be accurate, but would >> not convey that this is an air force base, but not an Air Force base. >> >> To get around all of this, we should tag military bases with thei

Re: [Tagging] RFC - Hazards - 2 Week Update & RFC Summary

In general I have avoided proposing values for these "warning of something ahead" signs that are at a non-trivial distance from the hazard, as I think that is a controversial usage, deserving of a separate discussion and/or proposal. Since there is already a tag for cattle grids and there is no us

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

> > Ground/land, air/aviation & maritime/naval all seem pretty well > interchangeable, space is ready for the future & we should also include > amphibious & probably Staff / Command / Headquarters for somewhere like > this place: https://www.openstreetmap.org/relation/89605! Currently > office=mili

Re: [Tagging] How to put a name tag on an area with more than one type?

Hello Anders, I would recommend creating a multipolygon relation (type=multipolygon) with each of the wetland pieces, and set the name= and appropriate natural= and wetland= tags on the relation. On Fri, Dec 11, 2020, 11:11 AM Anders Torger wrote: > Hello, > > I was on this list a while back ex

[Tagging] Feature Proposal - Voting - Hazards

Hello, Voting is now open for a two-week period on the proposal "Hazards". I wish to express my sincere appreciation to the many of you that provided valuable input during the development of this proposal. Voting link: https://wiki.openstreetmap.org/wiki/Proposed_features/hazard#Voting _

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

> Break - I've just found that there actually are a handful of > club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use, > although all are undocumented, so they will be fine. Are we all in > agreement though, that there should be no reference to "military" against > Cadet groups (e

[Tagging] The saga of landuse=reservoir vs water=reservoir

This story is offered because I find it interesting, and as a possible catalyst for updates to our tagging documentation. I offer apologies to those that are well aware of this controversy. There are two competing ways to tag reservoirs: landuse=reservoir, or natural=water + water=reservoir. The

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

e for the same reason - working together to create the best possible map for the world. [1] https://josm.openstreetmap.de/ticket/17874 [2] https://github.com/openstreetmap/iD/issues/6589 On Sun, Dec 13, 2020 at 10:39 AM Tomas Straupis wrote: > 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:

Re: [Tagging] Is landuse=conservation actually deprecated?

I will note that the Massachusetts, USA mapping community does believe that there is a distinction between the two tags, as noted here: https://wiki.openstreetmap.org/wiki/Massachusetts/Conservation However, this usage and definition seems to be specific to that particular community and is not a

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

François, thank you for your hard work on this proposal! I will most likely support this version. I have a few questions: 1. The proposal states "It is proposed to discourage the use of undocumented pump:type=* to state pump mechanisms in favour of new pump_mechanism=*." It is not clear what is

Re: [Tagging] How to put a name tag on an area with more than one type?

It sounds like what we are asking for is the ability to tag a rough polygon in the approximate area where a label should be placed for a known but not strictly bounded toponymic feature (mountain range, water body, etc). That would give a hint to renderers as to the location and most importantly,

  1   2   >