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

2020-12-23 Thread Andrew Harvey
I'm giving away all my favourite spots here but both of these the stream is
mapped a a way, and has the pool under the waterfall mapped as an area, so
you can determine pools under a waterfall based on the natural=water area
with one of the nodes being a waterway=waterfall node.

https://www.openstreetmap.org/way/531128566
https://www.openstreetmap.org/way/32173325

If we want a separate tag for this that's fine, but currently people use
the water=stream_pool in OSM to tag these.

On Thu, 24 Dec 2020 at 16:31, Brian M. Sperlongano 
wrote:

> That doesn't work if the river/stream is modeled as a way only.  Also, it
> assumes that every waterfall has a plunge pool - I'm not sure that's the
> case.
>
> On Thu, Dec 24, 2020, 12:25 AM Andrew Harvey 
> wrote:
>
>> Mind you, you do need any of these tags to determine that. You can
>> automatically 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".
>>>
>>> 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 didn't even know plunge pools where a thing until Kevin Kenny
>>>>> mentioned them.  He knows everything.
>>>>>
>>>>
>>>> Probably, but per wikipedia (again I'm no expert on this) "Plunge
>>>> pools, or plunge basins, are stream pools formed by the action of
>>>> waterfalls", so plunge pools are just a specific type of stream pool, When
>>>> I originally documented stream_pool on the wiki after the mailing list
>>>> discussion the intent was that plunge pools would be tagged as
>>>> water=stream_pool.
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-23 Thread Andrew Harvey
Mind you, you do need any of these tags to determine that. You can
automatically 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".
>
> 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 didn't even know plunge pools where a thing until Kevin Kenny
>>> mentioned them.  He knows everything.
>>>
>>
>> Probably, but per wikipedia (again I'm no expert on this) "Plunge pools,
>> or plunge basins, are stream pools formed by the action of waterfalls", so
>> plunge pools are just a specific type of stream pool, When I originally
>> documented stream_pool on the wiki after the mailing list discussion the
>> intent was that plunge pools would be tagged as water=stream_pool.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-22 Thread Andrew Harvey
On Wed, 23 Dec 2020 at 00:50, Brian M. Sperlongano 
wrote:

> Great discussion, here and in the 2017 thread.  Participation in the
> tagging list is certainly educational.
>
> water=stream_pool suffers from a few problems, and its use seems far from
> a settled question.  (None of this is meant as criticism, as I understand
> all too well the hard work involved in developing proposals and good wiki
> documentation).
>
> In the three years since that discussion, water=stream_pool has achieved
> just 425 usages.  I assume that the biggest reason for this is that it's
> only documented as an entry in the table for the wiki page for Key=water.
> Notably absent is any mention of stream pools (or for that matter, plunge
> pools) from either of the two main wiki pages for river documentation
> (water=river vs waterway=riverbank).  This begs the question of how
> water=stream_pool should interlace with river polygons for mapping.
>

All the ones I've encountered the stream/river was only ever mapped as a
linear way, so it's just a linear way for the stream and then an area way
for the stream pool.


> Stream/plunge pools are part of a river or stream (I assert this based on
> Wikipedia's definition).  Logically, one might think "chop up the river
> polygon, and tag the stream pool portion as a stream pool".  This approach
> has a few problems:
>
> 1. If the river area is tagged with the water=river scheme, the area of
> the stream pool is no longer tagged as a river (because water=stream_pool
> conflicts with water=river).  This is wrong because the stream/plunge pool
> is indeed part of the river.  You could use the waterway=riverbank scheme,
> but now you're blending the two types of river tagging.  Yuck.
> 2. If the stream pool has a name, that portion of the river loses the name
> of the river, as the polygon can only have one name= tag.  The
> waterway=river way of course would still carry the name, so you do still
> maintain continuity.  But you lose concepts like "the total surface area of
> the river".
>
> Alternately, you could overlap the pool area over the river polygon, but
> then you're double-tagging the water area which seems like poor practice,
> and certainly JOSM would give you a warning for overlapping water features.
>
> It seems to me that river=stream_pool would have been the more sensible
> tagging within the natural=water+water=river scheme, as it further
> describes that portion of the river.
>

So for creeks would you also use river=stream_pool or have also
stream=stream_pool? I guess that's fine too. I see your point, it's just
I'd never really considered mapping streams/rivers with stream pools as
anything other than a linear way.


> The low usage and structural problems associated with stream pool tagging
> suggest that this is not a ready-for-prime-time tagging scheme, and
> deserves a proposal - not just a mailing list discussion - to sort out
> fundamentally unanswered questions about how to tag a river with both named
> and unnamed stream pools, particularly with regard to how the polygons are
> divided and/or overlapped.
>

I don't think changing the tagging would really change the usage, but if
you think there are structural issues with the tag then I'd be happy to try
and comment on a proposal.


> One might also argue that a stream pool should simply be mapped as a node,
> and if it's too big for a node, then perhaps it's more properly tagged as a
> pond or lake.  Unanswered questions.
>

Sorry I disagree with that, because water=pond per the wiki is usually man
made, and they are too small to be a lake and probably formed differently.


> Stream and plunge pools are a part of rivers (per WP definition), and I
> don't intend to address river tagging as part of the reservoir/lake/pond
> proposal[1].  Therefore, what makes the most sense is to simply scrub
> mention of pools and rivers from the proposal and leave it squarely focused
> on reservoirs, lakes, and ponds.
>

Yeah that sounds good, a separate proposal could cover that.

>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
>
>
>
> On Tue, Dec 22, 2020 at 12:49 AM Andrew Harvey 
> wrote:
>
>> Back in 2017 this was discussed on the list
>> https://lists.openstreetmap.org/pipermail/tagging/2017-March/031595.html and
>> the outcome of that was I added water=stream_pool to the wiki at
>> https://wiki.openstreetmap.org/wiki/Key:water#Natural_features. Is there
>> any reason to change this now? I think continuing to tag these as
>> natural=water + water=stream_pool is best as currently documented and in
>> use.
>>
>> On Tue, 22 Dec 2020 at 05:13, Brian M. Sperlongano 
>> wrote:
>>
>>> Discussion on the current re

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

2020-12-22 Thread Andrew Harvey
On Tue, 22 Dec 2020 at 22:34, Martin Koppenhoefer 
wrote:

> > On 22. Dec 2020, at 06:49, Andrew Harvey 
> wrote:
> > water=stream_pool
>
> isn’t this an oxymoron?
>

How so? It's a body of water so therefore water=*. It's usually a pool of
water along a stream, so the name stream_pool. Usually here they are just
named as "X Pool" but stream pool seems to be the general name based on
wikipedia usage.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-22 Thread Andrew Harvey
On Tue, 22 Dec 2020 at 19:15, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 22, 2020, 00:42 by graemefi...@gmail.com:
>
>
>
> On Mon, 21 Dec 2020 at 23:24, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> Dec 20, 2020, 23:29 by graemefi...@gmail.com:
>
> On Sun, 20 Dec 2020 at 17:55, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>
> How objects tagged now with amenity=lifeboat_station should be tagged
> after this proposal passes?
>
>
> They were a late addition after somebody pointed out that they exist. They
> would be replaced by emergency=marine_rescue, which has already been
> defined as groups " dedicated to the rescue of vessels &/or sailors at sea"
>
> The problem is that some water rescue stations are not marine but inland.
>
>
> Yes, not many but some, which is why I have changed the marine rescue
> definition to include "or inland waters".
>
> marine rescue defined to not be limited to marine is quite ugly
>
> Is term "water rescue" clear and acceptable? (not a native speaker)
>

I think it's fine to use marine here, even though it may not strictly be at
sea and could be related to inland waters. So long as this is clearly
stated in the wiki documentation. It's not always possible to have OSM tags
match how the term is commonly used.

Water rescue could be confused with the lifeguard tags which are for
rescuing swimmers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

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

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

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

>
>
>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
> wrote:
>
>> https://wiki.openstreetmap.org/wiki/Rescue_Stations
>>
>
> Moved to voting.
>
> If you still have any comments or concerns, please raise them for
> discussion, rather than just voting "No, because ..."!
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-15 Thread Andrew Harvey
Looks good to me.

Personally I'd usually try to add the operator and operator:wikidata tags
in combination to give more context.

On Wed, 16 Dec 2020 at 13:47, Graeme Fitzpatrick 
wrote:

>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
> wrote:
>
>> Please visit https://wiki.openstreetmap.org/wiki/Rescue_Stations & have
>> a look.
>>
>
> Reminder that voting is close to opening on this proposal.
>
> *Precis:*
>
> Amend the heading emergency=other_stations to emergency=rescue_stations /
> rescue_services (still in two minds about this one?)
>
> Under that heading, introduce new, or define existing, tags for various
> rescue services:
>
> emergency =
> disaster_response
> 
>
> emergency =
> marine_rescue
> 
>
> emergency =mine_rescue
> 
>
> emergency =
> mountain_rescue
> 
>
> Deprecate:
>
>- emergency =
>ses_station
>
>- emergency_service
>
> 
>=technical
>
>- amenity =
>rescue_station
>
>
>
> So far, there have been very few comments, so if there is anything you'd
> like to bring up about the idea, please do so, either here or on the talk
> page.
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Defining amenity=coast_guard

2020-11-30 Thread Andrew Harvey
On Tue, 1 Dec 2020 at 09:23, Graeme Fitzpatrick 
wrote:

> On Mon, 30 Nov 2020 at 23:29, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I run into https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoast_guard
>> and despite that I have basically zero experience with such objects
>> I am pretty sure that this description (and an old proposal) has a
>> problematic definition
>>
>
> Yep.
>
> Of a lot of interest to me, because I'm a member of a volunteer Marine
> Rescue ("Coast Guard") unit.
>
> I remember this being discussed previously with the same dilemma - Coast
> Guard means different things in different places, from an armed military
> force (that also has a rescue function) to a strictly volunteer Marine
> Rescue unit, with no official powers of any sort.
>
> Maybe the existing amenity=coast_guard & emergency =coast_guard tags both
> need to be deprecated in favour of two new tags:
>
> landuse=military + military=coast_guard: Base for a military /
> para-military force intended for protection of a country's coastal waters
> against enemy military forces, smugglers, terrorists etc, & which usually
> also has a marine rescue function. eg United States Coast Guard, Australian
> Border Force (& others). This would render as the standard military area; &
>
> emergency=marine_rescue: Base for a group, frequently non-Government /
> volunteer only, dedicated to the rescue of vessels / sailors at sea. eg
> British RNLI, Australian Volunteer Coast Guard, Volunteer Marine Rescue (&
> others). A good render would be a simple "SOS"! Alternatively, these could
> be mapped under the existing amenity=rescue_station tag, but that tag
> itself should come under the emergency= heading.
>
> There's currently about 150 x amenity=coast_guard, & only ~25 x
> emergency=coast_guard, tags in use, so not a major problem to go through &
> correct them. There are a *lot* more rescue bases that should be tagged
> though, in the order of 300 in Australia alone!
>

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


Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

2020-11-21 Thread Andrew Harvey
Boardwalk isn't really a good surface value as boardwalks can be made up of
a variety of materials not only wood.

We do have bridge=boardwalk but that always feels award when
the boardwalk is only elevating 10cm off the ground.

On Sun, 22 Nov 2020 at 10:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Is there some value in surface=boardwalk tag?
>
> It seems to be a duplicate of surface=wood.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] lanes - is "parking allowed" a parking lane?

2020-11-19 Thread Andrew Harvey
The way I understood the tagging guidelines was that if there was nobody
parked there, could you drive along the lane as usual. If you can't then I
wouldn't include it as lanes=* and only tag it as parking:lane. If you can
drive along it when vacant, but you can still legally park there then I'd
include it as lanes=* and also tag parking:lane.

It's common that during peak hour the lane is used by traffic, but off-peak
it's available for parking.

On Fri, 20 Nov 2020 at 01:22, Tobias Zwick  wrote:

> Hello all
>
> First of all, in the past, we have explored many edge cases for the
> lanes-tag in various discussions and I am happy that for the most part,
> it seems to be quite well defined by now. However, there is one edge
> case which is not uncommon at all but still unclear or awkward to tag.
> Look at this:
>
> https://westnordost.de/misc/2or1lanes.jpg
>
> It is a residential road marked clearly for 2 lanes, so it seems obvious
> to tag it with lanes=2. But on the other hand, you'll notice that there
> are parking cars on the right side that effectively render the right
> lane unusable. These parking cars would (currently) be tagged I believe as
>
> parking:lane:right=parallel
> parking:lane:right:parallel=on_street
>
> And the wiki states
>
>  > And the following lanes should be excluded:
>  > [...] Parking lanes [...]
>
> So here is an ambiguity in the documentation. On the one hand, if the
> road has marked lanes, the number of marked lanes should be tagged, on
> the other hand, there are these kind of "parking lanes" which do not
> have their own space marked as a parking lane but simply absorb the
> space assigned to normal car traffic. In OSM tagging, these are also
> "parking:lane"s as far as I know.
>
> We need to dissolve this ambiguity by defining a way how to distinguish
> between these two cases:
>
> https://westnordost.de/misc/parallel_parking_lane.png
> (1) a dedicated parallel parking lane. This lane should not count as a
> lane in the lanes-tag.
> (2) (parallel) parking is allowed (and used). This should be irrelevant
> for the lane count.
>
> My suggestion would be
> (1) parking:lane:*:parallel = lane
> (2) parking:lane:*:parallel = on_street
>
> Maybe especially those who recently involved themselves with parking
> lane tagging out and about and its documentation could also state their
> point of view here. According to the wiki edit history, looks like at
> least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.
> What do you think?
>
> There is also at least one data consumer I know about that is using
> parking lane information and displays it visually,
> https://github.com/dabreegster/abstreet it would be good to know how
> they interpret and visualize the data.
>
> Cheers
> Tobias
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-06 Thread Andrew Harvey
The documented tag for that is place=locality, an in populated named place.
it's rendered and in Nomatnium.

On Sat, 7 Nov 2020, 12:44 pm Martin Søndergaard, 
wrote:

>   I am also very much a newcomer only having mapped for a few months, and
> so far I have constantly been running into the same problems that
> are mentioned in this thread.
>
> I am mapping in Denmark where we have high quality official information on
> place names. However, adding much of this information in OSM is very
> difficult. In most cases the place names are *not* tied to a single
> specific landuse or natural area. Here are a couple examples I have worked
> on:
>
> *Orebanker* - https://www.openstreetmap.org/way/861178572
> This is a prominent bank or elongated hill with a single name. However, it
> consists of a mix of landuse=forest and landuse=farmland and no obvious
> single feature to add the name to. What is the correct way to tag this?
>
> *Viemosen *- https://www.openstreetmap.org/way/863161581
> This is the name of an area of wetland/meadow, but a part of the area has
> been reclaimed for farmland. However, the name officially still applies to
> the original area, so it should include the farmland just north of the
> meadow. Instead I have had to just add the name to the only feature that
> covers most of the area. You could argue that it is better than nothing,
> but technically it is slightly incorrect information.
>
> As a casual mapper mapping this information is really discouraging. Best
> case, the names might show up on renders in 5-10 years; worst case, the lag
> of standard guidelines on this means that the tagging is wrong or few
> people add this information and renderers never render it.
>
> I understand that tagging standards are based mostly on how many current
> features with  said tag there are and it is therefore slow to change. And
> this process makes some amount of sense for more specialized information.
> But for something as basic as "*how do we tag the place name of an area
> that is not tied to a single feature?*" it baffles me that there is no
> consensus after 16 years. It is clearly a sign that the current process of
> agreeing on tagging standards is not working in this specific case.
>
> /Martin
>
> On Fri, 6 Nov 2020 at 19:34, Anders Torger  wrote:
>
>> Hello everyone, newcomer here!
>>
>> I've been a casual contributing mapper for a couple of years here in
>> Sweden. Only since 2018 :-O, I thought it was longer, and during this
>> time I've made 1700 edits mostly using iD, just started using JOSM for
>> some more complex edits. Anyway, I recently tried to up my game to make
>> really high quality and "complete" maps in the areas I live. I have a
>> lot of local knowledge combined with very high quality government maps
>> (already preloaded into the editor, not the highest resolution version,
>> but enough for most aspects) together with satellite images which today
>> has much better alignment than a few years ago (still government maps
>> are best on that). So good reference is there too, I have all I need to
>> make a good job.
>>
>> My areas are bit more rural, more nature. Villages, hamlets and towns.
>> Nature is prominent and naming nature is important, many old names but
>> still in active use by forestry, outdoor people, hunters and locals.
>> When mapping these, I immediately run into basic issues that I'm
>> surprised that they aren't solved already.
>>
>> I'm not 100% sure if this mailing list is the right venue for discussing
>> these issues. OSM as a community is quite hard to grasp for a newcomer
>> and I have been sent to different places, but now I'm here.
>>
>> Anyway, my observations (mostly using the default openstreetmap-carto
>> style) :
>>
>> ** Tagging bays and straits as areas work great, as the renderer gets
>> and idea how prominent it is and it can make proper text sizing and they
>> can be seen even if zoomed out if the area is large. Lots of our lakes,
>> even quite small ones have sub-naming, and with these features I can
>> make really good mapping of this.
>>
>> ** Tagging and naming areas on ground does not seem to be developed much
>> at all, unfortunately.
>>
>> ** There is natural=peninsula so one can tag and name an area of varying
>> size, but it doesn't seem to render (unless I've made some mistake...)
>>
>> ** I can't make an area to name hills or slopes, which is very common
>> around here (natural=hill would be nice and is more generic than slope).
>> There's peak, but that's only for point for the highest peak with
>> elevation, so it doesn't the purpose here.
>>
>> ** Valleys can only be tagged as ways, but here it would make much more
>> sense to make an area, as sizes of these valleys vary a lot, and the
>> renderer need to know how large this is (not just how long) to make sane
>> renders.
>>
>> ** Due to limitations in area-based name tagging the map looks empty
>> just when zoomed out a little, as names disappear almost directly, so
>> 

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

2020-11-06 Thread Andrew Harvey
All great points there, I've ran into many of those myself. If you're
interested in helping work on solutions to these, discussion here is
probably the best place to start, once ideas gain some momentum you can
start a tagging proposal
https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that
process takes a huge amount of time, effort and communication, but usually
results in well rounded documentation and considers a wide range of
scenarios and creates better tags than just "using whatever tags you like".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-04 Thread Andrew Harvey
I wouldn't do that because then logically you have two features, but in
this case they are one in the same, it's a rideshare pickup parking lot, as
opposed to a on-street section designated for rideshare pickup/dropoff.

On Thu, 5 Nov 2020 at 09:38, Simon Poole  wrote:

> While I would try to avoid it, you can naturally simply duplicate the
> geometry (and you don't even need to duplicate the nodes to do that).
> Am 04.11.2020 um 22:26 schrieb Andrew Harvey:
>
>
> On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:
>
>> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>>
>>
>>
>> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>>
>> We don't seem to have a tagging currently for dedicated pickup locations
>> in this kind of context, bus stops etc are naturally taggable), if
>> considered really useful I don't see why we couldn't introduce a
>> amenity=...pickup... tag.
>>
>>
>> But if such a dedicated pickup location is a carpark then it needs
>> amenity=parking, so it can't fit into the amenity key.
>>
>>
>> A pickup point will be a node within a car park area.
>>
>> Its is already common to add amenity=bicycle_parking nodes within
>> amenity=car_park areas.
>>
>
> Why would it be a node within a car park? For example
> https://www.openstreetmap.org/way/366754575 is the designated airport
> Uber, etc. pickup location, not some point inside the car park, but the
> whole car park itself.
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-04 Thread Andrew Harvey
On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:

> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>
>
>
> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>
> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>
>
> But if such a dedicated pickup location is a carpark then it needs
> amenity=parking, so it can't fit into the amenity key.
>
>
> A pickup point will be a node within a car park area.
>
> Its is already common to add amenity=bicycle_parking nodes within
> amenity=car_park areas.
>

Why would it be a node within a car park? For example
https://www.openstreetmap.org/way/366754575 is the designated airport Uber,
etc. pickup location, not some point inside the car park, but the whole car
park itself.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-03 Thread Andrew Harvey
On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:

> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>

But if such a dedicated pickup location is a carpark then it needs
amenity=parking, so it can't fit into the amenity key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-03 Thread Andrew Harvey
On Wed, 4 Nov 2020 at 00:13, Lukas Richert  wrote:

> Hi,
>
> While the original proposal did specify that generators are usually
> diesel, broadening the definition would only lead to a loss of detail, but
> the tagging would still be correct. I'm hesitant to use *offgrid* as a
> building that has, for example, a grid connection with solar panels on the
> roof would then be tagged as *electricity=grid;offgrid* instead of
> *electricity=grid;generator*. The former is illogical.
>
> However, I don't have any experience in developing countries: is it easier
> to verify if something is off-grid compared to if it is connected to a
> generator? And, would it be necessary to differentiate between local grids
> (i.e. 2-3 generators, no substations, transfromers, etc.) and national
> grids? Perhaps then a network tag would be useful, i.e. network=national,
> local, regional similar to the way cycle networks are mapped?
>
> A further suggestion was to change the tagging to
> *electricity:grid=yes/no/backup* and/or
> *electricity:generator=yes/no/backup*. This might be less ambiguous for
> tagging amenities or buildings that get electricity from both sources and
> would then be more consistent with tagging such as
> *electricity:generator:origin=diesel* when, e.g. a building has a backup
> diesel generator but is connected to the grid. Unfortunately, it would then
> not be consistent with the use by the Healthsites Mapping Project, although
> this already has the inconsistent *electricity=none* tag which should
> probably be changed directly to *electricity=no.*
>
Here is the link to that suggestion I made
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#multiple_values
 and
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#origin_of_different_sources

The whole point of the proposal process is to identify these potential
issues, resolve them, and get community agreement. If the goal is just to
implement someone else's standard then we can't use the wisdom of the
community here to improve the tag, therefore I'm not too fussed about
making this match what another project is using, instead we should aim to
have the best tags and documentation as the outcome of this proposal
process. Then if that's different, other projects closely tied to OSM can
migrate to the OSM community accepted schema.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - electrcity=*

2020-10-30 Thread Andrew Harvey
On Sat, 31 Oct 2020 at 08:42, Steve Doerr  wrote:

> On 29/10/2020 16:50, Lukas Richert wrote:
> > as I've received no further comments to the proposal and all points
> > brought up should be resolved,
> > https://wiki.openstreetmap.org/wiki/Proposed_features/electricity is
> > open for voting now.
> >
>
> I see some evidence of voting, but it's in a section entitled 'Comments
> from voting 29-30 October'. Is there really only two days of voting on
> this application, and are votes considered 'Comments on voting'? It
> seems a bit misleading to me. Also, aren't there usually some
> instructions on how to vote? I find it a bit strange that people are
> actually replying to other people's votes - is that normal?
>

Lukas moved it back from Voting to Proposed, so voting is paused/stopped,
after more RFC time has passed it might open back up for voting.

I think it's fine to comment on other people's votes, usually to raise a
point or concern about their reasoning or justification. If I vote no and
give my reasons, but someone sees a flaw or mistake in my reasons I'd like
them to comment back to me so I'm aware of that and can re-assess my voting
position.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - electrcity=*

2020-10-29 Thread Andrew Harvey
Agree with Jan here, I didn't see the RFC either, but looking now I feel
there are still things which need discussing before voting.

In general I agree with the idea, but I don't feel like the issues at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity are
resolved yet so would have to vote no if the voting went ahead so that
these issues can be resolved.

On Fri, 30 Oct 2020 at 05:35, Jan Michel  wrote:

> Hi Lukas,
> I guess that most people (like me) missed your RFC.
> You posted it as a reply to a completely different topic
> about railway=station and not as a separate thread.
>
> I'd like to ask you to stop voting, repost the RFC for
> everybody to read and wait for comments.
>
> Jan
>
>
> On 29.10.20 17:50, Lukas Richert wrote:
> > Good evening,
> >
> > as I've received no further comments to the proposal and all points
> > brought up should be resolved,
> > https://wiki.openstreetmap.org/wiki/Proposed_features/electricity is
> > open for voting now.
> >
> > Cheers, Lukas
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-27 Thread Andrew Harvey
On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi  wrote:

> We've got emergency=landing_site for helicopters, maybe just
> emergency=parking?
>

I like that, areas set aside for parking by emergency vehicles.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

2020-10-25 Thread Andrew Harvey
I've drafted a proposal for natural=rock_overhang at
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Drock_overhang
please
provide any feedback or suggestions.

On Mon, 26 Oct 2020 at 15:10, Andrew Harvey 
wrote:

> Voting is closed now with 8 yes, 8 no, 2 abstain. no clear consensus here
> so marked as rejected.
>
> Reviewing those against, a common theme is the view that amenity=shelter
> should be reserved for purpose built/man made shelters and not natural
> features commonly used as a place of shelter.
>
> I'm still keen to have an approved way to map these features and avoid the
> current situation where two different kinds of features are commonly mapped
> using the same tag leaving no way to distinguish them.
>
> So with this voting feedback in mind I'll move ahead with a new proposal
> for natural=rock_overhang.
>
> On Mon, 12 Oct 2020 at 10:34, Andrew Harvey 
> wrote:
>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
>>  is
>> open for voting now.
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

2020-10-25 Thread Andrew Harvey
Voting is closed now with 8 yes, 8 no, 2 abstain. no clear consensus here
so marked as rejected.

Reviewing those against, a common theme is the view that amenity=shelter
should be reserved for purpose built/man made shelters and not natural
features commonly used as a place of shelter.

I'm still keen to have an approved way to map these features and avoid the
current situation where two different kinds of features are commonly mapped
using the same tag leaving no way to distinguish them.

So with this voting feedback in mind I'll move ahead with a new proposal
for natural=rock_overhang.

On Mon, 12 Oct 2020 at 10:34, Andrew Harvey 
wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
>  is
> open for voting now.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Takeaway drink shops

2020-10-21 Thread Andrew Harvey
Hi Tan,

Just wanted to say thank you for all your work on the takeaway drinks
proposal. I know it takes a lot of effort putting together a detailed
proposal and addressing feedback. Personally I think it was a great
proposal which would have improved the OSM ecosystem, so quite
disappointed it didn't pass even with a majority of support, but regardless
you did a stellar job.

On Mon, 5 Oct 2020 at 17:46, 德泉 談 via Tagging 
wrote:

> Dear All,
>
> The voting of the takeaway drink shops is on, please vote the proposal
> here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Takeaway_drink_shops
>
> Thanks,
>
> - Tan
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Parking fee only after some time period

2020-10-21 Thread Andrew Harvey
On Wed, 21 Oct 2020 at 20:20, Philip Barnes  wrote:

> On Wed, 2020-10-21 at 20:04 +1100, Andrew Harvey wrote:
>
>
>
> On Wed, 21 Oct 2020 at 19:45, Robert Delmenico  wrote:
>
> Ballarat in Victoria has kerb side parking where the first hour is free.
>
> There is some more information available here:
>
>
> https://www.ballarat.vic.gov.au/city/parking/smarter-parking-ballarat#:~:text=Your%20first%20hour%20of%20parking,the%20Central%20Square%20car%20park%20
> .
>
>
> The wiki is not the clearest on this
> https://wiki.openstreetmap.org/wiki/Key:parking:lane#Parking_conditions_.28terms.29
>
> You can do `parking:condition:left=ticket` +
> `parking:condition:left:conditional=free @ (maxstay > 1 hour)` though not
> sure if that's the best, but the best I can tell from the wiki.
>
> disc is not defined, I'd never heard of the term before and
> https://en.wikipedia.org/wiki/Disc_parking isn't that clear. It would be
> good if people using this would put a bit more detail on the OSM wiki of
> where it should be used. Is it only where the physical "disc" is used? Does
> it imply a fee or not, does it imply a maxstay?
>
>
> Parking discs used to be quit common in France, the Disque Blue areas were 
> very common in towns where you needed to set the time of arrival on your
>
> disc and display it in the car.
>
>
On Wed, 21 Oct 2020 at 20:58, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> disc appears at https://wiki.openstreetmap.org/wiki/Key:parking:lane
>
> with proposed tag a parking:condition:*:maxstay=2 h
>
> with * replace by left/right/both depending on side
>


So it's just plain old maxstay, but you need to mark your arrival time on a
device, could be paid or free. The only thing the tag adds over
`parking:condition:side:maxstay=2 h` is that it describes that you need to
use the disc device to record your time of arrival?

This part was unclear to me if it should be used for any maxstay regardless
of if it uses the disk device or not.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Parking fee only after some time period

2020-10-21 Thread Andrew Harvey
On Wed, 21 Oct 2020 at 19:32, stevea  wrote:

> In California, a common (not quite frequent, certainly not always)
> arrangement at malls, supermarkets and other places with parking lots
> (large and small) is a sign that reads "you can park here for three hours,
> but after that we have the right to tow your car away."  (Sometimes
> punctuated with 'video surveillance active' to make the point fairly direct
> and that "they mean business").  In my experience of driving-and-parking
> for many decades, I personally have never gotten towed (the few times I've
> gone over a time limit), I've never heard of anybody (that I personally
> know) getting towed, but I have seen the extremely infrequent tow truck
> towing a car that has likely been there a while — perhaps it was abandoned,
> used for illegal purposes or was otherwise a public nuisance.
>
> So, while that "moderately serious consequence" of getting towed is
> possible, it's rare.  And, while this is not a "fee," it certainly turns
> into a fairly large one once the bottom-line-costs, tow truck driver and
> storage charges (per day, usually) are added together and paid to get one's
> car back from the impound lot.
>
> If you are writing a proposal, this is a reality in certain parts of the
> world the proposal should consider, if it wants to convey the full
> situation (on Earth, in cars, with humans, on parking lots).  In short,
> what appears to be "simply" a fee can be fairly full-throated when it comes
> to describing the entire semantic richness of the situation.
>
> A tag like maxstay is a good beginning.  An additional tag of something
> like towing_penalty=yes|no is a start down this road.
>

