Re: [Tagging] Feature Proposal - RFC - Leisure=Skatepark

[Scott via Tagging]

Great question. I'm not a BMXer, just an aggressive inline skater so I am not a 
definitive authority on BMX culture by any stretch. I thought they were still 
called skate parks given I've seen organizations like Red Bull have referred to 
them as such (https://www.youtube.com/watch?v=8LgM0ralVVM). However looking 
further into this it seems based on the cities of both Houston and Chandler 
where I could easily find them as well as this list of them, they're classified 
'Bike parks':

https://www.houstoniamag.com/articles/2019/8/14/rockstar-energy-bike-park-bmx-park-opens-north-houston
https://www.chandleraz.gov/explore/chandler-parks/guide/espee-park/bike-park
https://www.twowheelingtots.com/kid-friendly-bike-park-pump-track-directory/

I'll update the proposal in the next 15 minutes to remove that BMX only example 
and add a blurb that bike only parks be tagged as leisure=bike_park

-Scott

‐‐‐ Original Message ‐‐‐
On Sunday, December 8, 2019 7:29 PM, Graeme Fitzpatrick  
wrote:

> One question (from a very non-skateboarder!) ...
>
> You've made reference to a "BMX only skatepark".
>
> If it's BMX only, would it still be called a skatepark?
>
> Thanks
>
> Graeme
>
> On Mon, 9 Dec 2019 at 12:14, Scott via Tagging  
> wrote:
>
>> Description: An area designated and equipped for skateboarding, in-line 
>> skating, BMX'ing, or scootering.
>>
>> Proposal for fixing improper definition of sport=skateboarding, creating 
>> skatepark as a result, and other relevant access and equipment tags.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/skatepark
>>
>> Constructive feedback appreciated!
>> ___
>> 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb]

On 12/8/2019 6:44 PM, Peter Elderson wrote:



Could you envision a node passed by two hikes, and being a checkpoint
for the one and nothing special for the other?


