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.

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

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

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

[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] 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,

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

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-centric v

[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

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] RFC - Hazards - Pedestrian hazard

at=53.50421582735714=14.477556379223921=17=photo=aaBuvm_A9utc1PYDRyGyXw=0.5085941428184124=0.5962547075134255=0 On Sun, Dec 6, 2020 at 6:45 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 7. Dec 2020, at 00:17, Brian M. Sperlongano > wrote: > > > > The

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

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

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

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

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

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

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

[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

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

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

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

[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 (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] 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] 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] 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] 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] 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,

Re: [Tagging] Tagging sewage treatment basins

I knew them as sewage treatment ponds, but apparently there's a name for them: https://en.m.wikipedia.org/wiki/Waste_stabilization_pond I feel like this a separate class of object that deserves its own tag, either within or separate from natural=water, or perhaps even subclassed as

Re: [Tagging] Rapids (whitewater) on rivers

hazard=yes is neither banned nor discouraged. It was simply not included in the list of proposed approved tags due to objections raised during the RFC. The goal was to approve the hazard tagging that everyone agreed on. Since hazard=yes has some existing tagging (>600 uses), it would still be

Re: [Tagging] Tagging sewage treatment basins

With respect to basins, my understanding is that some of these have water in them all of the time, some of them have water some of the time, and then there are some that are almost always dry, but become wet only rarely when they are needed (e.g. for stormwater handling) Mappers have used BOTH

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

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

[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

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 >

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

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

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] The saga of landuse=reservoir vs water=reservoir

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šė: >

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

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

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

I could see value in tagging them separately. I.e. "I'd like to swim in a small pool with a waterfall". On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey wrote: > > > On Thu, 24 Dec 2020 at 10:26, Paul Allen wrote: > >> >> Isn't that a plunge pool? https://en.wikipedia.org/wiki/Plunge_pool >> I

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

ically measure natural=water size where the way contains a waterfall > node. > > On Thu, 24 Dec 2020, 4:14 pm Brian M. Sperlongano, > wrote: > >> I could see value in tagging them separately. I.e. "I'd like to swim in >> a small pool with a waterfall". >>

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

On Thu, Dec 24, 2020 at 9:00 AM Paul Allen All of which has drifted somewhat off topic, but until we have a > reasonable understanding of how different legislations handle > things we don't have a good model of how we ought to go > about mapping them (or even if we should map them). > I'm not

[Tagging] Quarry lakes

A commenter on the reservoir proposal[1] pointed out the existence of quarry lakes[2], which is a lake that is formed after a quarry has been dug after a mining operation. It was suggested that such bodies of water should be tagged separately from other lakes with a tag such as water=quarry.

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

I understand pitch to mean "a playing field" (as "pitch" is not often used in US English -- we would say "soccer field" for example.). I don't know if a shooting range is a pitch or not, but it definitely isn't a playing field. On Sat, Dec 19, 2020 at 3:35 PM Paul Allen wrote: > On Sat, 19 Dec

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

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

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

Historic or abandoned military features, or military ruins, are clearly not what this proposal is describing. On Sat, Dec 19, 2020 at 5:44 PM Graeme Fitzpatrick wrote: > On Sun, 20 Dec 2020 at 02:00, St Niklaas wrote: > >> >> Your text or proposal seems to be focused on modern times. >> > >

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

These guys in Texas will let you drive their tank around and shoot things, for a price: https://www.oxhuntingranch.com/activities/hunting-shooting/machine-gun-shooting/ On Sat, Dec 19, 2020 at 6:16 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 19. Dec 2020, at 23:59, Jeremy

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

Perhaps simply leisure=range, as this would be generic to any type of facility where one might fire projectiles or ordnance. You could then extend that with something like range= to specify what is being fired, and/or the existing sport= key if it's considered a shooting sport. On Sat, Dec 19,

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

> > is firing ordnance a leisure activity somewhere? Or a sport? Hello, let me introduce to you the United States of America. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

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

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

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

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