I'd just use the regular maxstay tag, I think most places if you overstay
they can tow you.

`fee:conditional = no @ maxstay < 3h` says you're allowed by the rules of
the car park to park longer if you like, but you need to pay a fee to do
so. This is different to the rules saying you're limited to 3hr and then
issuing a fine or penalty for overstaying
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Parking fee only after some time period

2020-10-21 Thread Andrew Harvey
On Wed, 21 Oct 2020 at 19:45, Robert Delmenico  wrote:

> Ballarat in Victoria has kerb side parking where the first hour is free.
>
> There is some more information available here:
>
>
> https://www.ballarat.vic.gov.au/city/parking/smarter-parking-ballarat#:~:text=Your%20first%20hour%20of%20parking,the%20Central%20Square%20car%20park%20
> .
>

The wiki is not the clearest on this
https://wiki.openstreetmap.org/wiki/Key:parking:lane#Parking_conditions_.28terms.29

You can do `parking:condition:left=ticket` +
`parking:condition:left:conditional=free @ (maxstay > 1 hour)` though not
sure if that's the best, but the best I can tell from the wiki.

disc is not defined, I'd never heard of the term before and
https://en.wikipedia.org/wiki/Disc_parking isn't that clear. It would be
good if people using this would put a bit more detail on the OSM wiki of
where it should be used. Is it only where the physical "disc" is used? Does
it imply a fee or not, does it imply a maxstay?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Parking fee only after some time period

2020-10-20 Thread Andrew Harvey
I agree these are very common arrangements.

On Wed, 21 Oct 2020 at 07:46, Martin Koppenhoefer 
wrote:

> I am not usually mapping this detail of parking fees, but from my
> understanding the above suggested tags would work and could be seen as
> covered by current state of tagging, no need for a proposal, just use it.
> https://taginfo.openstreetmap.org/keys/fee%3Aconditional#values
>

I agree, I wouldn't think it needs a proposal since I thought it's already
covered by the current :conditional and maxstay schemes.


> as a note, I believe we should "err on the safe side", i.e. better
> A)
> fee=yes
> fee:conditional = no @ maxstay < 3h
>
> than B)
> fee = no
> fee:conditional = yes @ maxstay > 3h
>
> I think I would ignore the maxstay==3h condition, ;-)
>

I agree, generally I think of these as paid parking, but with the exception
that if you stay for a short time it's free, as opposed to being free
parking but if you overstay the parking they charge you a fee (the latter
would be more like a fine for going over the limit, but rather this is
usually just a grace period for not needing to pay).

I've came to the same conclusion in the past where I tagged
https://www.openstreetmap.org/way/23024004#map=19/-33.79813/151.18415

Taginfo says 9 things tagged like this already
https://taginfo.openstreetmap.org/tags/fee%3Aconditional=no%20(maxstay%3C2%20hours)
 +
https://taginfo.openstreetmap.org/tags/fee%3Aconditional=no%20(maxstay%3C3%20hours)

This is also the syntax I suggested for the streetcomplete quest at
https://github.com/westnordost/StreetComplete/issues/102#issuecomment-687761605