Camino de Santiago ( https://www.openstreetmap.org/relation/153968 )
comes to mind. Hikers doing the whole route carry passports that are
stamped at checkpoints along the way, to document completion of the
route. Hikers not attempting to complete the whole route probably
wouldn't have the passport and wouldn't bother with the checkpoints.

And certainly some of the portions of the Camino de Santiago are also
parts of other routes, eg the sub-sub relation
https://www.openstreetmap.org/relation/3523300 is part of the Camino de
Santiago ( via https://www.openstreetmap.org/relation/138227 ), and is
also part of the European long-distance hiking route E3 -- which as far
as I know doesn't feature a checkpoint system.

Jason


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

Re: [Tagging] Feature Proposal - RFC - Leisure=Skatepark

[Graeme Fitzpatrick]

One question (from a *very* non-skateboarder!) ...

You've made reference to a "BMX only skatepark".

If it's BMX only, would it still be called a skatepark?

Thanks

Graeme


On Mon, 9 Dec 2019 at 12:14, Scott via Tagging 
wrote:

> Description: An area designated and equipped for skateboarding, in-line
> skating, BMX'ing, or scootering.
>
> Proposal for fixing improper definition of sport=skateboarding, creating
> skatepark as a result, and other relevant access and equipment tags.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/skatepark
>
>
>
> Constructive feedback appreciated!
> ___
> 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 - Leisure=Skatepark

[Scott via Tagging]

Description: An area designated and equipped for skateboarding, in-line 
skating, BMX'ing, or scootering.

Proposal for fixing improper definition of sport=skateboarding, creating 
skatepark as a result, and other relevant access and equipment tags.

https://wiki.openstreetmap.org/wiki/Proposed_features/skatepark

Constructive feedback appreciated!___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature proposal - Voting - Telecom distribution point

[François Lacombe]

Hi all,

Following 7 months of RFC and apparently no problem to tag telecom
distribution points, the vote is now open.
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

These are really (certainly too) tiny boxes with telecom network references
on them that I propose to map with telecom=distribution_point according to
IEC 722-12-19 definition.

Keep in mind this vote won't force anyone to map distribution points.
Question asked is to know if telecom=distribution_point is the most
appropriate key for that.
References can be taken as landmarks just like address numbers in your
neighborhood.

Thanks in advance for your time on this vote, all the best.

François
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

I have some doubts about the need to link the feature to the relation. The
node is already in or possibly very near the route, and the feature could
be tagged, displayed and routed as a type of POI.

But, if entered into a route relation, role checkpoint sounds ok to me.
Then it could be displayed with an icon even if not tagged.

Fr gr Peter Elderson


Op ma 9 dec. 2019 om 01:11 schreef Warin <61sundow...@gmail.com>:

> On 09/12/19 10:44, Peter Elderson wrote:
>
> Ok, just asking to make sure.
>
>
> As an overview most hiking things are on
> https://wiki.openstreetmap.org/wiki/Hiking
>
>
> Could you envision a node passed by two hikes, and being a checkpoint for
> the one and nothing special for the other?
>
>
> Yes.
>
>
> Would a checkpoint need to be a node of a way in the relation?
>
>
> If it only relates only to that relation then quite possibly.
>
> If it is a required activity for that route then I would think so. This
> would link it to the operator, route name etc, possibly minimising the work
> of mappers and reducing errors?
>
>
> Vr gr Peter Elderson
>
>
> Op ma 9 dec. 2019 om 00:16 schreef Kevin Kenny :
>
>> On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson 
>> wrote:
>> > Is a checkpoint a feature in itself?
>>
>> Of  course it is. A way segment is also a feature in itself, which
>> doesn't mean that it can't or shouldn't be part of a route relation:
>> "When you're hiking this route, you'll need to sign in at these
>> points."
>
>
> https://wiki.openstreetmap.org/wiki/Key:checkpoint
> ___
> 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

On 09/12/19 11:07, Kevin Kenny wrote:

On Sun, Dec 8, 2019 at 6:45 PM Peter Elderson  wrote:

Ok, just asking to make sure.

Could you envision a node passed by two hikes, and being a checkpoint for the 
one and nothing special for the other?

Certainly, for the sort of checkpoint that's to show that a hiker
actually took the route, it's quite imaginable. There's a register on
the median (not mapped, and I haven't been down that way in a couple
of years to attend to it) at the motorway crossing on
https://www.openstreetmap.org/way/369195402 and a sign politely
requesting that Appalachian Trail hikers sign in. The sign says
nothing about the Ramapo-Dunderberg Trail, which shares the treadway
at that point. (I sign in anyway.)

For the mandatory checkpoints that I discussed in an earlier post,
pretty much any route that passes the checkpoint is a "must check in".


For the 'Overland Track' signing in is mandatory for through hikers, day 
trippers don't have to and most of these don't.



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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

On 09/12/19 10:44, Peter Elderson wrote:

Ok, just asking to make sure.


As an overview most hiking things are on 
https://wiki.openstreetmap.org/wiki/Hiking


Could you envision a node passed by two hikes, and being a checkpoint 
for the one and nothing special for the other?


Yes.


Would a checkpoint need to be a node of a way in the relation?


If it only relates only to that relation then quite possibly.

If it is a required activity for that route then I would think so. This 
would link it to the operator, route name etc, possibly minimising the 
work of mappers and reducing errors?




Vr gr Peter Elderson


Op ma 9 dec. 2019 om 00:16 schreef Kevin Kenny 
mailto:kevin.b.ke...@gmail.com>>:


On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson mailto:pelder...@gmail.com>> wrote:
> Is a checkpoint a feature in itself?

Of  course it is. A way segment is also a feature in itself, which
doesn't mean that it can't or shouldn't be part of a route relation:
"When you're hiking this route, you'll need to sign in at these
points."



https://wiki.openstreetmap.org/wiki/Key:checkpoint
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Kevin Kenny]

On Sun, Dec 8, 2019 at 6:45 PM Peter Elderson  wrote:
>
> Ok, just asking to make sure.
>
> Could you envision a node passed by two hikes, and being a checkpoint for the 
> one and nothing special for the other?

Certainly, for the sort of checkpoint that's to show that a hiker
actually took the route, it's quite imaginable. There's a register on
the median (not mapped, and I haven't been down that way in a couple
of years to attend to it) at the motorway crossing on
https://www.openstreetmap.org/way/369195402 and a sign politely
requesting that Appalachian Trail hikers sign in. The sign says
nothing about the Ramapo-Dunderberg Trail, which shares the treadway
at that point. (I sign in anyway.)

For the mandatory checkpoints that I discussed in an earlier post,
pretty much any route that passes the checkpoint is a "must check in".

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

I am now convinced it is useful to have a oneway=yes tag for a route
indicating it's not allowed or possible to go the other way.
As for routers, I would still expect a router to check all the ways and
nodes for access.

Fr gr Peter Elderson


Op ma 9 dec. 2019 om 00:36 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 7. Dec 2019, at 16:49, Mateusz Konieczny 
> wrote:
> >
> > Only-exit ways in zoos, Orla Perć hiking trail,
> > some tourism routes in castles, mines etc
>
>
> don’t know for the hiking trail, but the other cases are not what I would
> see as “legal prescriptions”, it’s what the operator has decided.
>
> Cheers Martin
> ___
> 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] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

sent from a phone

> On 8. Dec 2019, at 16:13, Volker Schmidt  wrote:
> 
> : (Unilever-owned) GROM produce their ice cream concentrate in a factory and 
> then convert that stuff locally into ice-cream for which people queue.("Un 
> gelato come una volta").
> Is that industrial or "artigianale" ?


industrial 

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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

Ok, just asking to make sure.

Could you envision a node passed by two hikes, and being a checkpoint for
the one and nothing special for the other?

Would a checkpoint need to be a node of a way in the relation?

Vr gr Peter Elderson


Op ma 9 dec. 2019 om 00:16 schreef Kevin Kenny :

> On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson  wrote:
> > Is a checkpoint a feature in itself?
>
> Of  course it is. A way segment is also a feature in itself, which
> doesn't mean that it can't or shouldn't be part of a route relation:
> "When you're hiking this route, you'll need to sign in at these
> points."
>
> ___
> 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 - hiking_trail_relation_roles

[Martin Koppenhoefer]

sent from a phone

> On 7. Dec 2019, at 16:49, Mateusz Konieczny  wrote:
> 
> Only-exit ways in zoos, Orla Perć hiking trail,
> some tourism routes in castles, mines etc


don’t know for the hiking trail, but the other cases are not what I would see 
as “legal prescriptions”, it’s what the operator has decided.

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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Kevin Kenny]

On Sun, Dec 8, 2019 at 6:10 PM Peter Elderson  wrote:
> Is a checkpoint a feature in itself?

Of  course it is. A way segment is also a feature in itself, which
doesn't mean that it can't or shouldn't be part of a route relation:
"When you're hiking this route, you'll need to sign in at these
points."

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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Martin Scholtes]

