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

[Nick Bolten]

Sorry for the late feedback, Markus! Thanks for considering my thoughts.

> Wouldn't this mean that any footpath leading into a road would need to
be split for its last few metres, like the last 3 m of the path here?:

> https://www.openstreetmap.org/node/413988097

I believe so, yes. While this implies a lot of edits, there is a very clear
upgrade path that is conducive to tools like MapRoulette: when a particular
kind of footway shares a node with a street, suggest splitting it into a
link + non-link. This dovetails with the use of highway:area=*.

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

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.

My challenge to you is: write an algorithm that determines, with good
spatial accuracy, these pedestrian network transition locations: from
stairs to sidewalk centerline, from sidewalk centerline to curb, from curb
to street. You can use road width or area:highway=*. i.e., break up that
footway=link at the right places. It can be roughly estimated from street
and sidewalk width, but only if great, great care is taken in mapping that
tertiary street's geometry - more than is taken virtually anywhere on
earth. Keep in mind that the most intuitive strategy won't work at all near
intersections, as the sidewalk geometries won't be accurately captured.

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

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

> In my opinion there isn't a necessity tag it differently – if the width
of the sidewalk is specified, it is clear where the crosswalk begins.

A challenge: tag this crossing by your current preferred schema and write
an algorithm to tell me where the crosswalk begins:
https://www.openstreetmap.org/node/4694558040. Now do a version where's
just one curb ramp pointed into the intersection!

> This is a very different situation from the connections i have in mind.
Besides, these aid ways likely aren't verifiable.

They are the same abstract situation: a path someone could be expected to
take over an arbitrary 2D pedestrian space that is not itself a centerline,
but nevertheless provides routing and interpretability value. A very large
percentage of urban "footways" are equally unverifiable as they have the
same abstract problem, such as the other examples.

> > 5. Short paths to building entrances from sidewalks, other footways.
[...]
> >
> > 6. Short paths that deviate slightly from centerlines to make use of
facilities, but are still related to those other footways. [...]

> Could you please give me some examples for these two points?

I haven't mapped them yet personally, but I can show examples where they'd
be warranted.

Short paths to building entrance:

- https://www.openstreetmap.org/way/223357798. The entrance is in the
northwest corner and has two staircases (one per street) leading to a
landing. I could map the staircases, but what do I connect to at the
landing? 

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Martin Koppenhoefer]

sent from a phone

> On 5. Dec 2019, at 21:41, Jan Michel  wrote:
> 
> Also, introducing another set of 7 tags for such a minor piece of information 
> is (at least to me) an absolute overkill.


my suggestion if you want to map these in great detail would be mapping the 
bathrooms (or other things) and adding the property to them rather than the 
bigger, containing feature (museum, shopping mall etc.), also because even at 
the proposed level of detail there would be room for ambiguity (e.g. several 
distant ladies bathrooms in the same feature), or, map the changing table as a 
feature on its own rather than a property of something else. 


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

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Markus]

Hi Sören

Multiple tags are only needed if each of them describes a different
property, which is not the case for changing_table:location. I don't
see a problem with adding two or more values separated by a semicolon
in this case. In the contrary: a value list is clearer and it seems
that it can be used more easily by data users (see this discussion [1]
and its continuation [2]). The wiki page on Semi-colon value separator
[3], which you referred to, seems to be overly strict when it says
that "avoid ';' separated values whenever possible".

[1]: https://lists.openstreetmap.org/pipermail/tagging/2018-December/041650.html
[2]: https://lists.openstreetmap.org/pipermail/tagging/2019-January/041884.html
[3]: https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Jan Michel]

Hi,
I very much prefer the already accepted version. There is nothing wrong 
with semicolon separated values. Searching for one key and splitting its 
value is so much faster than searching with wildcards in a huge database 
like ours.
Also, introducing another set of 7 tags for such a minor piece of 
information is (at least to me) an absolute overkill.


Jan

On 05.12.19 14:39, Sören Reinecke via Tagging wrote:

Hey all,

A new but small proposal to change the specification for subkey 
`changing_table:location` because of a discussion yesterday about using 
seperators in values. I totally agree that we should avoid using 
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location

Definition: Tagging of the location of the nappy changing facility in a POI



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

[Tagging] Access Aisle Proposal

[Clifford Snow]

I have closed the voting for the Access Aisle Proposal. [1]

Final results of the voting are: It was *approved* with 14 votes for, 2
votes against and 1 abstention with an 82% approval.

I will start integrating the proposal into the wiki as documented in
Proposal Process.[2] The iD developers have already implemented the new tag
but I'm not sure when it will show up in iD.


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/access_aisle
[2] https://wiki.openstreetmap.org/wiki/Proposal_process

Thanks to all that participated.

Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Paul Allen]

On Thu, 5 Dec 2019 at 10:10, Martin Scholtes 
wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> Definition: Information that can be taken on this parking lot to form a
> carpool.
>

I would prefer the key to park_and_drive.  It's longer, and more typing,
but better English
and less prone to confusion.  Particularly for those in the UK and New
Zealand (and maybe
elsewhere) who know of these:
https://www.google.com/search?q=park+drive+cigarette

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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Martin Scholtes]

Am 05.12.2019 um 12:41 schrieb Sören Reinecke via Tagging:

> Allows the tag the mapping of carpool meeting points?
The proposal aims at marking parking places where one could meet to
carpool or which explicitly provide for parking one's vehicle and
forming a carpool.

An example would be a car park at a railway station, where you could
meet and carpool, but the car park is not explicitly intended for this
purpose, but for travelling by public transport.


-- 
Mit freundlichen Grüßen


Martin Scholtes




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

Re: [Tagging] Feature Proposal - RFC - park_drive

[Martin Scholtes]

Am I right in assuming that you support the proposal with the deviation
to only specify the values "designated" and "informal"?

Am 05.12.2019 um 12:13 schrieb Volker Schmidt:
> The only value of this key that is clear
> park_drive=designated (i.e. there are signs that allow only
> car-pooling parking)
> Any other car park that does not have a short time limit can be used
> for that purpose.
> Local knowledge may be used to identify those for which
> car_drive=informal
> might be a possible tag.
> Looking on satellite photos will give you hints for those. The ones I
> know of are not designated, but informal.
>
>
> On Thu, 5 Dec 2019 at 11:10, Martin Scholtes  > wrote:
>
> Hello,
>
> I would like to inform you that I have made a suggestion about
> park and
> drive. This resulted from a discussion in the OSM DE Telegram Chat.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> Definition: Information that can be taken on this parking lot to
> form a
> carpool.
>
> I would be pleased about suggestions.
>
> Forgive me, but this is my first time on that list.
>
>
> Greetings
>
> 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

-- 
Mit freundlichen Grüßen


Martin Scholtes



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

[Tagging] Feature Proposal - RFC - (changing_table:location)

[Sören Reinecke via Tagging]

Hey all,

A new but small proposal to change the specification for subkey
`changing_table:location` because of a discussion yesterday about using
seperators in values. I totally agree that we should avoid using
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location
Definition: Tagging of the location of the nappy changing facility in a
POI

Reason:
Someone pointed to the wikipage Semi-colon value separator as part of a
discussion of using semicolons as seperator of key values. In my 
previous successful proposal the subkey `changing_table:location' 
allows to seperate the values by a semicolon. While the support of a
semicolon as seperator for this subkey falls under the three exceptions
( https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator ), I
want to give here the chance to change that because the subkey 
changing_table:location is still not in widespread use.

Cheers

S??ren Reinecke alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Sören Reinecke via Tagging]

> Forgive me, but this is my first time on that list.There's not much to know. Now the discussion part begins, be attentative. Usually the discussion ends after the two week period and then voting takes place.I do not quite understand the definition of your proposal. Allows the tag the mapping of carpool meeting points?CheersSören Reinecke alias Valor Naram Original Message Subject: [Tagging] Feature Proposal - RFC - park_driveFrom: Martin Scholtes To: tagging@openstreetmap.orgCC: Hello,I would like to inform you that I have made a suggestion about park anddrive. This resulted from a discussion in the OSM DE Telegram Chat.https://wiki.openstreetmap.org/wiki/Proposed_features/park_driveDefinition: Information that can be taken on this parking lot to form acarpool.I would be pleased about suggestions.Forgive me, but this is my first time on that list.GreetingsMartin___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - park_drive

[Volker Schmidt]

The only value of this key that is clear
park_drive=designated (i.e. there are signs that allow only car-pooling
parking)
Any other car park that does not have a short time limit can be used for
that purpose.
Local knowledge may be used to identify those for which
car_drive=informal
might be a possible tag.
Looking on satellite photos will give you hints for those. The ones I know
of are not designated, but informal.


On Thu, 5 Dec 2019 at 11:10, Martin Scholtes 
wrote:

> Hello,
>
> I would like to inform you that I have made a suggestion about park and
> drive. This resulted from a discussion in the OSM DE Telegram Chat.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
> Definition: Information that can be taken on this parking lot to form a
> carpool.
>
> I would be pleased about suggestions.
>
> Forgive me, but this is my first time on that list.
>
>
> Greetings
>
> 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

[Tagging] Feature Proposal - RFC - park_drive

[Martin Scholtes]

Hello,

I would like to inform you that I have made a suggestion about park and
drive. This resulted from a discussion in the OSM DE Telegram Chat.

https://wiki.openstreetmap.org/wiki/Proposed_features/park_drive
Definition: Information that can be taken on this parking lot to form a
carpool.

I would be pleased about suggestions.

Forgive me, but this is my first time on that list.


Greetings

Martin



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

Re: [Tagging] Feature Proposal - Voting result - Pedestrian lane

[Markus]

On Wed, 4 Dec 2019 at 01:31, Alessandro Sarretta
 wrote:
>
> And in case on the left we have a shared cycle/foot lane?
>
> cycleway:left=lane
> pedestrian_lane=left
> segregated=no
>
> or
>
> cycleway:left=lane
> footway:left=lane
> segregated=no
>
> I think discussing of specific examples could help us clarifying which
> solution is better (or more usable).

A shared foot and cycle–lane is only one feature, therefore there
should only be one lane tag IMHO, not two. Because this is a separate
feature, likely with its own legal rules (i guess that pedestrians
have priority over cyclists?), i think a separate tag like
foot_cycle_lane=left/right/both would make most sense.

Another possibility were pedestrian_lane:bicycle=designated, but this
would imply that a shared foot and cycle–lane is a subtype of a
pedestrian lane. I'm unsure if this is sensible.

Regards

Markus

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