https://wiki.openstreetmap.org/wiki/Key:maxstay recommends to always add a
unit (unlike maxspeed, maxheight, maxweight which all have default units)
and all the examples use expanded terms in English eg "hours" instead of
"h" or "hr". Any good data consumer would want to parse out all the
variants, so I wouldn't complain if you used "h" instead of "hours" but
would be nicer if there was only one way to tag it, so I'd prefer to stick
with the full term like on the wiki "hours".

Unless there is disagreement we can just add this example to the wiki.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-20 Thread Andrew Harvey
On Tue, 20 Oct 2020, 5:34 pm Robert Delmenico,  wrote:

> They mean the same thing, we tag different aspects of a bridge with
> different tags.
>

Not quite if I want to count how many bridges there are you'd count
man_made=bridge. Counting bridge=yes would give you an overcount as it's
only road segments on a bridge not a bridge.

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


Re: [Tagging] How are busways mapped, which are not guideways?

2020-10-18 Thread Andrew Harvey
When you say busway is that just a road that only busses are allowed to
use, and specifically signposted for busses? if so then the suggested you
noted of highway=* + bus=designated + access=no would be correct.

On Sun, 18 Oct 2020 at 17:12, Joseph Eisenberg 
wrote:

> There is an approved tag for bus guideways, where specially-designed buses
> are guided by a rail:
>
> But how should ordinary busways be mapped? Right now the suggestion on
> highway=bus_guideway is that other busways might be mapped highway=service
> + bus=designated + access=no. (See
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_guideway)
>
> There is also a somewhat common tag service=busway which has been used
> 2500 times, and can be added to highway=service
>
> Alternatively, the tag highway=busway has been used a couple of dozen
> times, and there is a new draft proposal to use this tag instead of
> highway=service, for standard busways:
> https://wiki.openstreetmap.org/wiki/Tag:highway=busway
>
> A new tag would require database users to adapt, but since guided busways
> already have a specific tag, it seems odd that other exclusive busways are
> mapped only as service roads.
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-15 Thread Andrew Harvey
On Thu, 15 Oct 2020 at 23:44, Volker Schmidt  wrote:

> May I remind my dear mapper friends, that tags are just that: tags. From
> the database point of view these are just couples of arbitrarily chosen,
> character strings. OSM uses a convention to make it easier to memorize
> these strings by using GB-English terms for them, but, I repeat that is
> just a convention to help our human brain facilities. If you were to
> replace the string "man_made" at every occurrence in the database and in
> all programs that use the database with "3rgnJI)oò-" this would make no
> difference to OSM (provided you use different strings for different
> keys/values), but it would make a huge differnce to the work of
> inserting/correcting/consulting data by human beings.
> In addition, replacing one string with another string in all occurrences
> in OSM, apart from creating completely unnecessary new versiones of the
> objects, is trivial. Changing all products that make use of these data will
> be an enormous amount of work.
> And all this effort achieve what?
>

Exactly. The human readable version of tags is done through things like
editor presets and partly via the wiki infoboxes, where they can be
localised into different languages and regions. The actual tag names bear
zero weight and it's impossible to have them accurate across regions. My
favourite one is track vs trail, where for me track is narrow that you can
only walk and tail is wide that you can drive on, but for other parts of
the world it's the opposite, track you can drive on and trail only walk.
That doesn't mean we'll change up highway=track as it's the description on
the wiki that matters not the name of the tag key and value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-12 Thread Andrew Harvey
On Tue, 13 Oct 2020 at 10:29, Brian M. Sperlongano 
wrote:

> 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 specific option to a final yes/no vote on the most popular
> alternative.
>
> If, after that, a >74% yes vote cannot be achieved, there simply is not
> enough community consensus to move forward with the change.
>

I think for the most part this does happen already through the proposal
draft and feedback, the feedback identifies a few alternatives with one
having a bit more of a majority than the other options, so that one is
selected for the vote, but the vote could still fail to resolve a way to
map something due to the high 75% bar.

For me "there simply is not enough community consensus to move forward with
the change." is the issue because you can effectively lock out certain
valid things from being mapped and consumed in a standard way because there
is no large majority in favour.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-12 Thread Andrew Harvey
On Tue, 13 Oct 2020 at 09:36, Paul Allen  wrote:

>
> On Mon, 12 Oct 2020 at 23:23, Andrew Harvey 
> wrote:
>
>> I wrote about changing from a for/against vote to a pick your preferred
>> option at https://www.openstreetmap.org/user/aharvey/diary/394419
>>
>> Interested to hear what others think about this.
>>
>
> There are inherent problems when using first-past-the-post voting with
> more than two political candidates, and these have been covered
> extensively.
>

You could do preference voting, ranking your preferred options in order and
using one of the existing voting processes out there of which there are
many.

Regardless of the exact voting process at least it will give you a result,
a way to tag X instead of a no-result which can happen relatively easily at
the moment.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-12 Thread Andrew Harvey
I wrote about changing from a for/against vote to a pick your preferred
option at https://www.openstreetmap.org/user/aharvey/diary/394419

Interested to hear what others think about this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter

2020-10-11 Thread Andrew Harvey
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
is
open for voting now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] railway=station areas

2020-10-09 Thread Andrew Harvey
On Sat, 10 Oct 2020 at 09:35, Dave F  wrote:

> Apologies for breaking the thread, but I was unable to connect to
> Tagging & missed the initial message in my email client.
>
> I'm the user in disagreement. (Although reading the current
> railway=station wiki page I'm not convinced there's an genuine
> alternative belief).
>
> I believe most of this discussion is moot as the *vast* majority of
> railway=stations are mapped as nodes:
>   NodeWay Relation
> IT   2878400 15
> DE   438839  45
> FR   2553646 14
> JP   90635   11
> US   4140174 8
>

I don't think that makes the point moot since nodes are just a quick first
pass way to map a station, eventually they should all be upgraded to areas.
The same way you can map a building as a node as a first pass,
a footprint area is always better.

I edited a copy of the diagram (A-simple-station.svg) of a station
> layout, primarily to remove any references to PTv2 tags, a completely
> independent, duplicating tagging schema, irrelevant to anything to do
> with the railway=station tag. I also amended the area indicating what
> roughly constitutes a 'railway station' according to the wiki. This is
> the only page I uploaded the image to. (It's not complete - the creation
> of the PNG image removes the angled text I used)
>
> It appears that in 2015 a user took it upon himself to wholesale rewrite
> the wiki page, based on discussions in OpenRailwayMap IRC, a small
> clique group that keeps no record of any conclusions. If anyone knows if
> discussions took place on a major, wider reaching forum, please indicate
> them.
>
> Tagging objects should be based on the understanding of what the general
> consumer of OSM accept it to be, not just a small group of "rail
> enthusiasts" from Germany.
>

OSM should as much as possible try to remain agnostic towards a specific
audience or use, we should strive to both be accurate and usable for both
train drivers and public transport passengers. This is not just a matter
for rail enthusiasts from Germany.


>  >the railway is from the rail network/infrastructure point of view and
> public
> transit from the passenger point of view.
>
> This seems to be a common misunderstanding by those advocating PTv2.
>

I'm not advocating PTv2, for a long time it just seemed like duplication of
tags and a waste but if the ability to separate out the rail infrastructure
from passenger viewpoint can be done with the tagging schema then that's
maybe one advantage.


> Railway=station is the original tag for all stations, including
> passenger. Introducing a disparate schema at a later date, does not
> change the meaning of the original tag.
>
>  > In practice many are mapped as the same area, but that's usually only
> because unless you're a train operator it can be hard to actually survey
> where the station starts and ends from the train network point of view.
>
> No, it's because the public area is what most people consider to be a
> 'station'. (& most are mapped as nodes)
>

Maybe a solution is to keep railway=station and public_transport=station
both defined as the passenger view, but use a new tag for rail
infrastructure so you can still correctly map the station for train
drivers. The downside is that's an extra tagging schema to make things even
more complicated.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] railway=station areas

2020-10-07 Thread Andrew Harvey
On Wed, 7 Oct 2020 at 18:42, Martin Koppenhoefer 
wrote:

> I know we have already been discussing this several times in the past, but
> due to recent editing disagreements in the wiki, I am raising it again.
>
> For several years, we had railway=station on a way documented in the wiki
> as the complete area of a train station.
> https://wiki.openstreetmap.org/wiki/File:A-simple-station.svg
>
> This was also discussed in the wiki:
> https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dstation#Station_an_area_.3F
>
> And it is what we do around here locally. It is also what the definition
> of railway=stations says, the tag defines "A railway station".
>
> A fellow editor now insists that this tag should be used on the same area
> as defined for public_transport=station, i.e. the part of the train station
> that is accessible by passengers (platforms and buildings near the
> platforms).
> https://wiki.openstreetmap.org/wiki/File:Railway%3DStation.svg
>
> I am reaching out to the wider community because the user and me could not
> come to an agreement.
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dstation=history
>

I agree that for a long time the distinction between railway=station areas
and public_transport=station areas are as you've noted and as the wiki used
to say. I think it makes sense to retain this convention so that the
railway is from the rail network/infrastructure point of view and public
transit from the passenger point of view.

In practice many are mapped as the same area, but that's usually only
because unless you're a train operator it can be hard to actually survey
where the station starts and ends from the train network point of view.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-09-30 Thread Andrew Harvey
On Wed, 30 Sep 2020 at 18:58, stevea  wrote:

> This is useful because it shows not only where OSM mappers (like me) will
> need to update landcover
>

At least after the Australian fires, we still left natural=wood areas which
burned tagged that way, and in my view this is correct since they are still
are wooded areas even after the fire even with crown fires and with many
trees not surviving.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-09-30 Thread Andrew Harvey
So it seems then that what you're mapping here isn't so much the active
fire front, it's the burnt area given you want it to stick around after the
flames are out.

During Australia's fires last season, I did contemplate mapping active fire
fronts, given I could see with my own eyes where the flames were up to and
I could have done a more accurate job for a small area than what the
government authority was publishing at the time. However due to the fast
changing nature of it and temporary nature of the active front, I don't
think it's worth mapping.

For burnt areas and recovery progress, sure this is not temporary (could be
a few months to years for evidence on the ground) and it's not fast
changing, once an area is burnt it stays burnt. So yeah you could map it,
but from my experience in Australia this again wouldn't be worth it (not
saying that you shouldn't map it, the way isn't really harmful and I'm not
local, so not telling you what to do). The main reason here is that the
burn isn't uniform, patches are noticeably burnt to a higher degree than
others and some patches might be unaffected, and it can be hard to survey
this. It's also hard to know when to remove it from OSM, because after all
OSM doesn't contain historical features which aren't found on the ground
anymore, so at some point OpenHistoricalMap becomes more appropriate.

Satellites do a pretty good job of finding out which areas burned and to
what degree, so I'm happy mostly to just rely on rasters from satellite
instead of hand traced and vectors in OSM.

On Wed, 30 Sep 2020 at 16:30, stevea  wrote:

> It appears somewhat-established (in this thread) that data consumers both
> DO and WILL find a datum of a polygon tagged fire=perimeter to be useful.
> This might be for "remap HERE when newer imagery becomes available"
> purposes (to a mapper in the area like me), to "might want to avoid hiking
> in this area as some roads / trails may remain or be closed, and it can be
> quite dangerous with "stump-slump" causing trail failures / slippages..."
> purposes (to a hiker in the area like me).  Not to mention other reasons /
> purposes cited here.
>
> I'll say it once again:  such a fire=perimeter IS a real-world "thing,"
> represented in OSM by a lightweight datum that I find to be "worth it" to
> be in the map.  It serves both better-near-future-mapping purposes as well
> as end-user / map consumer purposes.  I find that "balance" (storage cost
> in the database, whether such a datum should or shouldn't be "in the map at
> all," its usefulness to diverse OSM audiences for various, useful
> purposes...) to have value, even significance (though I'm local, so I'll
> grant I'm biased).  It seems others find similar value, too and agree that
> "sharing" such data, as OSM does, is both valid and valuable (to some) data
> to map.
>
> After all, we don't want to "hold back people from using (such data) in
> creative, productive, or unexpected ways," do we?
>
> Thanks for great feedback here,
> SteveA
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

2020-09-04 Thread Andrew Harvey
All good feedback so far, it's pleasing to see I'm not the only one
interested in tagging these features.

On Sat, 5 Sep 2020 at 11:38, Jmapb via Tagging 
wrote:

> Assuming that I located the correct crack, it was undoubtedly a case of
> overzealous tagging. The problem I see is that the definition of rock
> shelter is subjective enough that this sort of tagging will happen from
> time to time. Some mappers will stretch the definition because they just
> love adding features. And since rock shelters are currently a subtag of
> amenity=shelter, people looking for amenity=shelter -- with the possibly
> live-saving properties that implies -- will be misled.
>
> Tagging a rock shelter any other way -- natural=rock_shelter,
> amenity=rock_shelter, whatever -- and we're no longer bound to fulfilling
> the existing expectations of the parent tag.
>
That's why it's a good idea to use the shelter_type sub tag, to provide
further detail on the type of shelter here and provide further information.

amenity=shelter alone shouldn't have an expectation that it's anything more
than a place to escape a storm to provide some protection. Plenty of bus
shelters in a big storm you'll still get soaked if it's windy as well.

Not all rock shelters / overhangs / endogene caves are the same size, I
guess you could try to tag in meters how far it goes into the rock as an
indication of size.

Overzealous tagging can happen regardless of what the tag is though, even
natural=rock_shelter can be abused for even the most minor feature, same
goes for waterfalls, cliffs, peaks and most natural features.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

2020-09-04 Thread Andrew Harvey
On Sat, 5 Sep 2020 at 01:23, Mateusz Konieczny 
wrote:

> "A cave you might need a torch to explore" - note that caves may be
> smaller.
>
> In fact, some cave classifications have separate categories for caves
> small enough/open enough to be fully lit by sun and at least some consider
> rock shelters to be a type of cave.
>

According to wikipedia, "The word cave can also refer to much smaller
openings such as sea caves, rock shelters, and grottos, though strictly
speaking a cave is exogene, meaning it is deeper than its opening is wide,
and a rock shelter is endogene." which makes sense as I mentioned in the
proposal, many of these rock shelters/rock overhangs are named as caves.

Regardless I was going by the description at
https://wiki.openstreetmap.org/wiki/Tag:natural=cave_entrance and that
seems to imply it's for the exogene type not the endogene type, further an
"entrance" to the cave only really holds meaning for the exogene type.

If we can come up with a way to tag the endogene type like rock shelters,
then that free natural=cave_entrance would naturally then just be for
the endogene type where there is a large underground and enclosed cavity.

On Sat, 5 Sep 2020 at 02:19, Jmapb  wrote:

> I agree that a shallow rock overhang that can be used for ad hoc shelter
> is not the same as a cave. But I'm strongly in favor of
> discouraging/deprecating shelter_type=rock_shelter.
>

I have no strong ties to that particular tag, all I want is a clear way to
distinguish these rock shelter endogene type caves from the exogene caves
which you could walk or crawl through. The shelter_type=rock_shelter tag
already has use and meets the description of these real word objects well,
so seemed the path of least resistance.


> I'm a bit strident about this because I've been personally "betrayed"
> using an OSM-derived hiking map, expecting to arrive at a shelter in
> poor weather and finding nothing. Back in civilization, I examined the
> node and discovered the shelter_type=rock_shelter subtag, but the map in
> question didn't render it any differently. Revisiting the site in fair
> weather, I found a tiny crack under a ledge that *might* have kept a
> child dry. It was very satisfying to delete that node.
>

All the ones I'm familiar with are certainly big enough to provide shelter
in poor weather. A "tiny crack under a ledge that *might* have kept a child
dry" I don't think is significant enough to be tagged as a rock shelter,
but that doesn't mean that none of these kinds of larger features which are
commonly used for shelter should be.

Obviously the map rendering can be improved, but it's against the
> general anti-troll-tagging practices to have a subtag that undoes the
> essential properties of the main tag. Because of the ambiguity as to
> what constitutes a viable rock shelter, I think
> shelter_type=rock_shelter falls into this category.
>

I don't see how this subtag undoes any essential properties of the main
tag, after all amenity=shelter is described on the wiki as "A small place
to protect against bad weather conditions", which a rock shelter is
exactly. Nothing on the amenity=shelter wiki page says that it's only for
man-made features.


>
> I'd suggest natural=rock_shelter as a replacement tag.
>

I'm not tied to any one particular tag, but just looking to further
formalise a tag that already has some documentation on the wiki and already
has extensive use in OSM.

If that tag was used, unless the wiki definitions are changed for
amenity=shelter to be strictly man-made it would not be wrong for someone
to tag amenity=shelter + natural=rock_shelter, which I guess is fine, as
one is mapping the actual natural feature and the other is saying how it
can be/is used.

On Sat, 5 Sep 2020 at 06:21, Tom Pfeifer  wrote:

> +1 for going into the natural key
> My expectations to amenity=shelter would be something purpose-built,
> which is true for all subtypes except that rock_shelter
>

Nothing on amenity=shelter wiki page says that it must be purpose-built and
not naturally occuring.

On Sat, 5 Sep 2020 at 08:47, Martin Koppenhoefer 
wrote:

> amenity=shelter is not about being purpose-built but about something being
> used for a purpose.
> I would not use the natural key with a value like "shelter" or
> "rock_shelter", as this is about the purpose, a specific use of the
> situation, and not a description of the physical situation.
> From the point of view of shelter tagging, shelter_type=rock_shelter seems
> a valid approach and I would go for it.
>
> You could still double tag it with natural=cliff_overhang (or whatever
> describes the feature) if you like.
>

Agreed.

On Sat, 5 Sep 2020 at 09:25, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> amenity=shelter is not about being purpose-built but about something being
> used for a purpose.
>
> +1 - I am 100% fine with amenity=shelter with rocks acting as a shelter
> (as long as usefulness
> is as good as purpose made shelter, not 

[Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

2020-09-03 Thread Andrew Harvey
I've created a proposal to formalise shelter_type=rock_shelter, while
currently in-use, there is disagreement within the community on if this tag
should be used and features are commonly mis-tagged.

So I'm hoping with this proposal and voting we can come to some
consensus around it's use.

I'll leave it open for two weeks for comments then move to voting.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-24 Thread Andrew Harvey
On Tue, 25 Aug 2020 at 06:27, pangoSE  wrote:

> The POI IMO cannot logically have an adress itself, its a human symbol for
> designating something of interest within a feature like a building, park or
> whatever. Adresses are specialized designations used by the state and
> postal service. You cannot apply for an address for a newsstand, a
> phonebooth or a park (In Sweden)
>

By that logic (at least in Australia) the building cannot have an address,
after all here land parcels hold the address not the building, but we still
commonly tag the building or POI with an address since they "hold" the
address.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
On Mon, 24 Aug 2020 at 15:27, Clifford Snow  wrote:

> I watch flagged changesets in my state, all changesets in my county and
> all changesets by people I've flagged to watch.  I review all edits of new
> mappers to offer them tips if needed. For flagged changesets in the state
> and all changesets in my county I review ones that seem interesting. If
> they request a review I try to review them. So far no one on my watch list
> has reappeared. Those are ones that vandalised OSM and were reported to DWG.
>
> On Sun, Aug 23, 2020 at 9:06 PM Jonathon Rossi  wrote:
>
>> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey 
>> wrote:
>>
>>> In OSMCha you can create a Filter, and in the Filter creation screen set
>>> a polygon area you're interested in monitoring
>>>
>>
>> Andrew, how do you specify a polygon, always wanted to do that but I
>> thought OSMCha only supports a bbox?
>>
>
> You can specify a city, county, state or country as well as a bounding box
> when creating a filter.
>

How were you able to view multiple filters at the same time (eg. watchlist
of users anywhere + all changesets within bounds)? Or do you have to
constantly need to switch filters? I can only handle one listing so
anything I can't fit into one filter I miss even though I'd prefer to see
it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
I read it as the changeset bbox intersects your location boundary where
your location boundary could be an arbitrary polygon, not that your area of
interest bbox. You can make a suggestion on the OSMCha issue tracker if you
have a better idea though.

On Mon, 24 Aug 2020 at 14:47, Jonathon Rossi  wrote:

> On Mon, Aug 24, 2020 at 2:22 PM Andrew Harvey 
> wrote:
>
>> On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi  wrote:
>>
>>> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey 
>>> wrote:
>>>
>>>> In OSMCha you can create a Filter, and in the Filter creation screen
>>>> set a polygon area you're interested in monitoring
>>>>
>>>
>>> Andrew, how do you specify a polygon, always wanted to do that but I
>>> thought OSMCha only supports a bbox?
>>>
>>
>> [...] So at the top you should see a map with a button in the top right.
>> Click that button and trace your polygon on the map.
>>
>
> Thanks. I've always read the text next to the map ("Filter changesets
> whose bbox intersect with a location boundary.") as meaning the map helps
> you define a bbox. i.e. it wouldn't keep and filter using the polygon, just
> uses it to work out a bbox to contain the polygon. Is that text misleading?
>
> --
> Jono
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
On Mon, 24 Aug 2020 at 14:21, Andrew Harvey 
wrote:

> I think OSMCha is really good, but it does have room for improvement. I
> get confused between saving a filter and applying the filter, and there is
> a bug which will show the polygon from the previously selected filter, it's
> very fiddly so might take a couple of attempts.
>

Bug report -> https://github.com/mapbox/osmcha-frontend/issues/474
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi  wrote:

> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey 
> wrote:
>
>> In OSMCha you can create a Filter, and in the Filter creation screen set
>> a polygon area you're interested in monitoring
>>
>
> Andrew, how do you specify a polygon, always wanted to do that but I
> thought OSMCha only supports a bbox?
>

When logged into OSMCha you can either click your username dropdown and
select My saved filters, and add it, then load it should popup the
configuration. So at the top you should see a map with a button in the top
right. Click that button and trace your polygon on the map.

I think OSMCha is really good, but it does have room for improvement. I get
confused between saving a filter and applying the filter, and there is a
bug which will show the polygon from the previously selected filter, it's
very fiddly so might take a couple of attempts.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
It'll sit there, but other people looking at OSMCha will see you marked it
as good so they might choose to not bother checking it, or still check it
anyway. You could probably add to the filter to exclude ones marked as
Good, depending if you want to check those too.

On Mon, 24 Aug 2020 at 13:02, Graeme Fitzpatrick 
wrote:

>
>
>
> On Mon, 24 Aug 2020 at 12:11, Andrew Harvey 
> wrote:
>
>>
>> In OSMCha you can mark as good or bad, but no way to say it's been
>> reviewed without explicitly saying good/bad.
>>
>
> Thanks, Andrew!
>
> If you mark it as good, does it then disappear, or just sit there forever?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
On Sun, 23 Aug 2020 at 14:55, pangoSE  wrote:

> And we have no statistics or functionality to mark a changeser as revieed
> so nobody knows how many reviews are done and how many falls through the
> cracks. We could make a tool that lists all changesets with a review
> request and no comments.
>

You can tag the changeset in OSMCha as Good or Bad, but unfortunately no
middle ground of just "Reviewed".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-23 Thread Andrew Harvey
On Sun, 23 Aug 2020 at 15:44, Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 23 Aug 2020 at 08:13, Clifford Snow 
> wrote:
>
>> osmcha.org picks up the review request. Their interface makes it easy to
>> view and post a comment back to the user.
>>
>
> Thanks!
>
> Not exactly a very user-friendly system though, especially if you're only
> trying to review requested changes?
>

In OSMCha you can create a Filter, and in the Filter creation screen set a
polygon area you're interested in monitoring, and set Show Flagged to yes
and Reasons for Flagging to Review requested.

That should then only show changesets which requested a review. You can
also get an RSS feed for this if you use an RSS reader, otherwise maybe an
RSS to email service could work, or just check OSMCha every now and then.

& with somewhere between 300k - 600k changes sitting there to look at, I
> don't think the chances are all that high that somebody will spot any
> errors!
>

I monitor the whole greater Sydney region and south coast and yes it does
take time, but I think it's worth it for the errors you catch. There are a
few others who also review with OSMCha, but we don't have a good way to
distribute the work to avoid duplication and minimize one's slipping
through the gaps.

In OSMCha you can mark as good or bad, but no way to say it's been reviewed
without explicitly saying good/bad.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-22 Thread Andrew Harvey
On Sat, 22 Aug 2020 at 17:25, Thibault Molleman 
wrote:

> So what's the consensus on an apartment building (way) that has mailboxes
> for each person who has an apartment there.
> I've just been tagging those as:
> addr:housenumber = A1;A2;A3;A4;A5;A6;A7;A8;A9;A10;A11
>

Could you use https://wiki.openstreetmap.org/wiki/Key:addr:flats? Leaving
unit/apartment/flat numbers out of the addr:housenumber.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-20 Thread Andrew Harvey
>
>
> And it may be useful to have tag to mark "yes this is actually a single
> housenumber despite
> that includes hyphen or something else that suggests range"
>

I would assume that to be the default, when there are multiple addresses
best to mark them all out individually or use a linear way with the address
at the start and end nodes and addr:interpolation on the line (as a first
pass before mapping them out individually)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-18 Thread Andrew Harvey
On Wed, 19 Aug 2020 at 04:26, Colin Smale  wrote:

> There are two use cases here: one is "what is the address of this building
> (or whatever)" and the other is the reverse situation: "where can I find
> number XXX". As long as we have tagging that is potentially ambiguous we
> won't be able to cover both.
>
> In the US I know of cases where an apartment number can follow the street
> address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I
> know of the suffix being used to indicate apartment number, or floor number
> - e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other
> characters are used for the floor/flat such as A/B/C or I/II/III - in these
> cases it is unambiguous because it is non-numeric.
>

> On the other hand using the "1-5" notation to indicate a range is pretty
> well understood in the UK at least. What it is missing is the
> "interpolation" value (even, odd, all).
>
> So let us sort this mess out by defining:
> 1) that a hyphen indicates a range
> 2) sub-addresses like a floor or apartment number must not use the hyphen
> notation, but must be given in addr:unit
>

Agreed, in those cases when it's not a range but actually an apartment
number or unit number addr:unit is best.


> 3) an address using the range syntax should indicate the interpolation
> scheme by means of addr:interpolation=*
>

The problem with this is addr:interpolation is currently defined as "Every
nth house between the end nodes is represented by the interpolation way.",
when mapping an address which uses a range, there is no start and end
nodes, it's just a single address, you're not saying this range
interpolates multiple addresses here, you're saying there is a single
address and it's a range. In this case we don't need to record the
addr:interpolation since the interpolated addresses don't actually exist
(where exists means signposted).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-18 Thread Andrew Harvey
On Tue, 18 Aug 2020 at 19:15, Simon Poole  wrote:

> The correct ways to model a range of house numbers is to use an address
> interpolation or explicitly list the numbers (using comma or semi-colons as
> delimitiers), anything else is woefully underspecified, not to mention
> other issues, for example hyphens being used to delimit building and
> apartment/unit numbers as in AUS for example.
>
If they are actually individual addresses and you're just taking a shortcut
when mapping by using addr:interpolation
https://wiki.openstreetmap.org/wiki/Key:addr#Tags_for_interpolation_ways then
that's okay.

But when you have a single parcel of land which has a single address which
uses a range, then I don't think addr:interpolation is best, that would
imply there are n addresses along the way here, but actually there is just
a single range address eg 1-3, it's different to an interpolation.

Apartment/unit numbers should be entered with addr:unit, seperate from the
street address number.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-17 Thread Andrew Harvey
> Data consumers see these hyphenated house numbers as one address, as well.

Is that a problem? An address range can be considered a single address.

> Create an address node for each housenumber and place each node somewhere
on the building outline (or inside the building)

I don't think that's a good idea, we should try to accurately map what's on
the ground, when the street address is signposted as a range like "1-3" we
should capture that as a single address "1-3" and not multiple addresses
unless it's signed that way on the ground.

> If house numbers are associated with individual entrances, tag those
numbers to entrance=* nodes.

Doesn't work when the whole site and single main entrance have the address
range.

> Separate the numbers by commas (e.g., 11,13,15) or semicolon (e.g.,
11;13;15).

Again I feel that's skewing what's actually represented on the ground,
which is a single address which is a range and not multiple addresses.

> Specify the range (e.g. 10-95). Note that there is a risk of ambiguity
between two meanings:
> When such a range is officially used for the entire house, this is the
preferred method. In this case 10-95 is simply a label like any other. In
this and other cases, house numbers officially contain a dash and are not
meant to be treated as special.
> When such a range is meant to be interpreted as a list of addresses, use
addr:interpolation=* (described below) to emphasise this. Some mappers will
add a short "virtual" way which allows them to put addresses 10 and 95 on
separate nodes as normal. Some mappers will specify the range 10-95 on a
single object, where the addition of the addr:interpolation=* tag
disambiguates it from the "simply a label" meaning, specifying that it is
indeed to be treated as a range. Both approaches are used in practice and
there is little consensus.
> Note that in some cases building or building complex has single address
such as 3-5 that only looks like a housenumber range. As usual, do not
convert such data blindly, without a verification.

I think this is the best option, since it depends exactly what's happening
on the ground.

I think the only reasonable alternative is to have something like
addr:housenumber:start=1 + addr:housenumber:end=3. Which is clearer that
this is a range and allows data consumers to understand it better.

On Tue, 18 Aug 2020 at 13:34, Paul White  wrote:

> Hello,
>
> I wanted to raise a concern about tagging house numbers on a building
> using a hyphen to denote the address range (e.g 33-55 Main Street). This is
> a bad idea because some areas in the United States and possibly elsewhere
> use hyphenated street numbers for individual dwellings.[1] Data consumers
> see these hyphenated house numbers as one address, as well. Other methods
> documented here
> 
>  work
> better, in my opinion.
>
> I hope to get some input on this issue and the best path forward.
>
> Best, Paul
>
> [1]
> https://en.wikipedia.org/wiki/Queens#Streets
>
> https://en.wikipedia.org/wiki/Fair_Lawn%2C_New_Jersey#Grid-based_address_system
> https://en.wikipedia.org/wiki/Address#United_States
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Have our tagging voting rules changed recently?

2020-08-04 Thread Andrew Harvey
I'd suggest that if you vote no, it will be helpful for the community if
you could elaborate on why you're voting no, without enforcing a reason as
mandatory. Is it because this feature shouldn't be mapped, is it because
there is an alternative tag. So if the vote fails all this feedback can be
taken onboard for a revisal of the proposal and second round of voting.

On Tue, 4 Aug 2020 at 17:59, Frederik Ramm  wrote:

> Hi,
>
> looking at the "bare_soil" proposal I was surprised to read:
>
> "Any opposition vote without reason or suggestion will not be counted in
> the voting process."
>
> Is that something that we have added by consensus?
>
> It sounds like a somewhat sneaky measure to ignore opposition votes, or
> discourage those who cannot properly express their opposition in English
> from voting in the first place. It also raises the question of what
> requirements there are for a "reason or suggestion". If I vote no with a
> reason "it stinks", will there then be someone who says "ah, this is not
> a valid reason" and strips me of my vote? Who will that person be?
>
> Has this been used in other votes in the past? I'm tempted to say it
> would invalidate any vote but maybe it *is* indeed based on consensus
> and I missed that.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

2020-08-01 Thread Andrew Harvey
While you're talking about the destination tag, I think when using a
destination_sign relation it's best to apply the mode as eg.
bicycle=designated, eg
https://www.openstreetmap.org/relation/11345354#map=18/-33.82573/151.21308
 for https://www.mapillary.com/map/im/VIq-OPTiw0BVI7gqdLR-iA

On Fri, 31 Jul 2020 at 23:55, David Marchal via Tagging <
tagging@openstreetmap.org> wrote:

> Hello, there.
>
> I'm wondering, there are destination signs which only apply to some kind
> of vehicles: for HGV, for bicycles, for pedestrians, for vehicles below
> 12t… How would I tag such destinations? The simple way would be to use,
> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*,
> destination:conditional="* @ weight<12". Am I right to assume these?
>
> If so, some examples:
>
>- in this example (
>https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), the road
>ahead would be tagged (regardless of direction),
>destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and
>destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare
>S.N.C.F.;Gare"
>- in this example (
>https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), the link
>would be tagged destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel du Mᵗ
>Blanc"
>- in this example (
>https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), the road
>exiting the turnaround would be tagged
>destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles"
>and
>
> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>sud;Zones industrielles) @ weight>3.5 AND hgv"
>- in this example (
>https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), the road
>exiting the turnaround would be tagged destination="La Voivre",
>destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>
> Is that correct? Can I edit the Wiki destination tag page to give these
> informations, or maybe should I submit a RFC to formalize this?
>
> Awaiting your answers,
>
> Regards.
> --
> Sent with ProtonMail  Secure Email.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-29 Thread Andrew Harvey
On Mon, 29 Jun 2020 at 22:21, Paul Allen  wrote:

> Why cuisine=* rather than drink:*=yes for chocolate drinks?  I consider
> cuisine
> to apply to food, not beverages.  Soup and ice cream are edge cases, but
> chocolate
> drinks don't count as food as far as I'm concerned.
>

Sorry I wasn't aware of https://wiki.openstreetmap.org/wiki/Key:drink, that
makes a lot of sense.

As an aside, it might make sense then to use drink:*= as the kind of drink
(chocolate) and cuisine=* to refer to the style/way it is prepared.

So a place that does the thick and rich italian hot chocolate would be
amenity=cafe + cusine=italian + drink:chocolate=designated (designated
means it's actually signposted as a chocolate cafe rather than just
happening to have chocolate on the menu but not the main item).

A place that does japanese style matcha drinks would be amenity=cafe +
cuisine=japanese + drink:matcha=designated.

On Mon, 29 Jun 2020 at 22:45, Martin Koppenhoefer 
wrote:

> what I wrote was that I believe subtagging is an option, but that it will
> / should not be a subtag for a (yet to introduce according to you) tag
> shop=drinks
>
> We will not get main tags for purple yoghurt or fruit tea, because there
> aren’t such places (at least I have never heard of places specializing in
> these, unlike bubble tea, which apparently is a thing).
>

Rice yoghurt ->
https://www.sbs.com.au/food/article/2020/02/06/are-rice-yoghurt-drinks-new-drink-craze

Fruit Tea -> https://yifangfruitt.com/

Only just scratching the surface with all the local variations of drinks
around the world.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-29 Thread Andrew Harvey
On Mon, 29 Jun 2020 at 21:17, Martin Koppenhoefer 
wrote:

> > On 29. Jun 2020, at 12:18, Andrew Harvey 
> wrote:
> >
> > I think it's better to have some kind of high level tag like
> amenity=drinks or shop=drinks which you order at a counter (as opposed to
> shop=beverages which is more a shop that has pre-made bottled drinks which
> you walk around and add to your shopping basket).
> >
> > The "bubble_tea" part should be left as the cuisine.
>
>
> I don’t believe it is helpful to cluster all kind of places where you can
> primarily find something to drink in a generic tag. Bubble tea is very
> specific, and unless you want bubble tea you would not want to find these
> when you are thirsty. We already do distinguish places to drink with
> various tags like bar, cafe, pub, and it does not seem likely that we will
> deprecate these, so a amenity=drinks or shop=drinks would not promise more
> consistency or ease of tagging. We also already have shop=wine,
> shop=beverages and more. I would make bubble_tea a first level tag
> (or maybe a subtag for pastry/sweets etc.)
>

So we have a first level tag for fruit_tea, purple_yogurt, milk_tea,
bubble_tea, fresh_squeezed_juice, blended_juice, milkshake, smoothie? It's
too long tail and breaks down when you have a shop that sells a mixture of
those instead of just one, a single primary tag for all of these is better.

The same way we just have amenity=restaurant and don't have
amenity=pizza_restaurant etc.

The same way a place that mostly does chocolate drinks that you sit down at
and also does desserts is amenity=cafe + cuisine=chocolate, even if there
is no coffee sold.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-29 Thread Andrew Harvey
The way I see it these are essentially vendors which primarily sell made to
order drinks and mostly take away only (although some provide seating).

I think it's better to have some kind of high level tag like amenity=drinks
or shop=drinks which you order at a counter (as opposed to shop=beverages
which is more a shop that has pre-made bottled drinks which you walk around
and add to your shopping basket).

The "bubble_tea" part should be left as the cuisine. This then caters for
the longtail of specific types of drinks which makes it much easier for
data consumers. It makes it easier when these places make a few different
kinds of drinks and not just bubble tea. Just around me there are the
traditional taiwainese bubble tea places, purple yogourt, other yogourt
drinks, fruit tea, blended juice. So a shop=drinks would cover them all
without needing a special top level tag for each, and you would add all the
specific types of drinks as cuisine (and possibly add cusine=taiwanese as
well).

While I've been tagging these as amenity=cafe and name-suggestion-index has
them as cafe, that's more just because we don't have a better tag and agree
that they aren't what at least I'd consider a cafe (which is more sit down,
possibly with cake or meals).

Existing tags like takeaway=only, indoor_seating=yes/no/bar_table,
outdoor_seating=yes/no should be used to add further information.

On Sat, 27 Jun 2020 at 01:31, 德泉 談 via Tagging 
wrote:

> I've drafted a new proposal about the bubble tea shops which are very
> common in Taiwan which are usually mismapped as shop=beverages
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/shop%3Dbubble_tea
>
> Please visit and comment for this proposal, thanks.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Path or track with many fallen trees

2020-06-25 Thread Andrew Harvey
It's a tricky one, but whatever is done I would need re-checking frequently
to know when it was cleared.

You could just add a single barrier=log somewhere as a rough approximation,
or add barrier=log to the way segment which is affected.
https://wiki.openstreetmap.org/wiki/Tag:barrier=log says it should only be
used on a node, but if you don't know exactly where then I'd say using it
on the way would be fine.

You could also consider using one of the stages of decay lifecycle prefix
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix#Stages_of_decay eg
disused:highway=track, where disused is "Not currently available for use,
but could be reinstated easily".

For a path my rule of thumb is sac_scale=demandig_mountain_hiking means you
need to use your hands and arms to get over something, so if that's the
case because of logs, then I'd tag it that way.

Lastly you can add a description so users could be presented with a text
notice about the way http://wiki.openstreetmap.org/wiki/Key:description

On Fri, 26 Jun 2020 at 09:46, Mike Thompson  wrote:

> Hello,
>
> How would you recommend tagging a path or track that has many fallen trees
> across it? There are too many to map each one with a node tagged
> barrier=log.  Foot travel is legal, but physically difficult.  Horse and
> bicycle travel are legal but probably physically impossible.  Motorized
> travel is prohibited, and would probably be physically impossible anyway.
>
> Thanks in advance for your input.
>
> Mike
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How are protected_area (and national_park) boundaries determined?

2020-06-23 Thread Andrew Harvey
Here in Australia they started off as rough areas based on local knowledge
and signage on the ground but now have mostly been replaced with imported
open data from the government.These legally declared boundaries are usually
declared based on parcels from the cadastre and so the open data usually
matches up with the cadastral polygons. A lot of these boundaries came from
CAPAD data https://www.environment.gov.au/land/nrs/science/capad which is a
federal level database which collates a lot of the federal and state based
protected areas in Australia.

If the parcel is privately owned it'll usually be excluded from the
national park, eg
https://www.openstreetmap.org/#map=19/-33.79587/151.15666 where
you can see houses sandwiched between national park boundaries.

It even goes so far to exclude some road corridors which aren't legally
part of the national park, even though most people would consider
themselves to be in the national park when driving through. As can be seen
at https://www.openstreetmap.org/#map=17/-34.15149/151.03035 these road
corridors don't even align with where the actual road was built, but that
could be an error in the cadastre data, anyway this is all beside the point.

On Wed, 24 Jun 2020 at 01:20, Joseph Eisenberg 
wrote:

> On the Talk-US mailing list, other mappers from the USA have been
> discussing how National Forest boundaries should be mapped.
>
> There is now generally consensus that these should be tagged
> boundary=protected_area + protect_class=6 but there are 2 possible lines to
> follow:
>
> 1) The boundary declared by Congress (the legislature), which includes
> large areas of private land and whole towns in many cases
>
> 2) The actual land owned by the Federal Government of the United States
> within that declared boundary.
>
> The argument in favor of the second is that the privately-owned land
> within the boundary has no actual protection against development. For
> example, I lived in a village which was within the declared boundaries of
> the Klamath National Forest, but the development rules were determined by
> the County government and they were mostly the same as if we were not in
> the boundary (I think?)
>
> In other countries, how are National Park and other protected_area
> boundaries determined? If there are villages or towns within the boundary,
> are they actually protected? Are they excluded from the area?
>
> – Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-09 Thread Andrew Harvey
If the way is used by "law enforcement, emergency, and maintenance staff"
motor vehicles then I'd tag it highway=track and if it's designated for
walking then foot=designated + motor_vehicle=private, since it's wide
enough and occasionally used by vehicles, even for a path that is mostly
used for walking. If you tag it as highway=path then you'd need to still
indicate it's usable by motor vehicle with motor_vehicles=private (though
that's only the legal use, not sure how you'd then tag the physical ability
for it to accommodate motor vehicles).



On Wed, 10 Jun 2020 at 00:32, Mike Thompson  wrote:

> I know we have had this discussion before, but perhaps some of you that
> are more elegant (and diplomatic) can comment on:
> https://www.openstreetmap.org/changeset/85034574
>
>
> These ways exist only to provide recreation to those on foot, bicycle or
> horseback.  One will occasionally see a park maintenance vehicle, such as a
> side by side ATV (I don't think one could even get a regular four wheeled
> vehicle back there.), but the public is not allowed to operate motor
> vehicles on these ways.
>
> Mike
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Highway mistagging ... again

2020-05-29 Thread Andrew Harvey
I think the wiki already does a good job at communicating this.

iD already goes a step too far calling these "unmaintained track roads" but
if anything that would have prevented people tagging as highway=track just
because it is maintained, so not a factor in this case.

I think the default renderer does play a role with some people might be
tagging for the renderer, but nothing can be done about that from the
tagging perspective.

I see someone has left a changeset comment, that's the right thing to do,
it gives the person who made this change a chance to come back either a
counter point on why they really should be highway=track, or a chance for
them to learn about their mistake and improve so they don't make it again.
If you don't hear back from the comment, you could just go ahead and fix
them back to residential if that's how you know they should be.

On Sat, 30 May 2020 at 08:12, Mike Thompson  wrote:

> I know we just had a similar discussion, but I am discovering more and
> more cases where mappers have changed every dirt road they can find to
> "highway=track".  For example, it looks like all of the dirt roads in the
> area of this way: https://www.openstreetmap.org/way/17051445 have been
> changed to "highway=track", when at least most of them should be
> "highway=residential."  What can be done to better communicate that OSM has
> a functional highway classification system (I did leave a change set
> comment, but I doubt it will do any good)?
>
> Mike
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-27 Thread Andrew Harvey
On Wed, 27 May 2020 at 17:15, Daniel Westergren  wrote:

> Yeah, the main problem is that a path can be anything and everything can
> be a path.
>
> I mostly use JOSM and prefer presets to remember to tag all relevant
> attributes. That means that a combined foot- and cycleway becomes a path...
> In Sweden, 99% of all cycleways are open to pedestrians and there are few
> footways where bicycles are forbidden. Thus, almost everything becomes a
> path
>
> I was even recommended by one of the most experienced Swedish mappers to
> use highway=footway for a natural forest path a couple of weeks ago...
> Which turns the mess the other way, that what really should be a path
> suddenly can be a footway and then we don't even know how to interpret
> footways... unless other tags, like surface etc. are used, which in a lot
> of cases they are not.
>
> For those combined urban foot- and cycleways, probably something like
> highway=footcycleway should have been introduced instead, to reserve path
> for the cases we're discussing here (which basically implies that it's not
> necessarily accessible to everyone, even if smoothness, sac_scale,
> mtb:scale etc. can be used to specify the difficulty/accessibility of the
> path).
>

The way I see it is there are two main views of highway=footway,path in
OSM.

1. Is that footway is urban and path is remote/forest
2. Is that footway is for primary walking paths (including remote/forest
paths) and that path is for non-specified usage or mixed use paths
(including urban paths).

These are conflicting and it does seem that OSM has a mix of both styles.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-26 Thread Andrew Harvey
On Tue, 26 May 2020 at 19:35, Volker Schmidt  wrote:

> We have now been reviving the path discussion in 73 messages, and counting
> ...
> I still feel we are not understanding each other (or is it only me who is
> lost?)
>
To me a highway=path is a concept that is well defined in the wiki, and the
> various types can be described with existing tags.
> A hiking route (sometimes called a hiking trail) is a concept that is
> clearly defined in the wiki.
>

>From what I can tell, the ask is a tag for a specific type of way which the
person needs experience or preparedness before undertaking. But I'm lost
and still not completely understanding what exactly this new tag would
cover exactly and what it wouldn't.

A hiking route relation can go over a mixture of way types including
highway=track, whereas this is about the way itself.

Both are very widely, and successfully used.
> Dictionaries do not agree on whether a path is a type of trail or a trail
> is type of path or whether they are synonyms. And I think this is at the
> base of the discussion.
> I would like to remind us that the British-English language words that we
> use in OSM tags are code words to make life easier, the meaning of the code
> words is defined by the mapping practice and that mapping practice is
> documented in the wiki. The common language meaning of these code words is
> in principle independent of the OSM meaning of the codes, and in that sense
> irrelevant.
>

Exactly the name of any tag in OSM is completely irrelevant, it's as you
say how it's used and documented which matters. The iD editor chooses to
localise and abstract away the actual tag name to what it's known as
locally. The tag value is only meaningful for OSM insiders.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-26 Thread Andrew Harvey
On Tue, 26 May 2020 at 17:28, Arne Johannessen  wrote:

> Kevin Kenny  wrote:
> >
> > I took the liberty of revising the English translation in
> > https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values to something
> > that I hope will be more helpful to English speakers.
>
> Overall, this seems like an improvement to me.
>
> However, I note that the translation on the wiki mentions trail markings
> several times, while the original German SAC text doesn't really mention
> markings at all. Instead, SAC mentions trail visibility several times. In
> OSM terms, the following is roughly true:
>
> T1 ~ trail_visibility=excellent
> T2 ~ trail_visibility=good
> T3 ~ trail_visibility=intermediate
> T4 ~ trail_visibility=bad
> T5 ~ trail_visibility=horrible
> T6 ~ trail_visibility=no
>
> Note that both T1 and trail_visibility=excellent can be achieved without
> any markings whatsoever. I think it would be best to remove the mention of
> trail markings in favour of links to trail_visibility.
>
> Alas, I haven't found a good way to express this on the wiki.
>
> Also, some T4+ trails out there have excellent visibility and some trails
> that are otherwise T1 have horrible or no visibility.
>
> The SAC scale does consider trail visibility. But should sac_scale=*
> consider it as well, and if so, to what extent?
>

I don't think sac_scale should consider trail_visibility. For the most part
I see sac_scale as how technical the path is which is independent of how
technical the trackpath is. You could have a path that is well marked with
guideposts so easy to follow, but might have ropes in place or rungs which
make it quite technical. Similarly you could have an easy non-technical
path that is just not well marked or well trodden so has bad trail
visibility. It's important to be able to tag these two concepts
independently.

So regardless of what the SAC standard says, in OSM the sac_scale has
become the defacto tag for how technical the path is.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-25 Thread Andrew Harvey
On Mon, 25 May 2020 at 19:44, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> Javbw
>
> On May 25, 2020, at 1:28 PM, Andrew Harvey 
> wrote:
>
> We do have that: `sac_scale=hiking`
>
>
> And that is a good example of bad tagging I want to correct.
>
> There are more people walking local wilderness trails with their dog in a
> single day than all “backpackers” on earth in a year. Few-to-none of these
> are “day-hike” or “trekking” routes, yet they are most definitely “trails”.
> I do not need to know the sac scale to tag it as a trail.
>
> And How are those routes “hiking”? There are plenty of trails not meant
> for hiking. Hiking is a leisure pastime. A trail is type of way.
>

But how would you define what a trail is?

Up in this thread Daniel noted some definitions, but I think that needs to
be written up as a proposal for where it would apply.

According to the Cambridge dictionary, a trail is "a path through a
> countryside, mountain, or forest area, often made or used for a particular
> purpose:
> - a forest/mountain trail
> - a walking/snowshoeing/cross-country skiing trail"
> Other dictionaries use "beaten path", "a track made by passage especially
> through a wilderness" or similar.
>
> To me, the main difference is between a beaten path vs a path that has
> been purposely groomed.




I can tag a track without defining it’s tracktype=* it’s a track - _and
> then_ further defined by tracktype=* .
>
> Do I have to know the width to tag a road? Do I need to know the number of
> stairs or the incline of the steps to tag it as steps?
>
> No.
>
> It’s a residential road. Steps. A cycleway. A trail.
>
> The attributes of the way do not define it as that type of way - a named
> tag anyone can use does, including someone who can’t define its sac scale -
> or has no idea what the heck that is.
>
> Trails should Have _never_ been lumped in with path. It was a _horrible_
> decision, like motorways and driveways sharing a main tag because cars use
> both.
>
> At least sub-tagging them to be able to easily separate them _and then_,
> when possible define further characteristics __when possible__ with more
> specific tags, like sac scale.
>

I get your point, and agree, but for highway=footway there is a definition
on the wiki of what that covers, same for cycleway, residential road,
highway=track, etc. we don't just say tag a track as highway=track.