Am 08.12.2019 um 05:04 schrieb Alessandro Sarretta:
>
> Hi Martin,
>
> my doubt on your proposal is that I think the only useful value would
> be "designated" (anyway, can you share any example/picture of a sign
> describing a park specificly designated for carpooling?). But in this
> case I'd support
>
you can have a look at a sign for such a parking lot which is explicitly
built and maintained for carpooling under the following link:
https://mitfahren.rlp.de/fileadmin/_processed_/2/3/csm_Mitfahrerparkplatz_LBM_3_2_b8add83c7b.jpg

> As far as I know, in a general-use parking (without specific access
> conditions) anyone can park, meet with a friend, and then continue the
> journey with only one car... What is the purpose to explicitly add
> this information?
>
Parking spaces that have been explicitly created for car pools are built
and maintained by the state. Furthermore, this type of car park does not
exist everywhere, mostly only at points where many commuters meet. It
makes the search easier. Because at the moment such objects can only be
found by a possible name, for example "Mitfahrerparkplatz".


Martin




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

Is a checkpoint a feature in itself?

Fr gr Peter Elderson


Op zo 8 dec. 2019 om 23:48 schreef Kevin Kenny :

> On Sat, Dec 7, 2019 at 12:29 PM Jmapb  wrote:
> > On 12/7/2019 11:52 AM, s8evq wrote:
> > > In my limited experience mapping hiking routes, I have not yet come
> across any real use for nodes in hiking relations, but I'm curious if other
> people have good uses.
> > > As far as I know, there is also not much documented in the wiki on the
> topic of nodes in hiking/cycling relations.
> > Possibly for checkpoints?
>
> Good idea. In at least some places where I travel, there are
> _mandatory_ checkpoints: “No person shall fail to register whenever
> passing a trail register established by the department in the Eastern
> High Peaks Zone.” (N.Y. Comp. Codes R. & Regs. tit. 6 § 190.13(f)(1)
> https://tinyurl.com/sdqfl2d)
> --
> 73 de ke9tv/2, Kevin
>
> ___
> 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Kevin Kenny]

On Sat, Dec 7, 2019 at 12:29 PM Jmapb  wrote:
> On 12/7/2019 11:52 AM, s8evq wrote:
> > In my limited experience mapping hiking routes, I have not yet come across 
> > any real use for nodes in hiking relations, but I'm curious if other people 
> > have good uses.
> > As far as I know, there is also not much documented in the wiki on the 
> > topic of nodes in hiking/cycling relations.
> Possibly for checkpoints?

Good idea. In at least some places where I travel, there are
_mandatory_ checkpoints: “No person shall fail to register whenever
passing a trail register established by the department in the Eastern
High Peaks Zone.” (N.Y. Comp. Codes R. & Regs. tit. 6 § 190.13(f)(1)
https://tinyurl.com/sdqfl2d)
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Sun, 8 Dec 2019 at 21:55, Allroads  wrote:

> Draw this image over the example, JOSM changes (not uploaded) drawn in.
> https://i.postimg.cc/t70p6WXm/Neubr-ckcrossing.png
> The area:highway=footway is correctly drawn in, but the footway is all
> footway=sidewalk, your still walking on the sidewalk.

I agree that you are on the sidewalk after coming down the steps, but
i don't agree that every way inside area:highway=footway +
footway=sidewalk (sidewalk area) is a highway=footway +
footway=sidewalk, because there is only *one* sidewalk, not multiple.
Otherwise, following your logic, all ways inside area:highway=tertiary
– including ways from the centre of the road to kerbs (which you
tagged footway=connection) – would have to be tagged highway=tertiary.

In my opinion, the way from the end of the steps to the kerb is also a
connection.

> Other perpendicular waylines inside a area:highway does not need that, if so
> then a other kind of value (I do not see the need for that)
>
> [...]
>
> Where do you need it, I think where kerbs are it is more important, and when
> you use area:highway, *=connection we could render visualise it slightly
> different.
> https://i.postimg.cc/D0n5S70G/tpath.jpg
> > [5]: https://www.openstreetmap.org/node/413988097

There's no kerb at this place. The only difference to the nearby T
crossing with the track is the width of the two ways.

Why should we need to tag the part of the path inside road area
specifically (e.g. as footway=connection), but not the part of the
track inside the road area?

Regards

Markus

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

[Tagging] surface=paving_stones examples review

[Mateusz Konieczny]

I just edited surface=paving_stones page at Wiki to add images with examples,
as it seems to be a case of a rare page where gallery can actually be useful.

Review of https://wiki.openstreetmap.org/wiki/Tag:surface%3Dpaving_stones
is welcomed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] state of a proposal

[Joseph Eisenberg]

The proposal was not continued and has not been significantly changed
since 2015, but the tag (area:highway=*) is documented at
https://wiki.openstreetmap.org/wiki/Key:area:highway and it has been
used by some mappers.

However, note that there were two different proposals which described
slightly different ways of using this tag: also see
https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway
from 2018

- Joseph Eisenberg

On 12/8/19, Catonano  wrote:
> I am interested in this proposal
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
>
> What' s the state of this proposal ?
>
> The tag says:
>
> rfc start 2015 08 15
>
> and then ?
>
> What happened since then ?
>
> Is the rfc still open ?
>
> When will it close ?
>
> Will it close ? I mean it was 2015 and it' almost 2020 now.
>
> Isn't there a progress status report ?
>
> Thanks
>

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

Re: [Tagging] state of a proposal

[Mateusz Konieczny]

This proposal is abandoned. See
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Street_area&action=history

As with any other tag:
- review how tag is actually used
- document it at https://wiki.openstreetmap.org/wiki/Key:area:highway
- use it in way matching de facto standard (or not use it)

