[Tagging] Quarry lakes

2020-12-24 Thread Brian M. Sperlongano
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] Definition of lake/pond as applied to stream/plunge pools

2020-12-24 Thread Brian M. Sperlongano
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

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

2020-12-23 Thread Brian M. Sperlongano
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

2020-12-23 Thread Brian M. Sperlongano
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

2020-12-21 Thread Brian M. Sperlongano
> 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] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

2020-12-21 Thread Brian M. Sperlongano
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

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

2020-12-21 Thread Brian M. Sperlongano
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] Fuzzy areas again: should we have them or not?

2020-12-21 Thread Brian M. Sperlongano
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

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

2020-12-20 Thread 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 > >

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

2020-12-20 Thread 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

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

2020-12-20 Thread 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

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

2020-12-20 Thread 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

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

2020-12-20 Thread 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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
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

2020-12-19 Thread Brian M. Sperlongano
> > 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] Proposed feature - RFC - Military Bases

2020-12-19 Thread Brian M. Sperlongano
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

2020-12-19 Thread Brian M. Sperlongano
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] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-19 Thread Brian M. Sperlongano
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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Brian M. Sperlongano
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] Tagging sewage treatment basins

2020-12-17 Thread Brian M. Sperlongano
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] Rapids (whitewater) on rivers

2020-12-17 Thread Brian M. Sperlongano
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

2020-12-17 Thread Brian M. Sperlongano
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 --> Hazards

2020-12-16 Thread Brian M. Sperlongano
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] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Brian M. Sperlongano
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

2020-12-16 Thread Brian M. Sperlongano
+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

2020-12-16 Thread Brian M. Sperlongano
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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
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

2020-12-16 Thread Brian M. Sperlongano
-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] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Brian M. Sperlongano
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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Brian M. Sperlongano
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

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

2020-12-14 Thread Brian M. Sperlongano
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] Feature proposal - RFC 2 - Pumping proposal

2020-12-14 Thread Brian M. Sperlongano
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
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] Feature proposal - RFC 2 - Pumping proposal

2020-12-13 Thread Brian M. Sperlongano
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] Is landuse=conservation actually deprecated?

2020-12-13 Thread Brian M. Sperlongano
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

2020-12-13 Thread Brian M. Sperlongano
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

2020-12-13 Thread Brian M. Sperlongano
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] Proposed feature - RFC - Military Bases

2020-12-12 Thread Brian M. Sperlongano
> 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

[Tagging] Feature Proposal - Voting - Hazards

2020-12-12 Thread Brian M. Sperlongano
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] How to put a name tag on an area with more than one type?

2020-12-11 Thread Brian M. Sperlongano
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] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
> > 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] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-10 Thread Brian M. Sperlongano
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] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
> > > 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] Proposed feature - RFC - Military Bases

2020-12-10 Thread Brian M. Sperlongano
> 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

2020-12-10 Thread Brian M. Sperlongano
"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

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

2020-12-09 Thread Brian M. Sperlongano
> > 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] RFC - Hazards - 2 Week Update & RFC Summary

2020-12-09 Thread Brian M. Sperlongano
> 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

2020-12-09 Thread Brian M. Sperlongano
> 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

2020-12-09 Thread Brian M. Sperlongano
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

2020-12-09 Thread Brian M. Sperlongano
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] Proposed feature - RFC - Military Bases

2020-12-07 Thread Brian M. Sperlongano
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] RFC - Hazards - Pedestrian hazard

2020-12-06 Thread Brian M. Sperlongano
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] RFC - Hazards - Pedestrian hazard

2020-12-06 Thread Brian M. Sperlongano
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

[Tagging] RFC - Hazards - Pedestrian hazard

2020-12-06 Thread Brian M. Sperlongano
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

2020-12-06 Thread Brian M. Sperlongano
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

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

2020-12-06 Thread Brian M. Sperlongano
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

2020-12-05 Thread Brian M. Sperlongano
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?)

2020-12-04 Thread Brian M. Sperlongano
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

2020-12-04 Thread Brian M. Sperlongano
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

2020-12-04 Thread Brian M. Sperlongano
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

2020-12-03 Thread Brian M. Sperlongano
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

2020-12-03 Thread Brian M. Sperlongano
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?)

2020-12-03 Thread Brian M. Sperlongano
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

2020-12-03 Thread Brian M. Sperlongano
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

2020-12-02 Thread Brian M. Sperlongano
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

2020-12-01 Thread Brian M. Sperlongano
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

2020-11-30 Thread Brian M. Sperlongano
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)

2020-11-27 Thread Brian M. Sperlongano
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

2020-11-27 Thread Brian M. Sperlongano
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

2020-11-27 Thread Brian M. Sperlongano
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

2020-11-26 Thread Brian M. Sperlongano
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)

2020-11-26 Thread Brian M. Sperlongano
: > 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

2020-11-26 Thread Brian M. Sperlongano
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)

2020-11-26 Thread Brian M. Sperlongano
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

2020-11-26 Thread Brian M. Sperlongano
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)

2020-11-26 Thread Brian M. Sperlongano
> > >- 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)

2020-11-26 Thread Brian M. Sperlongano
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

2020-11-26 Thread Brian M. Sperlongano
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

2020-11-26 Thread Brian M. Sperlongano
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

2020-11-25 Thread Brian M. Sperlongano
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

2020-11-25 Thread Brian M. Sperlongano
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

2020-11-24 Thread Brian M. Sperlongano
> 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

2020-11-23 Thread Brian M. Sperlongano
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

2020-11-22 Thread Brian M. Sperlongano
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

2020-11-22 Thread Brian M. Sperlongano
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

2020-11-22 Thread Brian M. Sperlongano
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

2020-11-20 Thread Brian M. Sperlongano
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

2020-11-20 Thread Brian M. Sperlongano
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

2020-11-18 Thread Brian M. Sperlongano
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

2020-11-17 Thread Brian M. Sperlongano
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

2020-11-16 Thread Brian M. Sperlongano
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?

2020-11-12 Thread Brian M. Sperlongano
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?

2020-11-11 Thread Brian M. Sperlongano
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?

2020-11-11 Thread Brian M. Sperlongano
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?

2020-11-11 Thread Brian M. Sperlongano
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?

2020-11-11 Thread Brian M. Sperlongano
> > 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?

2020-11-11 Thread Brian M. Sperlongano
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?

2020-11-09 Thread Brian M. Sperlongano
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

2020-11-09 Thread Brian M. Sperlongano
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:

  1   2   >