Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Felix Delattre via Tagging]

Hi all,

It is good to see active conversations on improving mapping of public
transport. Many thanks for your proposal John and Stereo!

Reading through it, I appreciate it being quite short. And I like the
idea of optional route ways. However, I disagree on deprecating them
entirely. There are good reasons to use them. In (many) other cases it
is very attractive to rely only on stops and waypoints, for the reasons
you are outlining.

The additional option for hail and ride is a useful feature. About the
variable routes, I'm not that sure. At least the variable routes, I know
in life, are also switching their stops, for example in high traffic
hours, they are one block off.

Instead of naming this public transport version 3, I think we should
really try come back to tagging without versioning schemas. In this
context I like a lot Ilya's proposal
(https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport)
which shows a good way get out of v1/v2/v3. And by the way, includes
also the idea of optional route ways.

> Should I use public_transport:version=3?
> Please don't. A route is either correct or not, and public transport
schema versions are not the same as software versions. The tag was
invented because PTv2 was not accepted by everybody. This schema
replaces (by incorporating) both of these, so the tag will be obsolete.

Cheers,
Felix

On 3/6/20 10:07 AM, John Doe wrote:
> Stereo and I have been working on a schema that makes it easier to create and 
> maintain public transport route relations. We would like to invite feedback, 
> questions, and suggestions, so it can mature and hopefully gain widespread 
> use.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations
>
>
>
> ___
> 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 - Public Transport v3

[Jo]

This is how I would map a solitary tram stop:

https://www.openstreetmap.org/node/611673223

Disregard the public_transport=platform, tram=yes. If I were mapping it
fresh today, I might not add those tags anymore.

Also note the pt=stop_position node:

https://www.openstreetmap.org/node/2000795897

I usually only map them If I plan to split the way (start or end of an
itinerary). It only has 2 tags, no further details and it is NOT a member
of the route relations.
I might stop mapping these altogether, since carto rendering decided to not
support the 'new' scheme. I don't see the point anymore. But that's not the
point.

And this is one with a platform:

https://www.openstreetmap.org/node/220369167

It's also served by buses.

The platform way is mapped separately:
https://www.openstreetmap.org/way/210281532

This is about as simple as it can get, no duplication, but still contains
all the relevant information. That is the point.

Polyglot

On Thu, Mar 12, 2020 at 9:11 AM Jo  wrote:

>
>
> On Thu, Mar 12, 2020 at 4:20 AM Jarek Piórkowski 
> wrote:
>
>> On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
>>  wrote:
>> > >  In inclement weather, passengers may well be found waiting in
>> > the transit shelter 8 metres to west, and the tram will stop for them
>> > if they are waiting in the shelter. It might also stop if you are
>> > waiting a little bit beyond the shelter
>> >
>> > In this case it sounds like the tram operators are allowed to stop in
>> > several different places.
>> >
>> > I would pick the place where the tram normally stops: either at the
>> > sign or the location of the shelter, depending on the standard
>> > practice in the local area. Either way, tram riders will be directed
>> > to the correct location by routing apps: an 8 meter difference is not
>> > significant.
>>
>> But why pick one and not the other? Only for the sake of having one
>> point rather than two in a database? Especially in this case where
>> they can be fairly reasonably described as "stop position" (the sign)
>> and "waiting area" (the shelter).
>>
>
> platform=stop_position is a node that is part of the way. As far as I'm
> concerned, they are not super important. What you call stop position (the
> sign) in the above paragraph seems to be what corresponds to
> highway=bus_stop, if it were a bus stop. That's the node, detached from the
> way that I would map as railway=tram_stop for representing the stop in the
> route relations, with all its details.. Of course, when you only have
> aerial imagery, it may be difficult to know that exact position. If there
> is a shelter I would put this node near to it, if there is nothing, I would
> place that node somewhere in the middle of a typical tram's length.
>
> If there is only a sidewalk, we would be done. If there is an actual
> platform, I would add a way or a closed_way with railway=platform, and
> possibly its height, tactile_paving and wheelchair. No name, no other
> details, they are on the node that represents the stop.
>
> If there is a shelter, I would map it with a closed_way; amenity=shelter,
> shelter_type=public_transport.
>
>
>> > >  Berlin mapping of streetside tram stops like
>> https://www.openstreetmap.org/way/389400777
>> >
>> > I have not visited that location in person, and the aerial imagery is
>> > not high enough resolution to see if there is a separate platform, so
>> > it is hard for me to say.
>> >
>> > The "gold standard" is survey: visiting the stop in location (and
>> > riding the tram perhaps)
>> >
>> > Do you know if the "platform" here is separate from the sidewalk in
>> > some way? It should either be a different height, or a different
>> > surface, or at least marked with a painted / thermoplastic line.
>> > Otherwise the length of this "platform" way would be arbitrary: why
>> > not include the whole block?
>>
>> In this particular case, there is not a platform that can be
>> distinguished - it's a curbside stop. The length of the "platform" way
>> appears to roughly match the length of the vehicles and thus the area
>> where the vehicles can be boarded (all-door boarding is in effect).
>> Berlin doesn't have many curbside stops but where they do exist, this
>> seems to be the prevailing local tagging.
>>
>> --Jarek
>>
>> ___
>> 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] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Michal Fabík]