As with any tag with an abandoned proposal:
You can also start second RfC or start a proposal vote.
You can also contact author of the proposal and asking whatever he
is fine with that.

Though given widespread use it is dubious whatever vote will actually
change anything, especially as it is too late to change tag definition
based on feedback. At this is the most useful part of a proposal 
process.

For closing - AFAIK we only note RfC start dates.

8 Dec 2019, 18:37 by caton...@gmail.com:

> I am interested in this proposal
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
>
> What' s the state of this proposal ?
>
> The tag says:
>
> rfc start 2015 08 15
> and then ?
>
> What happened since then ?
> Is the rfc still open ?
>
> When will it close ?
>
> Will it close ? I mean it was 2015 and it' almost 2020 now.
>
> Isn't there a progress status report ?
>

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

Re: [Tagging] state of a proposal

[Tobias Knerr]

On 08.12.19 18:37, Catonano wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
> 
> What' s the state of this proposal ?

Well, I wouldn't hold my breath for a vote unless the author (or someone
who takes over the reins) reboots it, but this doesn't necessarily mean
the idea is abandoned – not all proposals are adopted through voting,
some are simply adopted by people starting to use it.

In the case of this particular proposal, some people have experimented
with using it for mapping and development (myself included, I described
some very preliminary results during my SotM talk last year). From that
development perspective, I still feel Marek's proposal is the most
promising take on the area:highway idea so far.

Note that, although someone has later written wiki pages for
Key:area:highway¹ and related tags, they describe the wiki editors' own
take on the key, rather than any of the formally proposed versions. As a
result, that content is different from and incompatible with the
proposal you linked to. Which is unfortunate, as it lacks the clear
definitions regarding separation of junction areas from the connecting
road areas etc., which I found helpful when experimenting with software
support for it. I'm concerned that, contrary to the proposal, it may not
be as well suited for use cases that go beyond uniformly "painting" an area.

Tobias

¹ https://wiki.openstreetmap.org/wiki/Key:area:highway

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

On 09/12/19 07:14, Peter Elderson wrote:

Sarah Hoffmann mailto:lon...@denofr.de>>:


The point about the processing you have now made repeatedly in
different
contexts. You seem to have come to this conclusion because
waymarkedtrails
does not implement non-linear routes. As much as it honors me that you
consider waymarkedtrails the gold standard for what is doable with
route
relations, I have to disappoint you here. Non-linear routes are
simply not
implemented because of lack of time.


I'll take your word for that, but I do not see it yet! The proposal 
says it's on your request, so considering the processing by 
waymarkedtrails seems appropriate. Is that what the requested roles 
are intended for, if you can find the time? Or do you mean processing 
of non-linear routes without special roles? Can this result in exports 
usable for navigating by OsmAnd, Garmin and the like? Will it solve 
your discontinuous profile issue for non-linear routes?


I believe the intention is to make it possible to resolve issues with 
routes. At the moment the roles in routes are not documented nor 
harmonious.

Thrashing out the various roles here helps lots to combine thoughts.



If I'd have to state a rule what makes processing easier then it
would be:
avoid subrelations unless the relation is so large that it is a
pain to
handle in the editor.


The wiki about that says over 300 ways. I agree. More is not 
immediately fatal, but from 300 on maintenance effort increases 
significantly because errors (chain breaks and sorting errors) by 
other editors will happen more often, are more difficult to track, and 
sorting functions do not handle these errors well. Non-linearity also 
frustrates sorting and maintenance.


The main route of nearly all route relations I regularly maintain are 
far more than 300 members in total. So they will be split into parts 
conform the wiki. Of course there is no special relation type 
"sub-relation", that just means it's a route-in-a-route. Variants can 
be short or long, the longer ones can e.g. consist of 3 day's walking, 
which merits one ore more separate route relations for the variant. 
Variants and main route are then assembled in a route relation of type 
route or sometimes superroute.

I assumed handling this is accepted practice and will continue to happen.
Lucky you in only having 3 days to deal with. There are routes of 3+ 
months. Thousands of kilometres.


The question at hand is, should the proposed roles be applicable only 
to ways, or also to other elements in the route relations? If so, the 
proposal should state that, I think, and also what exactly it means, 
e.g. what exactly does forward mean for a (sub)relation element, and 
whether a particular sorting order is required.



For me these roles could be used for both ways and relations. However 
some roles do not make sense for relations .. eg forwards/backwards .. 
the ways in those relations should have any forwards/backwards applied 
there, not on the entire relation.
Why? The ways in the relation may have different directions. Someone 
could edit a way or add a new way with a different direction. It is the 
individual ways that have the direction, not the entire relation.


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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Allroads]

https://i.postimg.cc/c43VzBtk/squarelivingstreet.jpg
Took the wrong link.

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Allroads]

https://i.postimg.cc/J41D2GSJ/pedestriansquare.jpg

[6]: https://www.openstreetmap.org/way/416303537


I made a mistake. i thought it was a pedestrian square, but it is a 
livingstreet, so a T connection from steps to middle livingstreet 
carriageway.

This need a *=connection  value tag.

https://i.postimg.cc/9fMgcmSN/squarelivingstreet.jpg

My mistake, there you see difference livingstreet and pedestrian area, 
handling.


Mostly in a livingstreet there is a kind of lane created with different 
stones to guide the vehicles.
Besides this lane, could we speak of a sidewalk or more a pedestrian zone. 
Difficult.









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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Allroads]

Markus example:

Let's use a nearby example: https://www.openstreetmap.org/way/86205950.