[Tagging] Definition of lake/pond as applied to stream/plunge pools

Discussion on the current reservoir proposal[1] (which seeks to define the distinction between reservoirs, lakes, and ponds) has brought up the question of stream/plunge pools[2,3], and how they fit into the lake/pond definitions. I've come up with the following text: "Occasionally a river or

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

Tomas, Since you are not willing to accept (1) an existing approved proposal, (2) new proposal to correct flaws in the first one, or (3) the overwhelming preference of the mapping community over the past four years[1], then I'm sorry but we must curtly dismiss your arguments as a one-man

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

The statistics reflect all areas, regardless of which editors were used to create them. I stand by them, as numbers do not lie. There was a 3:1 preference for water=reservoir during 2017 and 2018, two years prior to the change in iD preset. The data is open, and taginfo provides a very helpful

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

Wouldn't it be more consistent to keep it in the same key, and call it place=lake_group? Or even place=lakes? Would this be used for something like the Great Lakes in USA/Canada or is that too large of a feature? On Tue, Dec 15, 2020, 12:05 PM stevea wrote: > +1. Joseph's suggestion is a

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

-12-16, tr, 01:32 Brian M. Sperlongano rašė: > > The iD editor preset appears to use water=reservoir while the JOSM > > preset appears to use landuse=reservoir. > > Not entirely correct. > * JOSM gives freedom to mappers and supports BOTH. > * iD forces to use water=re

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

As the maintainer of the current hazard proposal - I don't really have strong opinions about signed versus unsigned hazards, though I know others do. However, signed hazards seem to be something that we all agree should be tagged, and this proposal is attempting to approve the collection of

Re: [Tagging] Rapids (whitewater) on rivers

+1 IMHO these are complementary. waterway=rapids can be tagged from overhead imagery, and the additional detail of the rapids can be added later by people with subject matter expertise. I see this as equivalent to sac_scale=* for hiking trails - it does not replace the underlying highway=path,

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

Thanks everyone for the discussion. I believe there are two germane points being raised by Tomas that warrant our consideration: 1. It is not clear from the original 2011 vote which created water=reservoir (and other values) as to whether the community intended to deprecate landuse=reservoir or

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

alifornia%20highway%201%20curves%20for%20next%2074%20miles=firefox-b-d=2ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu> > > > > > On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano > wrote: > >> As the maintainer of the current hazard proposal - I don't really have >> stron

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

Would this work for addressing schemes that use a hyphenated prefix? In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix in addresses to determine which sector of the island an address is located. So an address might be something like "99-123 Kamehameha Highway". Would

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

> I think you need to expand a little on how to "conflate" a pool with a > river. The > disadvantage of doing so is that the pool then cannot have a name assigned. > Sorry, my words were not clear enough here. By "conflate" I mean that the pool would simply be part of the river polygon. See

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm wrote: > Our current data model is not suitable for mapping fuzzy areas. We can > only do "precise". Also, as you correctly pointed out, or basic tenet of > verifiability doesn't work well with fuzzy data. > The current data model works just fine

[Tagging] Changes to clarify the Hazards proposal during the vote

Hello, I recently received late feedback on the hazards proposal. Based on the feedback, I felt it was necessary to make small changes to this proposal. I believe these changes are sufficiently minor that they do not invalidate the voting which has occurred so far. Since this proposal has begun

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

I agree with Mateusz that the wiki IS the project's standard document for the meaning of tagging (from the perspective of data consumers) and how to tag (from the perspective of mappers). Note that both perspectives are important. But to address the specific point, there is no standard document

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

On Mon, Dec 14, 2020 at 5:11 PM François Lacombe wrote: > Hi Brian, > > Thank you for your comments > > Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano > a écrit : > >> 1. The proposal states "It is proposed to discourage the use of >> undocumente

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

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

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

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

> 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

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

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

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

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?

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

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?

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?

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?

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

  1   2   >