For example around me a "Fire Trail" is tagged as highway=track, and a
"Track" (as in a remote forest/bush walking path) is tagged as
highway=footway/path (probably what you're proposing as "trail". So we need
definitions that can be applied globally regardless of how things are
locally known and across languages.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-24 Thread Andrew Harvey
On Mon, 25 May 2020 at 11:54, Kevin Kenny  wrote:

> On Sun, May 24, 2020 at 8:01 PM John Willis via Tagging
>  wrote:
> > Mapping “where the sidewalk ends” and the trails begin is vital to keep
> people from being routes where grandma could have a heart attack Climbing a
> difficult route or break her leg crossing a stream because we routed her on
> a trail down a ravine rather than on the longer, yet safer sidewalks down
> along the roads or paths through a local park because there is no way to
> say “THIS IS A TRAIL, not a walkway through a playground” in OSM.
>
> We do have that: `sac_scale=hiking`; as I understand it, few trails go
> beyond 'hiking', so that's at least better than nothing. (It still may
> suffer from underestimating the trail, leading city folk to the
> sketchy rock scrambles when they're expecting a nice level dirt path,
> so try to get the scale at least reasonable.)
>
> What we don't have - at all - is the complement: 'THIS IS INDEED A
> PATH'.  When we see 'highway=path', we don't know whether it's indeed
> a path, or a hiking trail where the mapper didn't assign an
> `sac_scale`.  We need a way to assert 'THIS IS A PATH' that doesn't
> depend on the absence of a trolltag.
>
> I can't stress enough that as long as we have the ambiguity, the only
> way to 'fail soft' is to support the assertion 'this is relatively
> safe', because we can deduce nothing from the absence of a 'this is
> dangerous' assertion.
>
> Incomplete information should 'fail soft'.
>
> On Sun, May 24, 2020 at 8:32 PM Andrew Harvey 
> wrote:
>
> > Agreed, the biggest question is how do you define that criteria for what
> is going to be tagged a a hiking trail and not a hiking trail.
> >
> > Eg. if you have a smooth paved track through the rainforest that the
> authorities created for grandparents and strollers, is that a hiking trail
> just because it's in a forest area? What about a stroll through the hills
> of grasslands that have no forest or mountains, is that marked as a hiking
> trail?
>
> No, just being in a forest doesn't make something a trail.  I think
> that it's pretty safe to assume that 'surface=compacted
> smoothness=intermediate wheelchair=yes` with a connection to a highway
> or parking area not strictly a hiking trail, and there are some trails
> near me- even in Wild Forest areas- that are constructed in such a way
> to offer wildland access to persons with disabilities. I'd be happy
> considering those trails on an equal footing with urban paths.
>
> A hiking trail can be an easy trail through the lowlands. (Those are
> rare near me, because the lowlands are mostly either settled and
> subdivided, or else sucking swamp, so the mountains are what is left
> for hiking trails to go.) I already mentioned that sac_scale discounts
> hazards other than mountains (and focused on water, but Graeme can
> surely fill in a number of deadlies that are specific to his
> continent).
>
> A lot of it comes down to, "would you route mobility-impaired people
> or folks with small children in tow down this?"  A wrong decision for
> some ambiguous corner case will be mostly harmless. Not having the
> information for a dangerous trail might be deadly.
>

Yeah right now you can use sac_scale=hiking, but I agree we are lacking a
tag to say this is not considered hiking.


>
> > I think it's too hard to have a reliable criteria for this which can be
> objectively surveyed, it's much easier to tag each attribute individually
> on their own independent scale.
>
> The _reductio ad absurdum_: by the same token, because there is
> controversy in many locales over which highways should be
> `highway=trunk` and which should be `highway=primary`, or which should
> be `highway=service` and which should be `highway=track`, all highways
> should be tagged just `highway=road` and the relevant attributes
> (surface, smoothness, speed limit, number of lanes, ...) should be
> mapped instead. Few if any of us think that would be appropriate. Why
> can cars get a hierarchy of ways, while hikers, equestrians and
> cyclists cannot?
>

If you can come up with a proposal I'd love to see it, of course I want to
see it happen to, but I just can't see what the hierarchy should be. For
roads the hierarchy is based on importance of the road in the road network
(eg is it a major connection between cities or just a road used to access a
drive through car wash). Things like surface, smoothness etc don't affect
the road hierarchy. So how would you decide a hierarchy for hiking trails?
How popular the track is? How well built the track is? How technical is the
track? How physically difficult is the track? How well signposted is the
track? How remote is the track?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-24 Thread Andrew Harvey
On Mon, 25 May 2020 at 00:31, Daniel Westergren  wrote:

> Well said John. When we now have highway=path, we need a subtag.
>
> Question is, on what criteria would we differentiate a trail from another
> "path"? Groomed vs beaten may not be specific enough. But by using some
> combination of dictionary definitions of trail, in the sense of path, could
> we come up with some verifiable criteria for when such a subtag should be
> used? What I'm looking for is to differentiate forest and mountain paths
> from urban paths or groomed, smooth paths. When people have been clearing
> forest to make a path more visible and passable, that's still a beaten path
> to me.
>
> And yes, path=trail would probably need to be used for trails tagged as
> footway too, although I personally see footway as an urban path and always
> use path for a trail.
>
> Whatever subtag , we're still stuck with all those cases when highway=path
> is not combined with any other tag (whether it should be path=trail or
> anything else). How would we treat those? Obviously we can't take it for
> granted that those cases should have path=trail.
>
>
>1. Can we agree on whether or not we need a subtag like path=trail?
>Since it's probably too late for highway=trail, which by all means would
>have been the best option.
>2. If we introduce path=trail, what would be the criteria for when it
>should be used?
>3. What about all the cases of highway=path that don't have and will
>not have path=trail? Old or new. Some probably should (like when
>surface=ground), others should never have path=trail. It will still make it
>difficult to render those cases and for data consumers to choose a fallback
>value for those cases.
>4. What about edge cases? It may have been a beaten path that has been
>groomed with better surface material to make it more accessible for
>example. Would it still be considered for path=trail?
>
>
Agreed, the biggest question is how do you define that criteria for what is
going to be tagged a a hiking trail and not a hiking trail.

Eg. if you have a smooth paved track through the rainforest that the
authorities created for grandparents and strollers, is that a hiking trail
just because it's in a forest area? What about a stroll through the hills
of grasslands that have no forest or mountains, is that marked as a hiking
trail?

I think it's too hard to have a reliable criteria for this which can be
objectively surveyed, it's much easier to tag each attribute individually
on their own independent scale.

Anything should work with both highway=footway and highway=path, since one
at the core of the definition on the wiki highway=footway is for primary
walking (which most designated hiking trails are), and highway=path is for
mixed use or unspecified usage paths (which some hiking trails are).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-24 Thread Andrew Harvey
On Sun, 24 May 2020 at 16:29, Daniel Westergren  wrote:

> Great discussion! I think we're discussing two different things here. One
> is about differentiating *trail* (not necessarily hiking trail) from
> other kinds of highway=path and the other is about *difficulty of a
> (hiking) trail* in terms of how technical and demanding it is (and thus
> who can use it and how it will affect walking/hiking/running pace).
>
> I'd like to elaborate on the suggestion *path=trail*, which I think is
> super!!
>
> According to the Cambridge dictionary, a trail is "*a path through a
> countryside, mountain, or forest area, often made or used for a particular
> purpose:*
> *- a forest/mountain trail*
> *- a walking/snowshoeing/cross-country skiing trail*"
>
> Other dictionaries use "*beaten path*", "*a track made by passage
> especially through a wilderness*" or similar.
>
> To me, the main difference is between a *beaten path vs a path that has
> been purposely groomed*.
>
> Could path=trail be used for this distinction? Unlike path=mtb, it would
> not be for trails created for a specific purpose, but any beaten path,
> usually in a forest or mountaineous region.
>

There are a few hiking tracks around mapped as highway=footway, at first I
was "that's wrong", but reading the wiki I couldn't find any fault since
they are designated walking paths.

What are you ultimately trying to distinguish from highway=path?

A very high percentage of the trails near me are all "groomed", they do
this to prevent erosion and track degradation, so while that could be an
indicator for how built up a track is it's not at all an indicator of a
hiking trail.

"Tracktype is a measure of how well-maintained a track or other minor road
is," https://wiki.openstreetmap.org/wiki/Key:tracktype is basically how
"groomed" a track/road is, are you looking for something similar for paths?


>  Regarding *trail difficulty*, I agree that sac_scale is more for
> different levels of alpinism (and not really relevant for non-mountain
> trails) and that other measures are needed to separate everything that on
> the SAC scale would simply be hiking.
>

> One challenge here is about verifiability. Another is about basing such a
> tag on a scale that is only used in a small part of the world. For people
> in the Alps it may be easy to use the SAC scale, because they walk on
> trails where it's used IRL. Similar with the other suggested scales (what's
> "bush" for someone outside of Australia?).
>

"bush" in Australia is what you'd probably call "woods" or "forest", so
bushwalking (AU) = hiking = tarmping (NZ) = backpacking, etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-23 Thread Andrew Harvey
On Sat, 23 May 2020 at 15:53, Tomas Straupis 
wrote:

> 2020-05-23, št, 04:51 Jarek Piórkowski rašė:
> > See also: not rendering roads or hamlets in very sparsely populated
> > areas because we have one map style which needs to accommodate central
> > European densities.
>
>   OSM-Carto is a very well done DATA VISUALISATION. It is not a
> cartography. What you're asking cannot be done with only tagging as
> you will have ways which look exactly the same but will have to be
> removed in one place and will remain in the map in another place. What
> you're asking is accomplished in CARTOGRAPHY by "road network
> pruning". It checks density/class of roads and removes minor ones at
> the places of high density. It is one of cartographic generalisation
> functions. All important generalisation functions take additional
> heavy pre-processing and that is probably a reason why OpenStreetMap
> does not have any Cartography projects yet.
>

 The fact that most maps would look bare until you zoom in was the primary
motivation for me creating my BeyondTracks Bushwalking Map (
beyondtracks.com/map). I show highway=path from zoom 5.

I wrote up some of the technical details at
https://tech.beyondtracks.com/posts/designing-an-australian-bushwalking-map/
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-23 Thread Andrew Harvey
On Sun, 24 May 2020 at 07:42, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

> =path is such a horrible catch-all tag and one that is extremely
> entrenched - I am surprised no one has implemented a path=trail subtag,
> similar to sidewalk, so we can separate all the hiking trails and other
> “hiking” paths, and then apply different hiking limitations you wouldn’t
> expect to find on a sidewalk or playground way.
>

Right now you can use
sac_scale=hiking,mountain_hiking,demanding_mountain_hiking to indicate if a
path is a hiking trail. Though you can't really currently say something is
not a hiking trail.

On Sun, 24 May 2020 at 10:01, Kevin Kenny  wrote:

> On Sat, May 23, 2020 at 5:42 PM John Willis via Tagging
>  wrote:
> >
> > =path is such a horrible catch-all tag and one that is extremely
> entrenched - I am surprised no one has implemented a path=trail subtag,
> similar to sidewalk, so we can separate all the hiking trails and other
> “hiking” paths, and then apply different hiking limitations you wouldn’t
> expect to find on a sidewalk or playground way.
> >
> > Mixing trails and sidewalks in the path key is as horrible as mixing up
> runways and train tracks in a “highway=not_car” way.
>
> Yeah. But it's so entrenched that trolltags are probably the only way
> out of the mess. And sac_scale is _surely_ not the right trolltag! The
> problem with sac_scale is that it's an impossible scale. I'm told that
> https://youtu.be/VKsD1qBpVYc?t=533 is still only a 2 out of 6 on that
> scale, and that https://www.youtube.com/watch?v=3y5_lbQZJwQ is still
> only a 3. Note that one misstep on either of those trails can easily
> mean death.
>

 https://youtu.be/VKsD1qBpVYc?t=533 I would tag
as sac_scale=demanding_mountain_hiking, my rule of thumb is anything where
the average person would need to use their hands to get over an obstacle
is demanding_mountain_hiking. This is what the wiki says too "exposed sites
may be secured with ropes or chains, possible need to use hands for
balance".

Anything that doesn't need hands, but has a fall hazard/is exposed would be
sac_scale=mountain_hiking (assuming it's not alpine).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Andrew Harvey
On Fri, 22 May 2020 at 22:33, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 22, 2020, 13:55 by andrew.harv...@gmail.com:
>
>
>
> On Fri, 22 May 2020 at 21:44, Daniel Westergren  wrote:
>
> Yeah, I guess there's no way to force the user to add a surface tag when
> adding a highway=path. We could also use analyzing tools to look for recent
> edits with only highway=path and comment to users about the use of surface
> etc.
>
>
> I think that's a step too far, while it's nice for people to add extra
> attributes and we should try to make it easier for mappers to discover what
> tags there are and use them, there is no obligation to, the same way a
> building=yes on a node is much appreciated even if it's not traced out in a
> way and has the building type mapped, a lone highway=path is still useful
> alone.
>
> Improving editors would be a better step, such extreme nagging is more
> likely to discourage people.
>

Agreed, though I think the biggest driver for the casual mapper would be to
close the feedback loop so they can actually see this change. ie. making
the default OSM style render width and surface.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Andrew Harvey
On Fri, 22 May 2020 at 21:44, Daniel Westergren  wrote:

> Yeah, I guess there's no way to force the user to add a surface tag when
> adding a highway=path. We could also use analyzing tools to look for recent
> edits with only highway=path and comment to users about the use of surface
> etc.
>

I think that's a step too far, while it's nice for people to add extra
attributes and we should try to make it easier for mappers to discover what
tags there are and use them, there is no obligation to, the same way a
building=yes on a node is much appreciated even if it's not traced out in a
way and has the building type mapped, a lone highway=path is still useful
alone.


> And yeah, the MTB preset bundle for JOSM has one preset for singletrack
> (width=0.5m) and one for doubletrack (width=2.5m), although the latter is
> highway=track. I suppose there's no need to be more detailed than within
> 0.5m in either case. But I'm still interested in the general principle of
> looking only on the treaded path on the ground or the "space" available for
> the path more generally.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Andrew Harvey
On Fri, 22 May 2020 at 20:54, Daniel Westergren  wrote:

> Ok, so I realize there will not really be any other way to distinguish an
> urban, paved path from a small forest path, other than by other attributes
> than highway=path itself. Path=mtb is nice for paths specifically created
> for MTB and nothing else. But I don't see an easily verifiable way of doing
> the same for other forest/mountain/meadow paths.
>
> So we're stuck with other attributes, which mappers should be encouraged
> to always use together with highway=path. Like there should never be a
> highway=path without a surface tag. Currently only 21% of highway=path has
> a surface tag, which contributes to the problem we're discussing.
>

iD puts surface right up there below the name, the third one in iD is
width, and there are presets for sac_scale, trail_visibility and other
tags. So I think iD is doing a good job encouraging people to add these
tags.

As far as I know StreetComplete asks for surface, but if you'd like to see
these other tags used more one way is proposing these for StreetComplete.

In JOSM there are map paint styles for surface and probably other
attributes too.


> Then there is width, which is only tagged on 3.5% of highway=path. I was
> discussing width of paths in another forum. For a forest path, would you
> say width is measured as the actual tread on the ground only? For a runner
> and MTB cyclist that would make sense, but for a hiker with a big backpack
> a width of 0.3 m may mean they think it's not possible to walk there.
>

For a paved path, it's usually very clear what to measure for the width, so
for forest paths I normally think of width in terms of wide enough for
single file or for 2+ abreast.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-05-21 Thread Andrew Harvey
On Thu, 21 May 2020 at 22:49, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 21, 2020, 14:17 by kevin.b.ke...@gmail.com:
>
> It's still tricky. Around here, few trails are actually signposted;
> some don't have a sign anywhere! They're marked with paint blazes in
> the woods, guideposts in the fields, and cairns above the tree line.
>
> Not a native speaker, but I thought that paint blazes,
> guideposts, cairns, signs, surface markings, special traffic signs,
> information boards, markings by cutting on trees, ribbons,
> wooden poles etc all may be used to signpost a trail.
>
> Is "signposted" referring to only some specific methods of marking
> a trail?
>

To me all those things tell me that someone else uses this track for
walking and I'm not too lost and reassures that I'm not just bush bashing
or following an animal trail.

Critically those things say there is a trail here, but don't say where the
trail goes as part of a route, so in that case without knowing the exact
route, I don't see how it can be marked out as a recreational route.

Though there was another thread recently about what constituents a route vs
just a named path..
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-21 Thread Andrew Harvey
On Thu, 21 May 2020 at 17:25, Daniel Westergren  wrote:

> Expanding on the discussion about attributes for trails. What's the
> current status of the highway=path mess? OSM is increasingly becoming more
> useful for forest trails than for car roads (for which other sources are
> usually more up-to-date, to be honest). But the default rendering doesn't
> differentiate between a forest or mountain path and a paved, combined foot-
> and cycleway in an urban environment.
>

There are plenty of apps/maps out there which do differentiate this, so
that's not a tagging issue.


> Obviously we're not tagging for the renderer and the default OSM rendering
> is discussed elsewhere. But has there been any fruitful discussing on this
> topic that will help users to tag these clearly extremely different kinds
> of "paths" in a way that make them more useful for data consumers, as well
> as easier to differentiate for renderers?
>
> Sure, tags like surface, width, trail_visibility can be used. But in most
> cases, highway=path is used with no additional tag. The JOSM presets for
> foot- and cycleways use foot|bicycle=designated, but that doesn't
> necessarily tell anything about the surface or size of the path, or even
> its importance in terms of usage by pedestrians, hikers and cyclists.
>

Those are very useful tags, plus smoothness and sac_scale.

You can also use foot=designated to indicated its signposted for walking or
foot=yes to indicate you are allowed to walk but not signed for walkers.

There are tags for ladders, rungs, ropes which are useful so less able
people can be informed if a trail features these obstacles.

The lifecycle prefix is good for tagging abandoned paths that have
significant regrowth and authorities have closed off and trying to
regenerate.

You're right a highway=path without any other tags covers a wide range of
possibilities, that's why it's great if you can add other tags.


> When highway=path was introduced, forest trails were not widely mapped and
> not the main consideration when introducing the tag as a way to deal with
> cases when footway or cycleway could not be used.
>

The highway value describes what the path was built for, the other tags
mentioned tell you a lot more about the suitability of it.


> I realize this topic has been discussed extensively over the years. But
> now more than ever OSM is becoming increasingly important for hikers, trail
> runners and MTB cyclists for whom a forest or mountain path is something
> completely different to an urban foot- or cycleway.
>

If you have any material suggestions, I'd be very keen to hear.

Disclaimer: I build a website and map for hiking using OSM (
beyondtracks.com/map) data and yes I do take into account sac_scale (path
is red when it's technical), trail visibility (sparser dot when the trail
is less visible), ladders, ropes and rungs.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-05-20 Thread Andrew Harvey
On Thu, 21 May 2020 at 12:35, Warin <61sundow...@gmail.com> wrote:

> The exclusion of the black trail as a possible 'excursion' in the main
> route is a judgment call. I'd be very careful about it.
>
> Why is one excluded where the other is not? Is that is going to be
> difficult to explain in a simple way?
>

It should depend if it's signposted as part of the route or not, since this
tagging only applies to signposted routes. If there is an excursion or
alternative route that isn't signposted as part of the route then it
shouldn't be included in the relation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-05-20 Thread Andrew Harvey
On Thu, 21 May 2020 at 12:31, Warin <61sundow...@gmail.com> wrote:

> Hi,
>
>
> Thanks for doing this!
>
>
> The excursion description is
>
> "A signposted side track which rejoins at roughly the same point where
> it left, usually to visit a point of interest."
>
> That would exclude a track that 'rejoins' at exactly the same point.
>
> Most of the ones I have come across are simple single track that go to
> the 'point of interest' and return is along the same track.
>
>
> Suggest?
>
> "A signposted track which leads to one or more point/s of interests. The
> return maybe along the same track or a different track provided it
> rejoins very close to point where the main track was left. Examples are
> tracks that lead to a view, drinking water, a campsite, a toilet."
>
> More verbose, but there it is.
>

Also discussed at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Recreational_route_relation_roles
where
I suggested not defining it as visiting a point of interest, but rather by
the topology alone. Otherwise people could confuse an alternate route which
visits POIs as an excursion, or not think it's an excursion just because it
doesn't visit a POI.

I read "rejoins at roughly the same point" as including returning at
exactly the same point, ie. meaning anywhere within a rough radius
including the point itself. You could for clarity say "which rejoins at
either the same point or roughly the same point where it left".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

2020-05-13 Thread Andrew Harvey
Agreed with Phake, any boundary that's used for administrative purposes
could be included, that's what I understand from
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative. That
doesn't mean that each area needs to have it's own legal entity and
administrator, nor need to be able to set laws, rules, codes etc. just that
the boundary itself is used for some administrative purposes.

On Thu, 14 May 2020 at 07:29, Joseph Eisenberg 
wrote:

> At the US talk mailing list and
> https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there
> has been discussion about whether or not certain features should be tagged
> as administrative boundaries in the States of Connecticut, Rhode Island and
> Massachusetts.
>
> While all these States have counties, in some cases most of the government
> functions have been lost, and are handled by the State (admin_level=4) or
> Town/City government (admin_level=8).
>
> However, I have the impression that in some countries, certain local
> administrative boundaries do not actually have "home rule", or the ability
> to make their own laws, for example in French-infuenced areas?
>
> What is the minimum qualification for a boundary to be considered a
> boundary=administrative with an admin_level in your country?
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-07 Thread Andrew Harvey
On Thu, 7 May 2020 at 02:05, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Hazard tag seems to be used when there is a sign, so I'm not confident to
> use it for doorzone.
>
> There is two choices :
> 1. describe the layout of the street lanes + cyclelanes + : parking lane +
> sidewalk
> then add the widt of the cycle lane.
> Data consumer can deduce if the lane is dangerous or not
> + objective
> + complete without feature tagged twice
> - harder to compute doorzone state
> - harder to tag (a cyclist willing to tag doorzone has to tag parking
> lanes and width)
>
> example :
> cycleway=lane
> cycleway:width=1m
> parking:lane=parallel
>
> => doorzone
>
> (I could add more tags, for buffer, but I keep simple as possible.)
>
> 2. just tag doorzone feature
> (opposite arguments +/-)
>
> example :
> cycleway=lane
> cycleway:left:doorzone=yes
>
> Before writing this email I was not pro 1., but it's only 2 tags against
> 1, problem is that you must measure the lane and that is little difficult
> (our eyes are bad at that).
> At the end if the two way of tagging is documented for doorzone I'm ok
> with both.
>

I agree there are the two approaches, both can co-exist. I think (1) alone
is a tad too fragile especially since if the cyclelane is a doorzone or not
depends on the buffer and layout, I think it's safer to have a tag like (2)
to specifically say the cyclelane is a doorzone.



On Thu, 7 May 2020 at 15:33, Marc Gemis  wrote:

> but in the end, someone will probably have to add
> parking:lane=parallel as well, not? The second style of mapping
> nothing says nothing about the parking lane. Or does
> cycleway:left:doorzone=yes implies parking:lane:left=parallel?
>

Yes the parking:lane tag should also be added together with the doorzone
tag, I guess you could say it's implied, but it would be a pain for both
data consumers and mappers to rely on this kind of implication, better to
always tag it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-06 Thread Andrew Harvey
On Wed, 6 May 2020 at 22:08, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 6. May 2020, at 13:20, lukas-...@web.de wrote:
> >
> > I agree with that, but then note that for "justice" we would need a
> foot:doorzone=yes, too, because when a sidewalk is in the parking car's
> doorzone (I think most sidewalks next to parking:lane=parallel are), there
> is hazard for pedestrians, too. It might be not soo dangerus because
> pedestrians have much lower speed than cyclists often have, but if we want
> to tag that hazard I think we would have to affect both, foot and bicycle.
>
>
>
> indeed there is much fewer risk for pedestrians and I would not tag it.
> Next thing would be to add hazards for roof tiles that may fly from roofs
> in case of storm? Snow sliding from roofs in winter? There may be many
> hazards if you think it through...
> ;-)
>

I agree with Martin here, I don't think "foot:doorzone" is really needed as
the concept only applies to bicycles.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-05 Thread Andrew Harvey
On Tue, 5 May 2020 at 18:45, Marc M.  wrote:

> Le 05.05.20 à 04:56, Andrew Harvey a écrit :
> > cycleway:both:hazard becomes an issue when there are multiple hazards
> > that apply, so "doorzone" should be part of the key not the value.
>
> ; is a common separator
> =value1;value2;value3
> for ex
>
> https://taginfo.openstreetmap.org/tags/hazard=animal_crossing%3Baccident_area


I know this but for this kind of thing I'd much prefer the schema didn't
use ;. ; makes it much harder for data consumers and editors to deal with
and impossible for users to tag yes/no/buffer as values.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-04 Thread Andrew Harvey
On Tue, 5 May 2020 at 02:35, Jan Michel  wrote:

> On 03.05.20 19:16, Volker Schmidt wrote:
> > I would advocate a more generic approach that remains open to other
> > types of hazards (there are many, unfortunately).
> > A generic
> >
> hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever
>
> I agree, but I would rather use
> cycleway:(left|right|both|):hazard
> 'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's
> more like an hazard that is a "feature" of the cycleway. Everybody close
> to the cycleway is part of the hazard (whether active or passive) but
> bicycles in other places of the road are not affected.


On Tue, 5 May 2020 at 04:33, Volker Schmidt  wrote:

> You are right that in case of cycling infrastructure tagged on the road
> (like typically cycling lanes) we need a way to indicate to which part of
> the road it refers, in addition to the type of haxard.
>

Agree with Volker here.

cycleway:both:hazard becomes an issue when there are multiple hazards that
apply, so "doorzone" should be part of the key not the value.

I originally proposed cycleway:lane:doorzone=yes but then since seeing
https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw changed it to
cycleway:doorzone=yes, but based on what Volker has said about indicating
which part of the road it applies to maybe after all:

cycleway:lane:doorzone=yes (both sides of the road have a
doorzone cyclelane) https://www.mapillary.com/map/im/MXuDWHZY_R9UkGcOk0FZUw
cycleway:lane:left:doorzone=yes (left side of the road has a doorzone
cyclelane)
cycleway:lane:right:doorzone=yes

highway=path,footway,cycleway is in a doorzone
bicycle:doorzone=yes (the bicycle lane of the path,footway,cycleway is in a
doorzone) https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw

The third scenario for dooring is just a regular road with no bicycle
infrastructure, but parked cars can still lead to dooring eg
https://www.mapillary.com/map/im/6YlYnuZPdlziwUsF1m7yWA I guess in that
case where there is no bicycle infrastructure the dooring hazard should be
determined by a parking:lane:parallel=* and some kind of parking:lane
buffer tag?

Are there any other scenarios where dooring is a hazard?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
On Mon, 4 May 2020 at 00:30, Hubert87  wrote:

> (Two replies is one)
>
> Am 03.05.2020 um 15:29 schrieb Andrew Harvey:
>
> On Sun, 3 May 2020 at 23:14, Hubert87  wrote:
>
>> I like the idea of using "buffered".
>>
>> "doorzone" to me, is a pretty laoded and subjective.
>>
>
> I don't see it as subjective. If there is parking directly next to the
> bicycle lane and if a parked car opening a door would intersect with the
> marked bicycle lane, then the bicycle lane is within a door zone. Is it the
> term that's the issue or the concept? Judging by the wikipedia page
> https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread
> term globally.
>
> I'm familiar with that term and the concept. However 'doorzone' (to me)
> seems to have negativ implications (=> hazard), due to cyclists being
> doored. (If I remeber corectly, cyclelanes/paths next to parking cars don't
> seem to be a big problem in NL due to the "Dutch Reach", this is similar to
> cyclist being right-hooked as it is inherend of the position of the
> cycleway relativ to the carrigeway)
>
> So, I'd rather see the concept of "doorzone" be an emergend property of
> multiple other tags (buffer, position of cycle lane, ...) derived by data
> users/renderes/routers.
>
While that does sound better, it is also quite complex as you point out
taking into account buffer, buffer distance, position of lanes but also
relative ordering of the traffic, parking and bicycle lane, counterflow
cycle lanes. Because of this a quick and simply "doorzone" tag I think is
useful for mappers who don't want to go into such detail. It also makes it
clear, otherwise there could always be a slight difference between data
contributor expectation and data consumer given the complex evaluation
without a dedicated door zone tag.



On Mon, 4 May 2020 at 00:19, Martin Koppenhoefer 
wrote:

> do you really need the lane component?
> Could be cycleway:doorzone=yes/no
> or with left/right when lanes on both sides exist that have different
> properties.
>

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


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
On Sun, 3 May 2020 at 23:32, Volker Schmidt  wrote:

> Here in Italy we do have both cycle lanes, cycle paths, and foot-cycle
> paths with dooring risk. So far I have not seen any tagging for these, but
> I would welcome a uniform approach for tagging this hazard on any type of
> cycling infrastructure, and it should be a hazard tag. In that context I
> would like to have also a way of tagging the danger of pedestrians crossing
> the cycle path/lane (e.g. cycle lane between roadside parking spaces and
> sidewalk ; another
> example  - both
> show passenger-door hazard)
> I would not put the hazard on the car parking spaces, it needs to go on
> the way the cyclist takes.
>

That example of https://www.openstreetmap.org/way/343935838 is a good one
since it's not a bicycle lane, it's physically separated from the road and
mapped as shared path using a way separate from the road
(bicycle=designated + foot=designated + segregated=yes). So in that case I
do agree that this door zone concept doesn't just apply to on road bicycle
lanes (cycleway=lane). Maybe cycleway:doorzone=yes/no=buffer is better than
cycleway:lane:doorzone then so it can apply to all types of bicycle ways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
I've started sketching this out at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:cycleway:lane:doorzone
but
I think we need more examples of the full range of scenarios as I've only
got two so far.

On Sun, 3 May 2020 at 23:35, Hubert87  wrote:

> Meant to also add a discriptive tag, like
>
> cycleway:right:parking_lane=right/left/both/no/yes
>

You would just use the existing parking:lane:parallel=left/right/both tag
no?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
On Sun, 3 May 2020 at 23:14, Hubert87  wrote:

> I like the idea of using "buffered".
>
> "doorzone" to me, is a pretty laoded and subjective.
>

I don't see it as subjective. If there is parking directly next to the
bicycle lane and if a parked car opening a door would intersect with the
marked bicycle lane, then the bicycle lane is within a door zone. Is it the
term that's the issue or the concept? Judging by the wikipedia page
https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread term
globally.


>
> Maybe something like:
>
> cycleway:right=lane
> cycleway:right:lane=exclusive
> (cycleway:right:buffered=right/left/both/no)
> cycleway:right:buffered:right=yes/no/0.3(m)
>

The problem still exists that this doesn't say if you're at risk of being
doored https://en.wikipedia.org/wiki/Doored (eg no buffer, but also no
parking lane), so a specific tag like cycleway:lane:doorzone=yes/no/buffer
addresses that better in my opinion.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC ele:regional

2020-05-03 Thread Andrew Harvey
I'm all for specifying elevation of mountain peaks etc in other datum which
may work better than WGS:84.

I think it's better to specify which datum the value is in, it'll be a
nightmare over time working out which datum the original mapper intended as
new datums are rolled out and are upgraded, and leaves confusion if there
are multiple datum in use.

ele:=value

Where  is the height datum.

Next question is then how to specify , in Australia we commonly use
https://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/ahdgm/ahd,
so could use ele:ahd but that probably collides with other anachronisms
globally so is not ideal. There is an EPSG code
https://spatialreference.org/ref/epsg/5711/ for the datum, perhaps
ele:epsg:5711= is better then.

I'm not sure if there are any issues legally using EPSG codes, but presume
it's okay.

On Sun, 3 May 2020 at 20:06, Martin Koppenhoefer 
wrote:

> I’m asking for comments on
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
>
> Cheers Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
On Sun, 3 May 2020 at 18:56, Jan Michel  wrote:

> Hi,
> I oppose adding this officially to the top-level cycleway:lane tag.
> I see this information as one more property of the cycleway, like
> surface, smoothness, width and so on.
>
> We already have a documented key 'cycleway:buffer' that is described
> as the width of the buffer space between car lanes and the bicycle lane.
> The 'cycleway:buffer' tag is also used combined with :left and :right to
> denote the buffer on left-hand and right-hand side of the cycleway.
>
> Mappers in Berlin worked on a more detailed tagging of buffer and
> protection of bicycle lanes, see (unfortunately in German only)
> https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege
>
> I'd suggest to get in contact with them and discuss this. I imagine that
> this information could fit very well into the cycleway:buffer tag - A
> door zone is a non-existent buffer, so instead of 'no' one could use
> 'doorzone' as one of the non-numeric values.


I didn't know about cycleway:buffer, it sounds good but I don't think alone
it is enough because:

- It doesn't indicate if cars can be parked next to the cyclelane (as a
doorzone only occurs when there are parked cars). I know we can marked a
parking lane with parking:lane:parallel but I think it's better to have an
explict way to say the cyclelane is in a doorzone.
- Can be hard to measure distances and hence hard to say at what distance
is considered in the door zone or not. In all the examples I know of there
is no buffer so cycleway:buffer:left=no (for left hand side driving) but a
half meter buffer might still be considered within the doorzone.

The current wiki page for cycleway:buffer implies cycleway:buffer is
between the cyclelane and traffic lane, it feels safer to never use
cycleway:buffer and instead always explicitly state cycleway:buffer:left
and cycleway:buffer:right, but it does get complicated with counterflow
cyclelanes.


On Sun, 3 May 2020 at 19:05, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> I think sub properties of a feature should go with this scheme
> mainfeature:subpropertie=values(yes/no/enumeration/absolute values/...)
> This help to respect orthogonality : values of a key should not conflict
>

Agreed


> So yes for :
> cycleway:lane:doorzone=yes/no/buffered
> buffered for the case there is a buffer marked between car park lane and
> cycle lane like this :
> https://cyclingsavvy.org/wp-content/uploads/2018/08/BikeLaneBuffer.jpg
> no means that the cyclelane is wide enough to not be doored (no buffer
> though).
>

That sounds good, except I think cycleway:lane:doorzone=no should mean that
no part of the cyclelane is within the doorzone or there is no car parking
and hence safe from doorzoning. cycleway:lane:doorzone=yes means that any
part of the cyclelane is prone to doorzoning and
cycleway:lane:doorzone=buffered means that there is a buffer to protect
from doorzoning, so while mostly you'll be safe from doorzoning you might
still want to exercise some caution.

I think this then can work in combination with cycleway:buffer:left and
cycleway:buffer:right.


>
> And I'd say yes also for :
> cycleway:lane:exclusive
> cycleway:lane:width
> cycleway:lane:color
> etc.
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
On Sun, 3 May 2020 at 18:17, Martin Koppenhoefer 
wrote:

> I am not completely sure, if I get this right, do you mean the area where
> a door that is opened, would intersect with the space of a cycle lane?
>

Exactly, see also https://en.wikipedia.org/wiki/Dooring. Personally when
riding I use the cycle lane as a buffer between parked cars and just ride
outside of the cycle lane. There's been cases of mappers removing the
cycleway=lane tag saying it's unsafe due to the doorzone, but that's wrong
since there is a cycle lane there, so a dedicated tag would help
alleviate this.


> Maybe this could be tagged as a “hazard”, i.e. a property, rather than
> forming a subtype of cyclelanes?
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>

That's an interesting idea. They key to note is that this is not usually a
signposted hazard rather comes about due to the position of a parallel
parking lane next to the cycle lane.

cycleway:hazard=doorzone could apply. Though there could be other kinds of
hazards which apply as well and it's unclear how that would work. I still
would learn towards cycleway:lane:doorzone=yes as being my preferred option
though, since you can tag =no as well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Doorzone bicycle lanes

2020-05-03 Thread Andrew Harvey
For a while myself and others have been using cycleway:lane=doorzone to say
the bicycle lane is in a doorzone, I've now added documentation of this as
"in use" at https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However
this conflicts with the other "in use" cycleway:lane=exclusive/advisory,
since you can have exclusive/advisory lanes which are doorzone or not.

None of these have gone through a proposal process and both are
independently in use.

Given cycleway:lane=exclusive/advisory have more use than doorzone, I think
we should put cycleway:lane=exclusive/advisory through the formal proposal
process and then change how we map doorzones as cycleway:lane:doorzone=yes
so it can work together with exclusive/advisory.

Any other opinions?

Also on https://wiki.openstreetmap.org/wiki/Key:cycleway:lane there is
cycleway=shared_lane + cycleway:lane=pictogram, should this not be
cycleway:shared_lane=pictogram?

Given https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dshared_lane is
already defined as "Used to identify roads which contain a shared lane
marking, or sharrow, to indicate that the travel lane is shared by bicycles
and other vehicles." what does the =pictogram tag mean and how is it
different to cycleway=shared_lane?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

2020-04-22 Thread Andrew Harvey
On Thu, 23 Apr 2020 at 03:03, brad  wrote:

> I've never seen an official IMBA rating on a sign.
>

I have,
https://wiki.openstreetmap.org/w/images/9/96/Serrata_Mountain_Bike_Track_Board_Map.jpeg


> I see both mtb:scale and mtb:scale:imba both used.   The wiki for
> mtb:scale doesn't make sense.   It's either skewed for extremely extreme
> riding or they don't understand gradient.   It says that for mtb:scale=1,
> gradient<40%.   This is meaningless.   Nobody can ride up an unpaved grade
> that is 40%, or probably even 30%.   A steep trail is 15%.   A really
> steep, almost unrideable, very difficult hiking, trail is 20%.Going
> downhill, anything above 25% is a double black, only a small percentage of
> riders can ride, unless it is very smooth with really good traction.
>

I agree, I find it very hard to set mtb:scale confidently based on the
descriptions on the wiki.

In my opinion, mtb:scale:imba could be deprecated, and the wiki for
> mtb:scale updated & clarified.
>

I would disagree on that, mtb:scale:imba is still useful to mark officially
signposted or designated ratings of the track made according to the IMBA
system, like in the first photo I posted.

I'd be very keen to review any improvements to mtb:scale though, I have
very low confidence in all the ones I've tagged so far as I feel like every
time I read the wiki I have a different opinion
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

2020-04-22 Thread Andrew Harvey
I've been using mtb:scale:imba on any kind of trail where signage at the
site notes an IMBA rating, in this way it's verifiable based on the sign. I
don't know what "bikepark" and "north shore" mean here but while some of
these trails which have an IMBA rating can be consider together as part of
a collection of trails and that collection does have a name sperate to the
individual tracks (which I guess is what bikepark means) others which do
have signposted IMBA ratings are standalone and not part of a named
collection of trails.

So if it has an official or signposted IMBA rating, it should be tagged
regardless of the trail being "natural" or with "artificial obstacles" and
regardless if it's part of a mountain bike "park" or not.

On Wed, 22 Apr 2020 at 17:29, Joseph Eisenberg 
wrote:

> Another user would like to redefine the definition of "Key:mtb:scale:imba"
>
> See suggestions at
> https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:
>
> This tag was approved in the proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale - with
> the description "The IMBA Trail Difficulty Rating System shall be used for
> bikeparks. Especially for North Shore. It is adapted to mtb trails with
> artificial obstacles. For "natural" trails it is advised to use the
> mtb:scale/mtb:uphill:scale." - linked to
> http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html
>
> Can other mappers who use this tag frequently confirm whether it is
> limited to specifically designed and built bike trails, like those found in
> "bikeparks"?
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:path=mtb

2020-04-20 Thread Andrew Harvey
On Tue, 21 Apr 2020 at 03:42, Martin Koppenhoefer 
wrote:

> Did you consider mtb=designated?
>

This was considered and mentioned in the rationale, mtb as a key is better
use as a mode specific access tag, which makes mtb=designated to usually
mean signposted or otherwise indicated for use by mountain bikes, its a
more formal endorsement that the way is for use by that mode.

Sometimes mountain bike tracks are evident as such on the ground due to
track construction and common usage, but have no signage or other
indication that they are for use by mountain bikes so I think
mtb=designated would be a mis-step in that case as it says it's officially
designated which it's not.

Secondly because you might have other highway types like highway=track
which are signposted as for use by mountain bikes you'd have
highway=track + mtb=designated, but it's still a highway=track not a
singletrail mountain bike track.

Are there implications for pedestrians, riders and "other" cyclists?
> Motorbikes? (Question is, are they allowed, not allowed, or maybe allowed
> in absence of explicit specific access tags?)
>

I believe it's always better to explicitly tag the access tags to indicate
who can use the way, so I'd always encourage setting foot= and bicycle=
(mountain bikes are a type of bicycle so usually the legal restriction
applies to any kind of bicycle) Data consumers would need to decide what
defaults they could use if not supplied, that would be their chose, a
mapper shouldn't rely on this default. Personally I'd assume foot=yes,
bicycle=yes, horse=no, motorbike=no as defaults where you only have
highway=path + path=mtb.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - Key:locked

2020-04-19 Thread Andrew Harvey
Voting has opened for the locked tag proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:locked.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-19 Thread Andrew Harvey
I've started a proposal
https://lists.openstreetmap.org/pipermail/tagging/2020-April/052174.html /
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:path%3Dmtb which
aims to take this discussion over to the next stage, if you everyone could
take a look at the new proposal and if discussion could happen on the new
thread I think that will help move this forward.

On Thu, 2 Apr 2020 at 18:56, Phyks  wrote:

> Hi,
>
> A discussion in CyclOSM issue tracker [1] spotted that there exists
> around 3500 highway=cycleway around the world which have specific
> mountain bikes (MTB) tags. In particular, around 800 highway=cycleway
> around the world declare a mtb:scale greater than 2, which would make
> them impassable without a proper mountain bike. Such cycleways would not
> be passable with a regular city bike. One example of such a case is at [2].
>
> Looking at the wiki page [3],
> "the highway=cycleway tag indicates a separate way for the use of cyclists"
> which does not mandate explicitly that a cycleway be accessible with any
> kind of bikes and should also cover dedicated paths for MTB. However,
> the documentation around cycleways and bike features is very oriented
> towards city cycling and there is no illustration about MTB-specific
> cycleways.
>
> So, is this considered a valid tagging or should it be represented by
> another highway class (path, track, etc)? If this is valid, I propose to
> add a statement in the wiki explicitly mentioning that cycleways can be
> restricted for specific kinds of bicycles, for future questions.
>
> Best,
>
> [1] https://github.com/cyclosm/cyclosm-cartocss-style/issues/208
> [2] https://www.openstreetmap.org/way/86978431#map=17/41.26426/-73.91907
> [3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway
>
> --
> Phyks
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - RFC - Tag:path=mtb

2020-04-19 Thread Andrew Harvey
Please see the proposal for highway=path + path=mtb as way to map mountain
bike tracks at
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:path%3Dmtb

This has come about after very extensive discussion on the tagging list at
https://lists.openstreetmap.org/pipermail/tagging/2020-April/051864.html as
a way to formalise the results of that discussion.

I've tried to take in the feedback from the prior discussion and the result
is in my view most suitable way forward.

At the moment I'm looking for feedback and any help with the wording or
examples to the document before taking it to voting
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Andrew Harvey
But on a highway=footway,cycleway,path you can't drive a vehicle, so in
those cases if there is a oneway=yes it's fair to assume it applies to all
modes of transport on that way, unless otherwise indicated. Sure you can
add oneway:foot=yes if you like, but oneway=yes should be interpreted as
the same on a highway=footway.

On Thu, 16 Apr 2020 at 21:14, Paul Allen  wrote:

> On Thu, 16 Apr 2020 at 11:48, Warin <61sundow...@gmail.com> wrote:
>
>>
>> What reason is there for excluding other modes of transport?
>>
>>
> Many ways permit more than one mode of transport.  Does oneway apply
> to all modes?  Does that mean I can only walk in the same direction that
> traffic is permitted on a oneway street?  That's why oneway excludes other
> modes of transport.
>
> --
> Paul
>
> If "oneway" cannot be used then what do you think should be used?
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-15 Thread Andrew Harvey
To sidestep your question, oneway=yes on a highway=footway, cycleway or
path already implies it's not accessible to vehicles so a oneway tag on any
of those highway tags should apply to all modes of transport. So
highway=footway + oneway=yes shouldn't need any other tags like oneway:foot.

On Thu, 16 Apr 2020 at 13:04, Joseph Eisenberg 
wrote:

> Some paths and footways have oneway=yes. Sometimes this means that
> bicycles may only access these features in one direction, but other
> times it has been used for one-way features for pedestrians (for
> example, queues in theme parks or at border control stations).
>
> Other more specific tags have been promoted, since the wiki states
> that oneway=yes is for vehicles.
>
> https://wiki.openstreetmap.org/wiki/Key:oneway:foot is used about 1400
> times
>
> https://wiki.openstreetmap.org/wiki/Key:foot:backward is used about 140
> times
>
> The wiki for Key:oneway was just edited to recommend using
> foot:backward instead of oneway:foot
>
> But as an English speaker, I find it difficult to immediately
> understand the meaning of foot:backward=no (which uses a double
> negative, as it were), while oneway:foot=yes seems clear right away.
>
> Is there really a reason to prefer the less common tag? Does it make
> more sense in other languages?
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-06 Thread Andrew Harvey
On Mon, 6 Apr 2020 at 03:27, Adam Franco  wrote:

> Thank you for putting together this  highway=path + path=mtb suggestion,
> Andrew. This is first suggestion on this thread that has felt like a good
> direction forward. First and foremost, mountain bike trails are paths,
> anything further is a qualifier that adds precision, but not a
> contradiction.
>
> In contrast, proposals to change to leisure=track feel wrong because these
> are routable ways and dropping highway=* removes them from the routable
> network.
>

In theory you could still include leisure=track in your routable network,
but it needs more fine tuning hence less likely "out of the box" and isn't
ideal in my opinion.


> Similarly, fiddling with access tags to imply mountain-biking trails feels
> like adding too much inference and dual-purpose to these tags that then
> complicate the access scheme. In general, I think expanding the path=*
> key would be a good way to add additional precision for other "special
> purpose" paths.
>

> I'm a long-time mountain biker and also a bicycle commuter, so I can
> sympathize with both camps. While my area (Vermont, USA) has some
> special-purpose mountain-bike trails (with ramps and the like) that are
> built at ski areas, most of our trails are built and cut by and for
> mountain bikers, but are also used by trail-runners and walkers. The "built
> for mountain bikers" part means that they have been sculpted to follow the
> terrain in a way that is fun on a mountain bike, with turn radii and grades
> that allow a flowing cadence. Often elevation gains/drops are managed to
> optimize for time coasting downhill, rather than dropping steeper than is
> needed only to have to climb again. These trails are also usually great for
> hiking/running, but also feel great on a bike. In contrast, a trail "built
> for hiking" might not worry about twisting between some large jumbled rocks
> that tires simply can't traverse, or might use steep, straight grades and
> stairs that "waste" elevation gains in a way that is less-fun on wheels.
> Long story short the vast majority of specialized mountain-bike trails
> *are* highway=path, they are just a particular flavor of highway=path.
>
> I would strongly support a formalized proposal based on what you put
> together.
>

Good to hear that feedback In my proposal I'm agnostic to built/maintains
it, and agnostic to if it's officially sanctioned or not, so path=mtb would
be based on how it's built/who it's built for.

On Mon, 6 Apr 2020 at 04:50, Volker Schmidt  wrote:

> It sounds as we have not yet made clear the difference between MTB routes
> and MTB leisure tracks. The former are routes that are suitable for
> mountain bikers, but they are on ways shared with other users, whereas the
> latter are for the exclusive use with MTBs - no other user is admitted.
> That is a similar distinction as between a road and a motor racing track.


A MTB route is just a relation with type=route + route=mtb, usually a
signposted collection of smaller track segments, it could go over other
track types like highway=track and or designated mountain bike trails (as
proposed highway=path + path=mtb).

On Mon, 6 Apr 2020 at 14:16, Jonathon Rossi  wrote:

> On Sun, Apr 5, 2020 at 5:49 PM Andrew Harvey 
> wrote:
>
>> [...]
>>
>
>> bicycle= as an access tag should refer to any class of bicycles by
>> default. Today I was walking a track which had a no bicycles sign, meaning
>> all types of bikes are disallowed. Conversely bicycle=yes just means that
>> bicycles are legally/physically allowed, it does not indicate suitability
>> by a specific type of bicycle. I don't think I've ever seen signage which
>> says no mountain bikes but you can use a road bike, or vice versa. If there
>> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
>> etc. You could have a path which is clearly a mountain bike track but
>> officially bicycles are not allowed. So based on this we can't use these
>> kinds of access tags to define the type of path they must be kept
>> independent.
>>
>
> Agreed, land managers don't define different access by type of bicycle,
> because at the end of the day what is a MTB, I had a MTB without suspension
> when I was a kid so it's not suspension, a MTB is just an advertised
> bicycle with heaps of features which has continued to change heaps in the
> last 15 years with technology, even today the range of features and price
> is amazing; eMTB is another category that is different per region/country
> whether land managers treat them as a bicycle or motorbike based on their
> power output.
>
> In my experience of riders I've met, the trails you can successfully ride

  1   2   3   >