It does not matter if the stairs are parallel or not!

Draw this image over the example, JOSM changes (not uploaded) drawn in.
https://i.postimg.cc/t70p6WXm/Neubr-ckcrossing.png
The area:highway=footway is correctly drawn in, but the footway is all 
footway=sidewalk, your still walking on the sidewalk.


In a area we draw lines like this highway=pedestrain area:yes example, 
area=yes should give area routing.

https://wiki.openstreetmap.org/w/images/1/19/Line_area_connection-EN.png
This image comes from this site: 
https://wiki.openstreetmap.org/wiki/Guidelines_for_pedestrian_navigation


Only way lines inside a area:highway=*, which have "not" equivalent value, 
should get the value, *=connection or link. Nothing else. We need this tag 
only from kerb to middle wayline carriageway, and can be used for 
pedestrian, footway, path, cycleway if there is the need to use it.
*=crossing value is cleary defined, *=connection must be the equivalent of 
*=crossing, at T connection on carriageways. This must also be clear 
defined!


(We do not draw a crossing further then the kerb of the road, so not as far 
as the middle line of the sidewalk)!!


Other perpendicular waylines inside a area:highway does not need that, if so 
then a other kind of value (I do not see the need for that)
Be aware that some people think that at a wide sidewalk, also a polygon, 
highway=footway footway=sidewalk area=yes, can be used just like the 
pedestran example ( a polygon and a wayline drwans in for pedestrian.)
When you are on a sidewalk, it feels  you are on a sidewalk, then it called 
a sidewalk.


I use my own style, far from complete, just working on sidewalk and crossing 
tags visualisation. I just missed a quick hint what is tagged.


Where do you need it, I think where kerbs are it is more important, and when 
you use area:highway, *=connection we could render visualise it slightly 
different.

https://i.postimg.cc/D0n5S70G/tpath.jpg

[5]: https://www.openstreetmap.org/node/413988097


https://i.postimg.cc/J41D2GSJ/pedestriansquare.jpg

[6]: https://www.openstreetmap.org/way/416303537


Like now, in Carto a polygon is rendered above the wayline, the example is 
area=yes pedestrian visualisation.





Nick Bolten examples:
Shelter crossing
https://i.postimg.cc/bJQpcL1Y/sheltercrossing.jpg
In front of the shelter (left) (busstop?) could a highway=platfrom be used 
as a tag.
I never draw a line over a shelter. right of the shelter middle of the way 
the wayline.


Steps building
https://i.postimg.cc/WzfPvyYZ/areafootway.jpg
steps, perpendicular footway to steps is footway=sidewalk, when you could 
draw the polygon area:highway=footway footway=sidewalk, this is inside the 
polygon, equivalent value. So =sidewalk.



Allroads.




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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Peter Elderson]

Sarah Hoffmann :

> On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote:
> > Also, i guess backward and forward roles are for ways only, the other
> > roles are more suited for relation members. Or not? Could I enter all the
> > ways of a 3 Km  medieval castle excursion to a viewpoint into the hiking
> > relation holding the ways of the main route, each with the 'excursion'
> > role? I think this should be explicit.
> >
> > It seems to me that use of these roles leads to relations containing
> > non-contiguous trails. I would call those relations collections rather
> than
> > routes. Processing non-contiguous routes presents extra challenges for
> > processing such as exporting routes and making elevation profiles.
>
> I have to strongly disagree with all of that.
>
> 1. Having alternatives and excursions does not make a route non-contiguous.
>It just makes it non-linear.
>

You are right, I used the wrong word. Non-linear. In practice most long
routes I work with also have gaps, in addition to branches, shortcuts,
extra loops, alternatives, full length variants, variants of variants and
completely separated variants e.g. island loops which are seen as part of a
longer route or collection. In addition, local routes are often part of
regional routes, (parts of) regional routes are sections of national
routes, and (part of) the main route of a national route is the national
section of an international route which can have completely separated
alternatives.


> 2. It is perfectly normal for a route to be non-linear. If the alternative
>route is marked, it's part of the route and should be mapped
> accordingly.
>

Of course. But it's not always clear what "the route" is! We (Nederland)
have routes consisting of several sections carrying their own trail names.
Sometimes people know them by their collective name, sometimes only the
separate names of the section paths. Many separate routes have identical
waymarking, and most of the waymarks carry no path name, so that does not
help.


> 3. Non-linear routes are not a problem for processing per-se.
>
> The point about the processing you have now made repeatedly in different
> contexts. You seem to have come to this conclusion because waymarkedtrails
> does not implement non-linear routes. As much as it honors me that you
> consider waymarkedtrails the gold standard for what is doable with route
> relations, I have to disappoint you here. Non-linear routes are simply not
> implemented because of lack of time.
>

I'll take your word for that, but I do not see it yet! The proposal says
it's on your request, so considering the processing by waymarkedtrails
seems appropriate. Is that what the requested roles are intended for, if
you can find the time? Or do you mean processing of non-linear routes
without special roles? Can this result in exports usable for navigating by
OsmAnd, Garmin and the like? Will it solve your discontinuous profile issue
for non-linear routes?



> If I'd have to state a rule what makes processing easier then it would be:
> avoid subrelations unless the relation is so large that it is a pain to
> handle in the editor.
>

The wiki about that says over 300 ways. I agree. More is not immediately
fatal, but from 300 on maintenance effort increases significantly because
errors (chain breaks and sorting errors) by other editors will happen more
often, are more difficult to track, and sorting functions do not handle
these errors well. Non-linearity also frustrates sorting and maintenance.