On 3/12/20 1:37 AM, Kevin Kenny wrote:


Just a quick question. Is it reasonable to support `oneway=no`? I know
of one that serves a lime kiln that hauls coal one way and cement the
other. The discussion on the WIki states, "I think that virtually all
conveyors are unidirectional, and this calls for an unidirectional map
symbol," but that's not universal.


Definitely makes sense. One example would be coal stacker/reclaimer machines 
whose main conveyor is reversible to facilitate both modes of operation.

Regards,

--
Michal Fabík


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Jo]

On Thu, Mar 12, 2020 at 4:20 AM Jarek Piórkowski 
wrote:

> On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
>  wrote:
> > >  In inclement weather, passengers may well be found waiting in
> > the transit shelter 8 metres to west, and the tram will stop for them
> > if they are waiting in the shelter. It might also stop if you are
> > waiting a little bit beyond the shelter
> >
> > In this case it sounds like the tram operators are allowed to stop in
> > several different places.
> >
> > I would pick the place where the tram normally stops: either at the
> > sign or the location of the shelter, depending on the standard
> > practice in the local area. Either way, tram riders will be directed
> > to the correct location by routing apps: an 8 meter difference is not
> > significant.
>
> But why pick one and not the other? Only for the sake of having one
> point rather than two in a database? Especially in this case where
> they can be fairly reasonably described as "stop position" (the sign)
> and "waiting area" (the shelter).
>

platform=stop_position is a node that is part of the way. As far as I'm
concerned, they are not super important. What you call stop position (the
sign) in the above paragraph seems to be what corresponds to
highway=bus_stop, if it were a bus stop. That's the node, detached from the
way that I would map as railway=tram_stop for representing the stop in the
route relations, with all its details.. Of course, when you only have
aerial imagery, it may be difficult to know that exact position. If there
is a shelter I would put this node near to it, if there is nothing, I would
place that node somewhere in the middle of a typical tram's length.

If there is only a sidewalk, we would be done. If there is an actual
platform, I would add a way or a closed_way with railway=platform, and
possibly its height, tactile_paving and wheelchair. No name, no other
details, they are on the node that represents the stop.

If there is a shelter, I would map it with a closed_way; amenity=shelter,
shelter_type=public_transport.


> > >  Berlin mapping of streetside tram stops like
> https://www.openstreetmap.org/way/389400777
> >
> > I have not visited that location in person, and the aerial imagery is
> > not high enough resolution to see if there is a separate platform, so
> > it is hard for me to say.
> >
> > The "gold standard" is survey: visiting the stop in location (and
> > riding the tram perhaps)
> >
> > Do you know if the "platform" here is separate from the sidewalk in
> > some way? It should either be a different height, or a different
> > surface, or at least marked with a painted / thermoplastic line.
> > Otherwise the length of this "platform" way would be arbitrary: why
> > not include the whole block?
>
> In this particular case, there is not a platform that can be
> distinguished - it's a curbside stop. The length of the "platform" way
> appears to roughly match the length of the vehicles and thus the area
> where the vehicles can be boarded (all-door boarding is in effect).
> Berlin doesn't have many curbside stops but where they do exist, this
> seems to be the prevailing local tagging.
>
> --Jarek
>
> ___
> 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] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Martin Koppenhoefer]

sent from a phone

> On 12. Mar 2020, at 01:38, Kevin Kenny  wrote:
> 
> Just a quick question. Is it reasonable to support `oneway=no`? I know
> of one that serves a lime kiln that hauls coal one way and cement the
> other.


is this at the same time/ parallel, or reversing?

If it is the former, maybe it should be mapped as 2 conveyors?

Cheers Martin 

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