The main route of nearly all route relations I regularly maintain are far
more than 300 members in total. So they will be split into parts conform
the wiki. Of course there is no special relation type "sub-relation", that
just means it's a route-in-a-route. Variants can be short or long, the
longer ones can e.g. consist of 3 day's walking, which merits one ore more
separate route relations for the variant. Variants and main route are then
assembled in a route relation of type route or sometimes superroute.
I assumed handling this is accepted practice and will continue to happen.

The question at hand is, should the proposed roles be applicable only to
ways, or also to other elements in the route relations? If so, the proposal
should state that, I think, and also what exactly it means, e.g. what
exactly does forward mean for a (sub)relation element, and whether a
particular sorting order is required.

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

[Andy Townsend]

On 08/12/2019 17:01, Mateusz Konieczny wrote:


8 Dec 2019, 15:25 by mfbehren...@gmail.com :
> This diagram should help to better visualise the structure

At least in my case diagram was lost
and not displayed

It was a link to 
https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg 
in the wiki.


My email client also didn't show it by default (many won't show external 
image links by default)


Best Regards,

Andy


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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Fri, 6 Dec 2019 at 03:30, Nick Bolten  wrote:
> > I doubt that this were very useful, but would only complicate mapping. If 
> > you want to know the precise location where the footpath begins or ends, it 
> > should be possible to get that information from the road width or 
> > area:highway=*.
>
> Neither of these can reliably determine where the footpath begins or ends, as 
> the footpath may end before the street begins, such as when there's a 
> sidewalk between them.

If there's a sidewalk, it can also be mapped as an area
(area:highway=footway + footway=sidewalk). This way, it can be
determined where the footpath begins.

Alternatively, you could also tag the sidewalk width
(sidewalk[:left/right]:width=*), but this doesn't work well when the
width changes often.

> Let's use a nearby example: https://www.openstreetmap.org/way/86205950. This 
> is a highway=footway, footway=link connecting a set of stairs to the street 
> network, and it does so directly:  a highway=steps --> footway=link --> 
> highway=tertiary. A pedestrian router would want to encounter these decision 
> points: (1) continue onto the sidewalk vs. cross the sidewalk, (2) after 
> crossing the sidewalk, potentially encounter a curb, (3) enter the street. 
> Knowing the exact portion that is on the street is also useful, as that 
> distance should not factor into the route - pedestrians generally stick to 
> the side of a street when moving along it.

This example is quite different from the others as the steps run
parallel to the road and the sidewalk. (For a better visualisation,
i've mapped the sidewalk as an area, but you can also move about 100 m
southward, select the "Stadt Bern 10cm (2016)" aerial imagery and then
move back.) Therefore, you cannot continue the steps and connect them
with the road without breaking the orientation of the steps. The same
problem occurs with ending sidewalks [1] or with cycle lanes that
continue on the sidewalk [2], but also with crossroads with bollards
[3] or with an interrupted carriageway separator [4]. In these
examples, it makes sense to inform data users that these aren't
physical paths or roads, but merely connections needed for routing
purposes.

[1]: https://www.openstreetmap.org/way/554343046
[2]: https://www.openstreetmap.org/way/518400616
[3]: https://www.openstreetmap.org/way/749375744
[4]: https://www.openstreetmap.org/way/609505844

On the other hand, the part of the highway=path inside the road area
in the other example [5] is just an extension of the path to the
centre of the road. The orientation of the path doesn't need to be
broken in order to connect it with the road. Again, the
area:highway=tertiary makes it clear where the path really begins.
Therefore, i think mapping a path=link wouldn't be of much use here.

[5]: https://www.openstreetmap.org/node/413988097

Where i'm unsure whether a =link would make sense are steps that end
in a road, path or sidewalk [6]: on the one hand the orientation of
the steps wouldn't break when directly connecting them with the centre
of the road, on the other hand one would get a wrong impression of the
location of the first step and tread depth.

[6]: https://www.openstreetmap.org/way/416303537

> > Besides, only defining footway links, but e.g. not connections of tracks 
> > with roads (example [1]) or of roads with other roads (example [2]) seems 
> > quite arbitrary.
>
> The difference is that for vehicular traffic, the transition is correctly 
> described: directly from track to road. It is spatially a bit fuzzy, but I've 
> never encountered a routing scenario where a difference of a few meters of 
> track vs. road were considered important for vehicular routing. The link 
> schema would still be appropriate in those scenarios - it just needs to be 
> valuable.

Tracks (as well as other roads not primarily designated for
pedestrians) can often also be used by pedestrians. In the linked
example [7], the track is even part of a hiking route.

[7]: https://www.openstreetmap.org/node/893450790

> > That short way definitely isn't a separate sidewalk (no lateral kerb, not 
> > parallel to the road), but the extension of the crosswalk.
>
> I'm going to politely push back on this. We have to draw this connecting 
> segment regardless of whether the street crossing is marked (crosswalk) or 
> unmarked (no crosswalk) and whether there's a curb ramp or not, so it's not 
> necessarily part of a crosswalk. Even if this idea is amended to say that 
> this short way is an extension of a street crossing regardless of marking, 
> there's no appropriate crossing tag for it: is it 
> crossing=uncontrolled/marked, crossing=unmarked, or unset? All of them are 
> inaccurate in some way or another, or ambiguous.

I agree that the part from the centre of the sidewalk to the kerb is a
part of the sidewalk, but tagging it footway=sidewalk feels as wrong
as tagging a crosswalk highway=residential/... just because it is a
part of the road (or tagging the part 

[Tagging] state of a proposal

[Catonano]

I am interested in this proposal

https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area

What' s the state of this proposal ?

The tag says:

rfc start 2015 08 15

and then ?

What happened since then ?

Is the rfc still open ?

When will it close ?

Will it close ? I mean it was 2015 and it' almost 2020 now.

Isn't there a progress status report ?

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Mateusz Konieczny]

8 Dec 2019, 15:25 by mfbehren...@gmail.com:
> This diagram should help to better visualise the structure

At least in my case diagram was lost
and not displayed___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Volker Schmidt]

We all tend to think in pre-established categories.
Another one:
" The distinction that I find important is between ice cream made in an
artisanal fashion (like cakes, pastry) vs. ice cream that is produced
industrially,"
We have a famous (at least expensive) hybrid between the two her in Italy:
(Unilever-owned) GROM produce their ice cream concentrate in a factory and
then convert that stuff locally into ice-cream for which people queue.("Un
gelato come una volta").
Is that industrial or "artigianale" ?



On Sun, 8 Dec 2019 at 12:37, Mateusz Konieczny 
wrote:

>
>
>
> 11 Nov 2019, 12:04 by dieterdre...@gmail.com:
>
> Am Mo., 11. Nov. 2019 um 11:55 Uhr schrieb Mateusz Konieczny <
> matkoni...@tutanota.com>:
>
> Again, is there some difference
> in use by general population of mappers?
>
> I am not looking for differences in use
> wanted by specific mappers active here.
>
> I am not looking for how
> "place selling ice cream" may be split into
> smaller groups.
>
> I am not looking
> for purely theoretical implications
> of keys shop and amenity.
>
> I am not  looking for what would be desirable
> difference in use.
>
> Is there some consistent difference how
> this two tags are actually used?
>
>
>
> I have not found non-shops tagged as shop=ice_cream, have you? How many of
> these would we have to provide in order to be sure it aren't exceptional
> "errors" but standard way of tagging? You can find mistagged objects for
> any kind of object.
>
> For now giving a specific area where this distinction is maintained by
> mappers would be very helpful.
>
> Answering with something as short as "in Germany / London / Małopolska"
> would be helpful.
>
> And yes, mistaggings happen.
>
> Typically my next step would be to try to find what would be considered as
> mistagging
> and create notes and wait for how people will handle them.
>
> And/or ask other mappers from this region whatever this distinction
> actually exists.
>
> FWIW, if we always redefine our tag definitions to the smallest common
> meaning of the "general population of mappers", then discover that we have
> tags that now mean the "exact same thing", we will wipe out all the details.
>
> I am sure that attempting to store detail in top level tag is a big
> mistake.
> People tried to do this with landuse=forest vs natural=wood, with
> different people using them
> having a differing opinoin what is the difference and what exactly
> separates it.
>
> Detailed info really should go into additional tags.
>
> ___
> 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 - hiking_trail_relation_roles

[Michael Behrens]

Use of Subrelations and Superrelations[Quelltext bearbeiten

]

Some user requested to use subrelations to map parts of hiking trail and
then assign a role to the subrelation instead of each member of this
subrelation. In some cases this makes a lot of sense (long alternatives)
however in other cases (an excursion trail to a viewpoint made up of two
ways) it seems a little overdone.

My suggestion would be to establish a system that is able to handle both
ways of mapping at once.
[image: Proposed hierarchic structure of hiking relation .jpg]



This diagram should help to better visualise the structure.

   - The squares are relations which can contain further subrelations or
   - ways which are displayed as smaller circles.
   - The yellow circles are tagged with the role main. That means that they
   are part of the main hiking trail.
   - If you want to extract the main hiking trail from this hierarchic
   structure, you have to flaten out the hole structure into one big
   one-dimensional list of ways. That means that you follow down the
   hierarchie until you find the first way and then take the next one. This is
   called depth-first_search
   . An example is also
   indicated by the red line in the diagram. After that you ignore everything
   that is not a way and is not tagged with the role main (forward and
   backward can be considered later). This should give us a linear route that
   contains all elements from the main route in the correct direction.
   - The three white ways in the bottom right corner could be an
   alternative. For everything to be neat and tidy it has been put into a
   subrelation. Because it is just not tagged with the main role it has simply
   been ignored when we tried to figure the main trail out.
   - The fourth way in our main relation is also white. This one represents
   a short and very simple excursion to a viewpoint. This one is also ignored
   in the main trail procedure

Additionally roles can also be assigned to relations. In this case all the
elements in this relation which don't have a role inherit the role from
their relation. With this feature it is possible to create a relation with
all the paths of an alternative and only assign the role to the newly
created relation. Still, all the ways are considered as alternatives.

In this way both of the possible ways to map hiking trails are combined
into one way.--Mfbehrens99
 (talk
) 14:17, 8
December 2019 (UTC)

Am So., 8. Dez. 2019 um 13:21 Uhr schrieb Michael Behrens <
mfbehren...@gmail.com>:

> I fully agree with this argument and I also wrote a comment on the Wiki
> Talk page.
>
> What do you thing about using main:forward, main:backward,
> alternative:forward and alternative:backward.
>
> Another problem is that whenever there the main trail has a forward or
> backward we automatically have two main trails what could be considered as
> alternative. However now you can still create a elevation profile from the
> main route. One for forward and one for backwards.
>
> Michael
>
> On Sun, 8 Dec 2019, 10:48 Mateusz Konieczny, 
> wrote:
>
>> What about routes that have oneway segments, without paths having a legal
>> restrictions
>> on direction of walking?
>>
>> 6 Dec 2019, 19:28 by jan...@gmail.com:
>>
>> I think the "forward" and "backward" don't belong in a role of a
>> relation. Oneway=yes on a way should be enough. In the Wiki discussion it
>> is said that if there is one little "oneway" way in a big branch, then all
>> the ways in a branch should be checked to see if the whole branch is
>> oneway. But that means we are doing the work of a router directly in the
>> tags.
>>
>> We should just mark "oneway" ways as such, and leave the rest to the
>> routers.
>>
>> Also, "main" and "alternative" are orthogonal to "forward" and
>> "backward". We should then have "main:forward", "alternative:backward", and
>> so on. That doesn't make sense, and is not what "role" is traditionally
>> used for. Public transport routes used to use them, but not in the new
>> scheme.
>>
>> Janko
>>
>>
>> ___
>> 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 - hiking_trail_relation_roles

[Michael Behrens]

I fully agree with this argument and I also wrote a comment on the Wiki
Talk page.

What do you thing about using main:forward, main:backward,
alternative:forward and alternative:backward.

Another problem is that whenever there the main trail has a forward or
backward we automatically have two main trails what could be considered as
alternative. However now you can still create a elevation profile from the
main route. One for forward and one for backwards.

Michael

On Sun, 8 Dec 2019, 10:48 Mateusz Konieczny, 
wrote:

> What about routes that have oneway segments, without paths having a legal
> restrictions
> on direction of walking?
>
> 6 Dec 2019, 19:28 by jan...@gmail.com:
>
> I think the "forward" and "backward" don't belong in a role of a relation.
> Oneway=yes on a way should be enough. In the Wiki discussion it is said
> that if there is one little "oneway" way in a big branch, then all the ways
> in a branch should be checked to see if the whole branch is oneway. But
> that means we are doing the work of a router directly in the tags.
>
> We should just mark "oneway" ways as such, and leave the rest to the
> routers.
>
> Also, "main" and "alternative" are orthogonal to "forward" and "backward".
> We should then have "main:forward", "alternative:backward", and so on. That
> doesn't make sense, and is not what "role" is traditionally used for.
> Public transport routes used to use them, but not in the new scheme.
>
> Janko
>
>
> ___
> 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] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Mateusz Konieczny]

11 Nov 2019, 12:04 by dieterdre...@gmail.com:

> Am Mo., 11. Nov. 2019 um 11:55 Uhr schrieb Mateusz Konieczny <> 
> matkoni...@tutanota.com> >:
>
>> Again, is there some difference
>> in use by general population of mappers?
>>
>> I am not looking for differences in use
>> wanted by specific mappers active here.
>>
>> I am not looking for how 
>> "place selling ice cream" may be split into
>> smaller groups.
>>
>> I am not looking
>> for purely theoretical implications
>> of keys shop and amenity.
>>
>> I am not  looking for what would be desirable
>> difference in use.
>>
>> Is there some consistent difference how
>> this two tags are actually used?
>>
>>
>
>
> I have not found non-shops tagged as shop=ice_cream, have you? How many of 
> these would we have to provide in order to be sure it aren't exceptional 
> "errors" but standard way of tagging? You can find mistagged objects for any 
> kind of object. 
>
For now giving a specific area where this distinction is maintained by 
mappers would be very helpful.

Answering with something as short as "in Germany / London / Małopolska" would 
be helpful.

And yes, mistaggings happen.

Typically my next step would be to try to find what would be considered as 
mistagging
and create notes and wait for how people will handle them.

And/or ask other mappers from this region whatever this distinction actually 
exists.

> FWIW, if we always redefine our tag definitions to the smallest common 
> meaning of the "general population of mappers", then discover that we have 
> tags that now mean the "exact same thing", we will wipe out all the details.
>
I am sure that attempting to store detail in top level tag is a big mistake.
People tried to do this with landuse=forest vs natural=wood, with different 
people using them
having a differing opinoin what is the difference and what exactly separates 
it. 

Detailed info really should go into additional tags.

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Mateusz Konieczny]

What about routes that have oneway segments, without paths having a legal 
restrictions
on direction of walking?

6 Dec 2019, 19:28 by jan...@gmail.com:

> I think the "forward" and "backward" don't belong in a role of a relation. 
> Oneway=yes on a way should be enough. In the Wiki discussion it is said that 
> if there is one little "oneway" way in a big branch, then all the ways in a 
> branch should be checked to see if the whole branch is oneway. But that means 
> we are doing the work of a router directly in the tags.
>
> We should just mark "oneway" ways as such, and leave the rest to the routers.
>
> Also, "main" and "alternative" are orthogonal to "forward" and "backward". We 
> should then have "main:forward", "alternative:backward", and so on. That 
> doesn't make sense, and is not what "role" is traditionally used for. Public 
> transport routes used to use them, but not in the new scheme.
>
> Janko
>

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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Tom Pfeifer]

On 08.12.2019 00:49, Martin Scholtes wrote:


Am 07.12.2019 um 18:59 schrieb brad:

We already have park_ride tag.   I don't see the new tag adding anything?


"park and ride" rather describes the change to public transport and not
the continuation of driving with others in a private vehicle.


However it is the same concept to reduce the number of individual cars in the 
city.

Literally it means that you park your own and ride another vehicle,
whether that is a public transport train, a pooled car, an otherwise shared car,
a rental/shared bike, a scooter -- it is all the same concept.

There will be more coming in near future.

Thus it would be helpful and prevent tag fragmentation to group them all
under the established "park and ride" concept
and specify the respective riding facility in subtag.

tom

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