subject:"Re\: \[Tagging\] public_transport=platform rendering on osm\-carto"



sent from a phone

> On 23. Jun 2018, at 00:55, Graeme Fitzpatrick  wrote:
> 
> then why are we all worrying so much about stop positions? The driver knows 
> he has to stop at this location, & (I'm pretty certain! :-)) he's not staring 
> at his phone / GPS to see if OSM says he at's exactly the right spot on the 
> ground to stop the bus! 


they are relevant for long platforms as you find them in train stations, for 
typical bus stops they are not relevant


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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Graeme Fitzpatrick

On Fri, 22 Jun 2018 at 19:36, Martin Koppenhoefer 
wrote:

Have been following this whole conversation with interest (&, I must admit,
some confusion!).

Not wanting to be at all awkward :-), but if

The stop_position is the spot where the vehicle stops, it is not strictly
> needed for routing (of pedestrians) but the bus needs to know where to stop
> (doesn't typically need OSM navigation to drive his bus though).
>

then why are we all worrying so much about stop positions? The driver knows
he has to stop at this location, & (I'm pretty certain! :-)) he's not
staring at his phone / GPS to see if OSM says he at's exactly the right
spot on the ground to stop the bus!

Or are we making provision for fully autonomous driverless buses, relying
on OSM for guidance to find their correct stops? :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Johnparis

Most folks do use presets, especially those marking bus stops in the wild,
which is the vast majority of the cases that matter in this discussion.

Only recently (March 2018) did iD begin including PTv2 tags in its presets.
Before then, it only offered PTv1, that is, highway=bus_stop. So of course
"actual tagging" reflects this. It also created the mess with a "bus stop"
including the direction-depended platforms and the (often approximate) stop
positions. All of which PTv2 addresses.

There have been two big problems with progressing on PTv2, as I see it:

1) There was no preset in iD for it. Jo (Polyglot) has previously remarked
on his years of effort in this area. I am glad it finally happened.

2) There is no support (still) in osm-carto for it.

These are the two fundamental steps that need to occur for a tag revision
to succeed. Until they are in place, the old tag will continue to be
preferred in "actual tagging."

I have seen an uptick in PTv2 tagging in the wild for bus stops since the
iD change took place. (The iD preset is rendered in osm-carto because the
preset includes BOTH the PTv1 and PTv2 tags.)

It took seven years for iD to incorporate PTv2 as a preset. Hopefully it
will take less time for osm-carto to render it.

You say PTv1 is simpler. It's only simpler in that it involves one tag
rather than two. To me, if I were not using presets, it would be more
complicated to remember:
highway=bus_stop (for bus stops)
railway=platform (for railway, tram and subway platforms)
aeroway=gate (at airports)

rather than
public_transport=platform + bus=yes   for buses
public_transport=platform + train=yes   for trains
public_transport=platform + subway=yes   for subways (US English)
public_transport=platform + tram=yes   for trams

... and of course, it's not possible to map a platform in PTv1 that serves
both trams and trains, while in PTv2 you have
public_transport=platform + tram=yes + train=yes

To me, that's simpler.

On Fri, Jun 22, 2018 at 3:37 PM, Martin Koppenhoefer  wrote:

> 2018-06-22 15:28 GMT+02:00 :
>
>> It's always the same tag. So any routing software can (foot) route you to
>> a public_transport=platform, and if there are any route relations including
>> that platform, they know that you will be able to enter that public
>> transport route and can exit it at any public_transport=platform listed in
>> the route relation after this one. This works exactly the same for busses,
>> trams, trains, ferries, ...
>
>
>
> it is understood that this is always the same tag for the same or similar
> function wrt public transport routing, but is there a benefit from it?
> Aren't bus stops different from ferry boarding or from platforms in train
> stations? For those of us who don't use presets, isn't it simpler to add
> highway=bus_stop on your smartphone than public_transport=platform and
> bus=yes? I do not care a lot about this issue, but from the actual tagging
> it seems people prefer the simple way (simple for them).
>
>
> 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] public_transport=platform rendering on osm-carto

2018-06-22 Thread Jo

For access restrictions we had started by using psv=yes, but I guess few
people will read that as public services vehicle and another problem with
that is that is apparently includes taxis as well.

Personallly, I see a big difference between a way tagged as *=platform and
a node with that tag.

On a way it means the area where passengers are supposed to stand and which
usually is a bit higher, or explicitely created for those passengers. You
know it, when you see it.

On a node it means waiting area, where you can expect to be picked up by a
public transport vehicle. There could be pole, there could be a platform
(which can be drawn next to it), there could be a shelter, a vending
machine, a screen announcing when the vehicle will come, garbage cans,
benches. Or there could be nothing there at all, but the convention that
buses will alight and pick up passengers at that spot.

The platform node groups most of the properties of the bus stop, so it
makes sense to add it to the route relations. I'd like to see that it can
remain a node over the lifetime of such a bus stop. And for all the other
amenities near it, we can have separate objects.

This works just as well for bus stops as for tram stops and indeed, some
tram stops are served by buses as well.

it's that 'platform' node that gets bus=yes/tram=yes etc.

For the platform way/area mode of transport is far less important.

Maybe the platform node should have been called something else. Especially
since stop_position contains the word stop and some new mappers consider
that to be the correct tag for tagging the bus stop.

So yes, words are confusing and the way they have become defined in
OpenStreetMap even more so.

Polyglot

Op vr 22 jun. 2018 om 16:53 schreef Johnparis :

> Heh. Another example of the imperfectibility of language.
>
> Neither the GTFS specification nor the NetEx standard envisions any
> distinction between boarding-only and alighting-only points (or mixed ones,
> for that matter), and I have never encountered any bus route where such a
> distinction was made. Since the wiki is supposed to be descriptive, I
> have amended it accordingly, but of course there will still be other
> precisions to be made.
>
> I think Thorsten's description of the magic transfer is very accurate.
>
> One of the advantages of PTv2 over PTv1 is the ability to tag mutlimodal
> platforms. Tram platforms are frequently multimodal, but others can be as
> well. The tags used (not controversial) are public_transport = platform +
>  = yes, for one or more mode tags. The controversy referred to in
> another thread is that this duplicates (some of) the access=* mode tags, so
> there is a potential confusion between bus=yes when it is intended to be an
> access tag and bus=yes when it is a modal tag for public transport.
>
> I have previously gone on record as supporting "access:bus=yes" when
> access is meant, but I don't think that's very practical, and in the real
> world the conflict doesn't exist. (I suppose an alternative would be
> "public_transport:bus=yes" for such cases, which might make things simpler
> for parsing software, and maybe for editor software, but makes no
> difference otherwise that I can see.)
>
> John
>
>
>
>
>
> On Fri, Jun 22, 2018 at 2:35 PM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 22. Jun 2018, at 13:53, Johnparis  wrote:
>> >
>> > It's not always a waiting area, btw, sometimes it's reserved for
>> leaving the transportation device.
>>
>>
>> the definition for public_transport=platform is “The place where
>> passengers are waiting for the public transport vehicles.”
>> if the area is not used for waiting, you cannot tag it as platform, you
>> could use something like boarding_area
>>
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Johnparis

Heh. Another example of the imperfectibility of language.

Neither the GTFS specification nor the NetEx standard envisions any
distinction between boarding-only and alighting-only points (or mixed ones,
for that matter), and I have never encountered any bus route where such a
distinction was made. Since the wiki is supposed to be descriptive, I have
amended it accordingly, but of course there will still be other precisions
to be made.

I think Thorsten's description of the magic transfer is very accurate.

One of the advantages of PTv2 over PTv1 is the ability to tag mutlimodal
platforms. Tram platforms are frequently multimodal, but others can be as
well. The tags used (not controversial) are public_transport = platform +
 = yes, for one or more mode tags. The controversy referred to in
another thread is that this duplicates (some of) the access=* mode tags, so
there is a potential confusion between bus=yes when it is intended to be an
access tag and bus=yes when it is a modal tag for public transport.

I have previously gone on record as supporting "access:bus=yes" when access
is meant, but I don't think that's very practical, and in the real world
the conflict doesn't exist. (I suppose an alternative would be
"public_transport:bus=yes" for such cases, which might make things simpler
for parsing software, and maybe for editor software, but makes no
difference otherwise that I can see.)

John

On Fri, Jun 22, 2018 at 2:35 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 22. Jun 2018, at 13:53, Johnparis  wrote:
> >
> > It's not always a waiting area, btw, sometimes it's reserved for leaving
> the transportation device.
>
>
> the definition for public_transport=platform is “The place where
> passengers are waiting for the public transport vehicles.”
> if the area is not used for waiting, you cannot tag it as platform, you
> could use something like boarding_area
>
>
> 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] public_transport=platform rendering on osm-carto

2018-06-22 15:28 GMT+02:00 :

> It's always the same tag. So any routing software can (foot) route you to
> a public_transport=platform, and if there are any route relations including
> that platform, they know that you will be able to enter that public
> transport route and can exit it at any public_transport=platform listed in
> the route relation after this one. This works exactly the same for busses,
> trams, trains, ferries, ...



it is understood that this is always the same tag for the same or similar
function wrt public transport routing, but is there a benefit from it?
Aren't bus stops different from ferry boarding or from platforms in train
stations? For those of us who don't use presets, isn't it simpler to add
highway=bus_stop on your smartphone than public_transport=platform and
bus=yes? I do not care a lot about this issue, but from the actual tagging
it seems people prefer the simple way (simple for them).


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

Re: [Tagging] public_transport=platform rendering on osm-carto



sent from a phone

> On 22. Jun 2018, at 13:53, Johnparis  wrote:
> 
> It's not always a waiting area, btw, sometimes it's reserved for leaving the 
> transportation device. 


the definition for public_transport=platform is “The place where passengers are 
waiting for the public transport vehicles.” 
if the area is not used for waiting, you cannot tag it as platform, you could 
use something like boarding_area


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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread marc marc

Le 22. 06. 18 à 10:41, Jo a écrit :
> if there is a dedicated area, map it as a way or area and add:
> highway=platform for bus stops
> railway=platfomr for trams stops

> BUT keep the node tagged as
> public_transport=platform

you create duplicate objet for the same feature.

If you feel that that's the common vision, try to make again a proposal 
to change the current meaning of PTv2 for public_transport=platform (a 
common tag for all PTv1 variant)... but the 2nd previous have been rejected.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread ael

On Fri, Jun 22, 2018 at 07:35:27AM +0200, Jo wrote:
> The thing is, when PTv2 was voted, I asked what to do with the bus stop
> nodes next to the way. The answer was put public_transport=platform on
> those NODES. In fact they rather represent a pole with a flag on it. But
> for some bus stops, there is nothing physical present. The bus stops there
> and both passengers and the drivers know it.

I expect it is too late to change this, but this is just plain wrong.
It should be something like
   public_transport=waiting_place
which can be a node or an area.

So far, I just haven't been able to tag a place without a platform
as a "platform".

ael

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread ael

On Fri, Jun 22, 2018 at 01:26:37AM +0200, Yves wrote:
> Why adding 'platform' where there's no physical platform?

+1


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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Alan Grant

On 22 June 2018 at 11:01, Paul Allen  wrote:

>  If I'm right, the only downsides are that I have to map two distinct
> objects (platform and
> stop position) and I have to repeat information (the name of the stop, at
> least) for both.
>
>
I have found that the downside is not so much in the initial mapping as in
the subsequent maintenance. Mapping two distinct objects from scratch is
tedious but do-able, especially if done by one mapper who takes a
consistent approach. But at least in my city, urban bus routes and their
stops change a lot and thus require a lot more maintenance than trams and
railways (without even getting into repairing relations that get broken by
other mappers working on something other than public transport). If the
stop moves and another mapper decides to update the map, you have to hope
they realise that the position and maybe the name and reference tags need
to be changed for 2 objects (or maybe 3 if there is a stop_area relation),
as well as updating the route relation itself.

Another downside, and apologies for going on about this but I haven't seen
a clear answer, is that you have to decide whether to add "bus=yes" to the
platform node (and indeed highway=bus_stop if you want to give it a good
chance of being generally rendered), and again hope that other mappers
agree with your approach.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 11:01 GMT+02:00 Paul Allen :

> As far as routeing goes, the stop position is important.  When I switch
> between bus/foot I do NOT (in most
> circumstances) walk through the platform itself and there's only a 50%
> chance I will walk past the length of
> the platform.  Platforms are often offset from stop positions, such as
> https://www.google.co.uk/maps/@52.0841293,-4.6605633,3a,75y,
> 333.25h,77.93t/data=!3m6!1e1!3m4!1sC6vWAGH4rcR2EoMfVZcIjQ!
> 2e0!7i13312!8i6656
>


the platform is (by definition) the place where you go to wait for the
vehicle, so it is needed for routing. The stop_position is the spot where
the vehicle stops, it is not strictly needed for routing (of pedestrians)
but the bus needs to know where to stop (doesn't typically need OSM
navigation to drive his bus though). You can deduct the stop_position from
the bus_stop / platform position, i.e. it is already implicit, apart from
rare exceptions where there are some meters of fuzziness (i.e. no practical
implications, you wait at the platform and enter the vehicle when it stops,
regardless the precise position). Usually the difference of a bus stopping
behind another bus makes a bigger deviation from the stop position than any
distance from a projected platform node on a highway (i.e. those meters are
all completely insignificant for all practical usecases).



>
> If I get off the bus there and turn left I don't walk past the platform.
> If I get off and turn right I'd only walk through
> the shelter if there were people blocking the rest of the sidewalk.  I
> know it's only a matter of a metre or so, but
> from a strictly technical perspective the routeing is from the stop
> position, not the platform.
>


from a strictly technical perspective you have to take into account whether
you leave the bus at the beginning, in the middle or at the end, which is
usually much more than a single meter, and whether the bus stopped at the
stop position or behind one or two other busses, which again makes much
more difference than a meter.




>
> Even if the underlying mechanics is taken care of by the database engine,
> it takes more CPU and memory to
> find the segment of a highway closest to a platform than to find the
> highway that a node (stop position) is on.
>



yes, but I have already written about this:  "OSM traditionally values
mapper convenience higher than simplicity of data evaluation."

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 7:35 GMT+02:00 Jo :

>
>
> What I am trying to accomplish is that bus and tram stops would be
> represented by a single node, next to the highway.
>



tram stops are a different beast IMHO, often they do have a platform
(railway=platform is ok for these), some are like bus stops, it depends on
the situation. tram stops can also look like subway stations in some cases,
and an area can make sense in some cases.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Paul Allen

On Thu, Jun 21, 2018 at 11:34 PM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

>
> I am with Jo here: the stop_positions at bus stops do not add any
> information, at most they would add convenience for data consumers (if
> every bus stop had them), but OSM traditionally values mapper convenience
> higher than simplicity of data evaluation.
>

I don't fully comprehend all the implications of PTv2. I don't fully
comprehend the capabilities of routeing engines as
currently implemented or how they may be implemented in future,. I'm
considering only the aspects of this that
affect buses, not other PTV2 categories. So there may be extreme
Dunning-Kruger ahead...

I'm starting to think (probably incorrectly) that the stop position on the
highway is more valuable in a relation than the
platform but the platform is more valuable than the stop position in
rendering.

As far as routeing goes, the stop position is important. When I switch
between bus/foot I do NOT (in most
circumstances) walk through the platform itself and there's only a 50%
chance I will walk past the length of
the platform. Platforms are often offset from stop positions, such as
https://www.google.co.uk/maps/@52.0841293,-4.6605633,3a,75y,333.25h,77.93t/data=!3m6!1e1!3m4!1sC6vWAGH4rcR2EoMfVZcIjQ!2e0!7i13312!8i6656
If I get off the bus there and turn left I don't walk past the platform.
If I get off and turn right I'd only walk through
the shelter if there were people blocking the rest of the sidewalk. I know
it's only a matter of a metre or so, but
from a strictly technical perspective the routeing is from the stop
position, not the platform.

Even if the underlying mechanics is taken care of by the database engine,
it takes more CPU and memory to
find the segment of a highway closest to a platform than to find the
highway that a node (stop position) is on. Of
course, I could be completely wrong about that.

If there is any merit to the idea I put forward that stop position and/or
platform should be interspersed in the
route relation rather than gathered at the beginning (I'm not convinced
there is merit in the idea, but I would
find it easier to figure out what is going on in a bus route relation if
they were interspersed) it feels more
natural to me to have the stop position than the platform.

Taking all that into account, it feels more natural (to me, when thinking
of bus routes) that platforms are
physical objects unrelated to bus route relations but which should be
rendered and that stop positions are
a necessary part of bus route relations but which should not be rendered.
I don't even see a necessity to
"link" the two via an auxiliary relation as some seem to have suggested.

As far as I understand it, I actually have the choice to map it this way
(although whether I choose to include
platform or stop position in the relation they currently have to be
gathered at the start of the relation) without
breaking any rules. If I'm right, the only downsides are that I have to
map two distinct objects (platform and
stop position) and I have to repeat information (the name of the stop, at
least) for both.

Or maybe I'm completely missing the point of just about everything.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread Jo

Op vr 22 jun. 2018 om 10:10 schreef marc marc :

> Le 22. 06. 18 à 01:26, Yves a écrit :
> > Why adding 'platform' where there's no physical platform?
>
> public_transport=platform describe where passagers wait
> for a public transport.
> if there is no dedicated area, use a node outside the road/rail
> near the bus stop or near the railroad stop
>

Good, we agree thus far. Now if there is a dedicated area, map it as a way
or area and add:

highway=platform for bus stops
railway=platfomr for trams stops

maybe tactile_paving and wheelchair and a height.

BUT keep the node tagged as

highway=bus_stop
public_transport=platform
bus=yes
name=
ref=
route_ref=
operator=
network=
etc...

There is no need to "UPGRADE" from a node to a way/area. As this is not an
upgrade at all.

We can then use these highway=bus_stop nodes in the route relations and
each stop is represented in the route relations by 1 object. A single
object that has all the details for that stop. Nice and clean.

What I see happening is that a platform way and a stop_position node are
created, details are duplicated (maintenance nightmare)  and both are added
to the route relations.

There are still millions of bus stops that need to be mapped, we want to
have a way of mapping them that is as simple as feasible (without losing
information), but also that doesn't need transformations from nodes to ways
during the lifetime of the stops. A transformation that would also affect
all the route relations, and there are many of those as well, one for each
variation of a line.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-22 Thread marc marc

Le 22. 06. 18 à 01:26, Yves a écrit :
> Why adding 'platform' where there's no physical platform?

public_transport=platform describe where passagers wait
for a public transport.
if there is no dedicated area, use a node outside the road/rail
near the bus stop or near the railroad stop
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread Jo

The thing is, when PTv2 was voted, I asked what to do with the bus stop
nodes next to the way. The answer was put public_transport=platform on
those NODES. In fact they rather represent a pole with a flag on it. But
for some bus stops, there is nothing physical present. The bus stops there
and both passengers and the drivers know it.

Those are the nodes that get public_transport=platform, without an actual
platform being present.

Now if there is a physical platform, we draw a way or an area and tag it
highway=platform or railway=platform. Those can also get a
public_transport=platform tag. But it doesn't really matter, highway=platform
or railway=platform has all the information we need for those. In case it's
heightened, we can add wheelchair yes, if there is tactile paving, we can
add tactile_paving=yes, although I think it would be even better if we
could add explicit ways and nodes for those, as we map in more and more
detail.

What I am trying to accomplish is that bus and tram stops would be
represented by a single node, next to the highway. That those nodes get all
the tags describing the bus or tram stop and that only those nodes get
added to the route relations.

Some people say, but you should be able to 'upgrade' from a node to a way
or an area. I say: let's go for stability in the data and keep it all
contained in that single node per bus/tram stop. It's easy to work with for
both data consumers and mappers.

What this does imply is that stop_area relations should bundle the smallest
group of objects that belong together (for one side of the street at a time
or for one platform in a bus station). At present the wiki seems to say to
throw everything in there together for a group of bus stops that happen to
have the same name. But that, we can do just as well with a spatial query
on the data.

So no, adding public_transport=platform does not mean there is a physical
platform, just like highway=bus_stop doesn't mean it's part of the highway,
unfortunately both tags are slightly off. but we shouldn't get too fixated
on the meaning of those words in English, but rather what has become the
convention in OSM for them).

Polyglot

Op vr 22 jun. 2018 om 01:27 schreef Yves :

> Why adding 'platform' where there's no physical platform?
> Yves___
> 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] public_transport=platform rendering on osm-carto

2018-06-21 Thread Martin Koppenhoefer



sent from a phone

> On 22. Jun 2018, at 00:23,  
>  wrote:
> 
> And the ones that used to have only a highway=bus_stop node only require a 
> public_transport=platform node instead now. No increase in complexity.


you must add bus=yes or it would not be a bus stop. It isn’t more complex, just 
more complicated and time consuming.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread Martin Koppenhoefer

sent from a phone

> On 21. Jun 2018, at 23:30, Jo  wrote:
> 
> If Paul feels it would be better to have those stop_postion nodes in the 
> route relations anyway, he can add them back in. They dont add information 
> though.

I am with Jo here: the stop_positions at bus stops do not add any information, 
at most they would add convenience for data consumers (if every bus stop had 
them), but OSM traditionally values mapper convenience higher than simplicity 
of data evaluation.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread osm.tagging

> -Original Message-
> From: Martin Koppenhoefer 
> Sent: Friday, 22 June 2018 08:03
> 
> a bus stop usually didn’t have a highway=platform, just
> highway=bus_stop, only for platforms on stations the former is
> suggested.
> It is only a fraction (94k) of all bus stops (2M) that could be
> seen as simpler after a change.

And the ones that used to have only a highway=bus_stop node only require a 
public_transport=platform node instead now. No increase in complexity. So some 
are the same, and some are simpler, none are required to be more complex. So 
overall, it's simpler.



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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread Martin Koppenhoefer



sent from a phone

> On 20. Jun 2018, at 19:53,  
>  wrote:
> 
> One, which is connected to the foot network. That is your 
> public_transport=platform. In this regard, PTv2 is easier than the old 
> scheme, as you no longer have two separate highway=platform and 
> highway=bus_stop. You only have a single public_transport=platform. If it’s 
> on a node, then it’s just a simple pole or otherwise marked stop without any 
> real platform, if it’s tagged on a way (representing the platform edge) or an 
> area (representing the whole platform) then you got an actual platform.


a bus stop usually didn’t have a highway=platform, just highway=bus_stop, only 
for platforms on stations the former is suggested.
It is only a fraction (94k) of all bus stops (2M) that could be seen as simpler 
after a change.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread Jo

You guys are hilarious. I actually helped Paull Allen with his questions on
how to map that bus line. It's where the discussion about reverse role came
from, by the way.

Anyway, I removed the stop_position nodes from the route relations yes. It
shows that it's perfectly possible to map bus lines with nodes next to the
highways and without having to duplicate information across 2 objects and
then having to add both those objects to the route relations.

In general the data was improved and Paul learned how he can map a complex
bus line that does illogical things.

If Paull feels it would be better to have those stop_postion nodes in the
route relations anyway, he can add them back in. They dont add information
though.

Paul's concern was rather that the stops come first in the relation
foloowed by the ways. He would prefer to add the stops sprinkled between
the ways.

I'm looking into how feasible that would be in JOSM. There is something to
say for doig it that way, but only if there is support from the editor
software. Because the reason why we have a long string of ways, is because
now we get visual feedback that this sequence of ways is continuous. (or
not)

Anyway, I think we need to rethink how public transport should be mapped in
OSM, as what we are doing right now is too compilcated and data needs to be
duplicated between stop_position nodes and platform nodes/ways. I have been
silent about this for years, from now on I will keep hammering on this.

And to get back on topic changing the rendering of highway=platform or
railway=platform on ways is not useful. Those are just fine the way they
are. It's the platform nodes (previously highway=bus_stop) that we are
concerned about.

Jo (Polyglot)

Op do 21 jun. 2018 om 17:47 schreef :

> As I previously said, I would consider this vandalism.
>
> > -Original Message-
> > From: marc marc 
> > Sent: Friday, 22 June 2018 01:23
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] public_transport=platform rendering on osm-
> > carto
> >
> > Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> > > Platforms are mapped but stop positions aren't (somebody who
> > thinks
> > > they shouldn't be there cleaned up after me).
> > > https://www.openstreetmap.org/relation/7620346
> >
> > if want to known who destroy stop_position in the relation, look at
> > version #18 changet 59355804 23 days ago.
> > PS: Polyglot=Jo
> >
> > The destruction of perfectly valid tags is really a problematic
> > behavior despite all the sympathy I have for Jo in many other
> > threads.
> > Fixing some stuff in a relationship does not need to destroy valid
> > info that another mapper had added previously.
> > ___
> > 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] public_transport=platform rendering on osm-carto

2018-06-21 Thread osm.tagging

As I previously said, I would consider this vandalism.

> -Original Message-
> From: marc marc 
> Sent: Friday, 22 June 2018 01:23
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] public_transport=platform rendering on osm-
> carto
> 
> Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> > Platforms are mapped but stop positions aren't (somebody who
> thinks
> > they shouldn't be there cleaned up after me).
> > https://www.openstreetmap.org/relation/7620346
> 
> if want to known who destroy stop_position in the relation, look at
> version #18 changet 59355804 23 days ago.
> PS: Polyglot=Jo
> 
> The destruction of perfectly valid tags is really a problematic
> behavior despite all the sympathy I have for Jo in many other
> threads.
> Fixing some stuff in a relationship does not need to destroy valid
> info that another mapper had added previously.
> ___
> 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] public_transport=platform rendering on osm-carto

2018-06-21 Thread marc marc

Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> Platforms are mapped but stop positions aren't 
> (somebody who thinks they shouldn't be there cleaned up after me).
> https://www.openstreetmap.org/relation/7620346 

if want to known who destroy stop_position in the relation,
look at version #18 changet 59355804 23 days ago.
PS: Polyglot=Jo

The destruction of perfectly valid tags is really a problematic behavior 
despite all the sympathy I have for Jo in many other threads.
Fixing some stuff in a relationship does not need to destroy valid info 
that another mapper had added previously.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-21 Thread Paul Allen

On Wed, Jun 20, 2018 at 10:24 PM, Jo  wrote:

>
> It's probably best to provide a link to the actual route relation. It's
> indeed a complex one.
>

For those who care, it's https://www.openstreetmap.org/relation/7620346 (I
think I now have everything in the
correct order in the relation).  I find it hard to figure out what's going
on from looking at the relation and I ride this
bus!  Good luck to any data consumer using the query tool trying to figure
it out.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

I'll help you with those as well, as long as we can keep those dreadful
stop_position nodes out of it :-) (and tag the stops as nodes next to the
way).

but feel free to follow what the wiki seems to say, I'll probably help you
anyway, no worries. At the end of the day, you'll be the one who will be
maintaining those routes in the future. For the routes that I plan to
maintain, I want only a single node per stop in the route relations, which
has all the details exactly 1 time.

As I want to be able to see on which side of the street they are
positioned, I create them as nodes next to the way (so stop_position nodes
won't do for that purpose). A few years ago I asked which public_transport
tag to use for them, and the answer was platform, so I ran with that. Even
in those places where there was no actual platform. The biggest advantage
was that JOSM added them to route and stop_area relations with a platform
role. Apart from that it was probably a waste of storage bytes. The more I
think about it, the more Ilya's proposal to simply use highway=bus_stop
seems like the right thing to do.

And for those places where there are actual platforms those get tagged
highway=platform (no mode of transport, only maybe
wheelchair=yes/tactile_paving=yes and maybe a height). These are the ones
mentioned in this thread by the way, the ones that don't make sense to
change the rendering for.

What we were asking to change the rendering for are the supposed
replacements of highway=bus_stop/railway=tram_stop, but the more I think
about it, the less this seems necessary.

Polyglot

Op wo 20 jun. 2018 om 23:44 schreef Paul Allen :

>
> On Wed, Jun 20, 2018 at 10:24 PM, Jo  wrote:
>
>>
>> It's probably best to provide a link to the actual route relation. It's
>> indeed a complex one.
>>
>
> I'll do it tomorrow.  I had a look earlier today and it was either broken
> before I looked or I broke it while trying
> to figure out how to use JOSM.  I'll post the link tomorrow after I've
> fixed it (or broken it even more).
>
> And yes, it's complicated.  The stop that is ignored the first time but
> used the second time is in the timetable
> but there isn't a shelter, there isn't a platform, there isn't a stop sign
> and there aren't any road markings.  The
> drivers I asked about it weren't sure exactly where it was.  It took a
> lengthy e-mail exchange with the head
> office before they finally admitted the stop existed and told me where
> they expected the drivers to stop.  At first
> it was "No, the bus doesn't stop there." and I had to rub their noses in
> the county council online timetable and
> their own online timetable.  They even tried declaring the whole route to
> be hail and ride, even in the town centre,
> to get around the problem.
>
> BTW, they have a couple of other routes that do similar things. :)
>
> --
> Paul
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread Paul Allen

On Wed, Jun 20, 2018 at 10:24 PM, Jo  wrote:

>
> It's probably best to provide a link to the actual route relation. It's
> indeed a complex one.
>

I'll do it tomorrow.  I had a look earlier today and it was either broken
before I looked or I broke it while trying
to figure out how to use JOSM.  I'll post the link tomorrow after I've
fixed it (or broken it even more).

And yes, it's complicated.  The stop that is ignored the first time but
used the second time is in the timetable
but there isn't a shelter, there isn't a platform, there isn't a stop sign
and there aren't any road markings.  The
drivers I asked about it weren't sure exactly where it was.  It took a
lengthy e-mail exchange with the head
office before they finally admitted the stop existed and told me where they
expected the drivers to stop.  At first
it was "No, the bus doesn't stop there." and I had to rub their noses in
the county council online timetable and
their own online timetable.  They even tried declaring the whole route to
be hail and ride, even in the town centre,
to get around the problem.

BTW, they have a couple of other routes that do similar things. :)

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

Re: [Tagging] public_transport=platform rendering on osm-carto

Le 20. 06. 18 à 21:24, Markus Lindholm a écrit :
> On Tue, 2018-06-19 at 15:13 +, marc marc wrote:
>> Le 19. 06. 18 à 16:30, Daniel Koć a écrit :
>>> I realized that highway=platform is not only marked on wiki as much
>>> less
>>> popular, but is also really 10 times less popular in the database.
>>
>> and for 93 906 highway=platform, 84 031 already have
>> public_transport=platform
>> https://taginfo.openstreetmap.org/tags/highway=platform#combinations
>>
>> this is a subject where it is very difficult to progress,
>> so I advise to do this in 2 steps:
>> check and add missing public_transport=plateform on highway=platform
> 
> What's the point of adding an additional tag that basically conveys the
> same information that's already tagged?

to reduce the uneeded diff between several transport mode.
For the multi-mode platforms, it is even more crying because for the 
moment it is necessary to be university graduate with 3 years of 
practice to maper a rural station which has a common platform between a 
train and a bus in PTv1

> It should be clear by now that there's a considerable part of the
> community that don't consider PTv2 to be a solution to public transport
> tagging

for highway==platform (the subjet of this thread) with
9k highway=plateform without public_transport=platform
versus
900k public_transport=platform without highway=plateform
I'm not sure I see where the considerable rejection of this 
harmonization for THIS tag.
imho the real current usecase of highway=plateform is to bypass
the "no PTv2 render" issue.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

Hi Paul,

It's probably best to provide a link to the actual route relation. It's
indeed a complex one.

Polyglot

Op wo 20 jun. 2018 om 23:11 schreef Paul Allen :

>
> On Wed, Jun 20, 2018 at 7:43 PM, 
> wrote:
>
>> Everything you write is no different between PTv2 and the old tagging
>> scheme.
>>
>>
>>
>> FIRST, all the stops, in order. THEN, all the ways that make up the
>> route, in order.
>>
>>
>>
>> As far as I’m aware, there hasn’t been a route tagging scheme before that
>> mixes the stops into the route before.
>>
>>
>>
>> The actual PTv2 proposal documents that quite well:
>>
>
> OK, at least that is clearer than the working pages of the wiki.  But I'm
> still having difficulty comprehending one thing.
> I have an actual route, and I'll designate segments of ways with letters
> (and simplify it a lot).  Platforms are mapped
> but stop positions aren't (somebody who thinks they shouldn't be there
> cleaned up after me).
>
> A  B  C  D  E  F M  N  B  C  D  E  F
>
> Starts at A, terminates at F.  It repeats B C D E F at the end of the
> route, but doesn't pass A.  There's a stop at A (start
> of the route). There's a stop at C which is ignored the first time the bus
> passes it but is stopped at (on request) the
> second time (and appears in the timetable). It stops at F both times.
>
> So the stops are going to be the ones at  A C F ... C F, in that order, in
> the relation.
>
> It's kinda hard for me to figure out what's going on from the relation,
> and I know the route.  Without stop positions
> it seems to me to be a lot of work for a router to figure out as well.  I
> think a typical consumer using the query tool
> would be completely baffled by the relation info returned.  But you're
> telling me this is correct?  If so, that's what
> I'll do.
>
> --
> Paul
>
> ___
> 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] public_transport=platform rendering on osm-carto

2018-06-20 Thread Paul Allen

On Wed, Jun 20, 2018 at 7:43 PM,  wrote:

> Everything you write is no different between PTv2 and the old tagging
> scheme.
>
>
>
> FIRST, all the stops, in order. THEN, all the ways that make up the route,
> in order.
>
>
>
> As far as I’m aware, there hasn’t been a route tagging scheme before that
> mixes the stops into the route before.
>
>
>
> The actual PTv2 proposal documents that quite well:
>

OK, at least that is clearer than the working pages of the wiki.  But I'm
still having difficulty comprehending one thing.
I have an actual route, and I'll designate segments of ways with letters
(and simplify it a lot).  Platforms are mapped
but stop positions aren't (somebody who thinks they shouldn't be there
cleaned up after me).

A  B  C  D  E  F M  N  B  C  D  E  F

Starts at A, terminates at F.  It repeats B C D E F at the end of the
route, but doesn't pass A.  There's a stop at A (start
of the route). There's a stop at C which is ignored the first time the bus
passes it but is stopped at (on request) the
second time (and appears in the timetable). It stops at F both times.

So the stops are going to be the ones at  A C F ... C F, in that order, in
the relation.

It's kinda hard for me to figure out what's going on from the relation, and
I know the route.  Without stop positions
it seems to me to be a lot of work for a router to figure out as well.  I
think a typical consumer using the query tool
would be completely baffled by the relation info returned.  But you're
telling me this is correct?  If so, that's what
I'll do.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread Markus Lindholm

On Tue, 2018-06-19 at 15:13 +, marc marc wrote:
> Le 19. 06. 18 à 16:30, Daniel Koć a écrit :
> > I realized that highway=platform is not only marked on wiki as much
> > less
> > popular, but is also really 10 times less popular in the database.
> 
> and for 93 906 highway=platform, 84 031 already have 
> public_transport=platform
> https://taginfo.openstreetmap.org/tags/highway=platform#combinations
> 
> this is a subject where it is very difficult to progress,
> so I advise to do this in 2 steps:
> check and add missing public_transport=plateform on highway=platform

What's the point of adding an additional tag that basically conveys the
same information that's already tagged?

"To conform with PTv2" is not a valid answer in my opinion.

It should be clear by now that there's a considerable part of the
community that don't consider PTv2 to be a solution to public transport
tagging

/Markus



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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread Alan Grant

On Wed, 20 Jun 2018, 21:03 marc marc,  wrote:

>
>
> For my part, I have an intermediate/pragmatic position.
> I find that bus=yes on a platform is incoherent.
> but if it is there, I keep it to avoid any ping-pong for this.
>

Yes, I have been doing something similar. Probably influenced by the JOSM
preset which doesn't prompt for transport mode when creating a new
platform. But like you I wouldn't delete it if already there.

I guess my question is whether this affects the proposed rendering. Is the
idea to have a generic platform rendering that is the same for buses,
trams, and trains? From the github page I get the impression that there
will be a specific bus stop rendering, but how can this work if there is no
obligatory tag indicating the transport mode? However I may not be
interpreting the github page correctly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

Le 20. 06. 18 à 20:05, Alan Grant a écrit :
> adding bus=yes or tram=yes to the platform

it's controversial.
some think it is useful to describe the mode of transport served
by this platform.
some think that access tags such as bus=* describe access permission :) 
and therefore adding bus=yes to a platform means that the bus can run on 
your feet.

For my part, I have an intermediate/pragmatic position.
I find that bus=yes on a platform is incoherent.
but if it is there, I keep it to avoid any ping-pong for this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

Le 20. 06. 18 à 19:19, Jo a écrit :
> If v2 of the 'new' scheme means that we have to create 2 objects

You already said that several time in the past but it's still wrong.
You don't HAVE to create 2 objets.
if wou dislike stop_position, don't use it.
you MAY use/create only ONE plateform, that's fine.
but another mapper MAY also use/create a stop_position.
they are 2 different functions (pedestrian <> vehicule routing)

But I still don't understand how your rejection of stop_position
leads you to create 2 objects with *=platform that represents
the same thing.
one "passenger waiting area = 1 plateform in osm",
not 1 node + 1 way + 1 area
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread osm.tagging

Everything you write is no different between PTv2 and the old tagging scheme.

 

FIRST, all the stops, in order. THEN, all the ways that make up the route, in 
order.

 

As far as I’m aware, there hasn’t been a route tagging scheme before that mixes 
the stops into the route before.

 

The actual PTv2 proposal documents that quite well:

 

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant

 

“Each stop is included with two elements (if available): first the  
<https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position> 
stop_position tagged with role stop and immediately followed by the 
corresponding  
<https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform> platform 
tagged with role platform. The stops (stop_positions and platforms) should be 
inserted beginning with the initial stop_position/platform and ending with the 
terminal stop_position/platform. The ordering of the stop positions in the 
relation will determine the direction of the route.

 

…

 

After all the stops all the used ways should be inserted into the relation with 
an empty role. The ways should be inserted beginning with the way at the 
initial stop position and ending with the way at the terminal stop position.”

 

I fully agree that the individual pages for tags are a total mess, mixing 
together information both from previous tagging schemes and PTv2.

 

When evaluating PTv2 and mapping according to it, the actual accepted proposal 
(which I linked above) should be considered normative.

 

If you read through the actual proposal that was accepted, it’s actually pretty 
clear and well structured.

 

All the individual pages should probably be cleaned up, and only and clearly 
contain the information from the PTv2 proposal. That would greatly clear up the 
confusion people seem to have. But I understand that would greatly upset people 
that outright reject PTv2 despite it being newest voted on and accepted 
proposal.

 

 

 

From: Paul Allen  
Sent: Thursday, 21 June 2018 04:21
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] public_transport=platform rendering on osm-carto

 

 

On Wed, Jun 20, 2018 at 6:53 PM, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:
 

So, valid minimal tagging under PTv2 is very simple:

 

You have one node (if there is no clear platform) or a way (along the platform 
edge) or area (the whole platform), which is tagged as 
public_transport=platform (plus whatever mode of transport is served at the 

platform, so bus=yes or tram=yes, or …)

 

Which all sounds fine, until I try to make sense of the relation.  Something 
(or somebody) seems to like

shoving all platforms at the start of the relation, then the ways in order.
Which would work (just) for a routeing
algorithm, if you throw enough CPU at it, but is inefficient.  It also gets 
very confusing when you have a route which is

circuitous and doubles back on part of its earlier route in the same direction, 
causing some stops to be in the

relation twice.  The route I'm thinking of has a stop on that revisited section 
which is NOT used on the first

traversal but IS used on the second.  It's hard to figure out what's going on 
unless the stops appear in the

relation next to their ways rather than all lumped together at the beginning.


And it gets worse.  Suppose I have a simple route, from X to Z with a stop at Y.

  X --- bat street --- o --- cat street --- o --- dog street --- Z

X is at the start of bat street, Z is at the end of dog street.  Y is in the 
middle of cat street, not at either of its 

junctions with the other two streets.

The choices I have for relation ordering (I'm still learning/battling JOSM to 
do it) are X, Y, Z, bat street, cat street,

dog street; or X (which appears to be how it's ordered by default), bat street, 
Y, cat street, dog street, Z;
or X, bat street, cat street, Y, dog street.  None of which make it clear to a 
mapper or consumer what the reality is
without also looking at the map (simple inspection of the data is not enough).  
Or should cat street be split at Y
so I can have X, bat street, cat street 1, Y, cat street 2, dog street, Z?

Or does it simply not matter where the stops appear in the relation?  If not, 
does it even matter what order they're

in?  I would have thought that for efficiency of routeing you'd NEED stop 
positions on highways too, otherwise

there's an extra search outwards from the platform until it finds the way.  Oh, 
and the nearest portion of the

way may not actually be reachable from the platform because of obstacles.

 

I'm confused.  The wiki doesn't seem to make it clear and nor do the tools.  Am 
I entirely missing the point?

Probably.

I would appreciate somebody with a deep understanding of this stuff clarifying 
matters, here or on the wiki.


-- 

Paul

___
Tagging mailing list
Tagging@opens

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread Paul Allen

On Wed, Jun 20, 2018 at 6:53 PM,  wrote:

> So, valid minimal tagging under PTv2 is very simple:
>
>
>
> You have one node (if there is no clear platform) or a way (along the
> platform edge) or area (the whole platform), which is tagged as
> public_transport=platform (plus whatever mode of transport is served at the
>
>
platform, so bus=yes or tram=yes, or …)
>

Which all sounds fine, until I try to make sense of the relation.
Something (or somebody) seems to like
shoving all platforms at the start of the relation, then the ways in order.
   Which would work (just) for a routeing
algorithm, if you throw enough CPU at it, but is inefficient.  It also gets
very confusing when you have a route which is
circuitous and doubles back on part of its earlier route in the same
direction, causing some stops to be in the
relation twice.  The route I'm thinking of has a stop on that revisited
section which is NOT used on the first
traversal but IS used on the second.  It's hard to figure out what's going
on unless the stops appear in the
relation next to their ways rather than all lumped together at the
beginning.

And it gets worse.  Suppose I have a simple route, from X to Z with a stop
at Y.

  X --- bat street --- o --- cat street --- o --- dog street --- Z

X is at the start of bat street, Z is at the end of dog street.  Y is in
the middle of cat street, not at either of its
junctions with the other two streets.

The choices I have for relation ordering (I'm still learning/battling JOSM
to do it) are X, Y, Z, bat street, cat street,
dog street; or X (which appears to be how it's ordered by default), bat
street, Y, cat street, dog street, Z;
or X, bat street, cat street, Y, dog street.  None of which make it clear
to a mapper or consumer what the reality is
without also looking at the map (simple inspection of the data is not
enough).  Or should cat street be split at Y
so I can have X, bat street, cat street 1, Y, cat street 2, dog street, Z?

Or does it simply not matter where the stops appear in the relation?  If
not, does it even matter what order they're
in?  I would have thought that for efficiency of routeing you'd NEED stop
positions on highways too, otherwise
there's an extra search outwards from the platform until it finds the way.
Oh, and the nearest portion of the
way may not actually be reachable from the platform because of obstacles.

I'm confused.  The wiki doesn't seem to make it clear and nor do the
tools.  Am I entirely missing the point?
Probably.

I would appreciate somebody with a deep understanding of this stuff
clarifying matters, here or on the wiki.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

Le 20. 06. 18 à 19:23, osm.tagg...@thorsten.engler.id.au a écrit :
> In places where there was only a highway=bus_stop node, this is often now 
> dual tagged with public_transport=platform as well (which is correct).
> In places where there was only a highway=platform way/area, this is often now 
> dual tagged with public_transport=platform was well (correct too).

I agree, no issue with that

> But in places that have both a highway=platform and a highway=bus_stop, dual 
> tagging both with public_transport=platform is wrong. The two should be 
> merged into only a single way/area with public_transport=platform. The 
> problem then is that you can't really dual tag that anymore, because the 
> highway=platform and highway=bus_stop tags are in direct conflict and can't 
> be tagged on the same object.
> And because the lack of rendering in osm carto, many people are not going to 
> use PTv2 properly in this case, because they can't dual tag it so that it 
> will properly show up on the map.

the best way to handle this with PTv2 and still have something render
is to have highway=platform public_transport=platform on the way
and move the highway=bus_stop public_transport=stop_position on a node
part of the road.
with this, you have only one plateform, one stop_position and no render 
issue.

> Implementing public_transport=platform rendering purely as a 1:1 replacement 
> of highway/railway=platform, without properly supporting it as a replacement 
> of bus_stop, tram_stop, and so on is not going to fix that issue.

Render the most commun used public_transport=platform in stead of the 
old less common used highway=platform is still a improvement I thing.
it 'll not solve the whole mess, but it's a first good/easy step.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread Alan Grant

On 20 June 2018 at 19:53,  wrote:

>
> So, valid minimal tagging under PTv2 is very simple:
>
>
>
> You have one node (if there is no clear platform) or a way (along the
> platform edge) or area (the whole platform), which is tagged as
> public_transport=platform (plus whatever mode of transport is served at the
> platform, so bus=yes or tram=yes, or …)
>
>
>
But adding bus=yes or tram=yes to the platform doesn't seem to be mentioned
on the wiki. These tags are mentioned only for stop_position. Are mappers
expected to know that these tags should be added to platforms? I'm sure I
have mapped lots of bus stops without adding this tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

1. I'm not confused.

2. I don't agree that highway=bus_stop nodes next to the ways should be
'UPGRADED' to ways or areas. We should keep those nodes AND add those nodes
and ONLY those nodes to the route relations.

3. If there happens to be an actual platform, we can keep mapping those as
highway=platform/railway=plattform on a way or area. Those are the ones
where I started to remove the public_transport=platform from.
highway=platform/railway=plattform
is perfectly fine for them.

Op wo 20 jun. 2018 om 19:24 schreef :

> I fully agree with everything marc said.
>
> But I think Jo's confusion comes primarily from the fact that
> public_transport=platform replaces BOTH highway=platform AND
> highway=bus_stop.
>
> So under the old tagging scheme you could have a highway=platform way or
> area, AND a highway=bus_stop node.
>
> In places where there was only a highway=bus_stop node, this is often now
> dual tagged with public_transport=platform as well (which is correct).
>
> In places where there was only a highway=platform way/area, this is often
> now dual tagged with public_transport=platform was well (correct too).
>
> But in places that have both a highway=platform and a highway=bus_stop,
> dual tagging both with public_transport=platform is wrong. The two should
> be merged into only a single way/area with public_transport=platform. The
> problem then is that you can't really dual tag that anymore, because the
> highway=platform and highway=bus_stop tags are in direct conflict and can't
> be tagged on the same object.
>
> And because the lack of rendering in osm carto, many people are not going
> to use PTv2 properly in this case, because they can't dual tag it so that
> it will properly show up on the map.
>
> The lack of rendering support for public_transport=platform *as a
> replacement for highway=bus_stop and similar tags* is what prevents
> widespread adaption of PTv2 and deprecation of the old tagging scheme.
>
> Implementing public_transport=platform rendering purely as a 1:1
> replacement of highway/railway=platform, without properly supporting it as
> a replacement of bus_stop, tram_stop, and so on is not going to fix that
> issue.
>
> > -Original Message-----
> > From: marc marc 
> > Sent: Thursday, 21 June 2018 02:53
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] public_transport=platform rendering on osm-
> > carto
> >
> > Le 20. 06. 18 à 17:44, Jo a écrit :
> > > Actually I have started to remove public_transport=platform from
> > WAYS
> > > with highway=platform and railway=platform. As far as I am
> > concerned
> > > public_transport=platform goes on NODES
> >
> > sorry I didn't understand why (or maybe yes I prefer to not
> > understand) Zverik's propal that you clone to request that
> > public_transport=platform as way should be downgraded to a node-
> > only HAS FAILED !
> > So if another mapper extend the node to better match the geometry
> > of the plateform, why are you revert it ?
> > yes wiki is ambigous. but for almost (?) all objects the extend
> > from a node into a more precise geometry has always been considered
> > an improvement, not a mistkae that need to be fixed.
> > So the next contributor will probably add the PTv2 tags you deleted.
> >
> > > Removing those tags from ways comes from the objection of some
> > people
> > > that there would be both a way and a platform with the
> > > public_transport=platform tag.
> >
> > I remember this talk about that on tranport (french-speaking
> > transit) mailing when it became apparent that duplicate objects
> > were so common in France that they affected stats at a regional
> > scale.
> > This resulted in a collective work to add missing PTv2 tags, many
> > contributors spent many hours for that and fix a lot of mistake.
> > Currently the region of french capital is nearly 100% PTv2 and at
> > the country scale in france, there is almost no highway=plateform
> > tag left that does not also have its PTv2 equivalent.
> >
> > Of course one stop in one direction should have :
> > - only one plateform per "passenger waiting area" (including all
> > variant public_transport=platform highway=platform and
> > railway=platform) and/or
> > - one stop_position
> >
> > having one "passenger waiting area" mapped as a node + as a way + a
> > MP like I already see, with tags randomly distributed or duplicated
> > between these osm objects that represent the same thing, it is a
> > mess
> >
> > and PTv1 tag should of course be put only on one of the same objets.
> >

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread osm.tagging

I fully agree with everything marc said.

But I think Jo's confusion comes primarily from the fact that 
public_transport=platform replaces BOTH highway=platform AND highway=bus_stop.

So under the old tagging scheme you could have a highway=platform way or area, 
AND a highway=bus_stop node.

In places where there was only a highway=bus_stop node, this is often now dual 
tagged with public_transport=platform as well (which is correct).

In places where there was only a highway=platform way/area, this is often now 
dual tagged with public_transport=platform was well (correct too).

But in places that have both a highway=platform and a highway=bus_stop, dual 
tagging both with public_transport=platform is wrong. The two should be merged 
into only a single way/area with public_transport=platform. The problem then is 
that you can't really dual tag that anymore, because the highway=platform and 
highway=bus_stop tags are in direct conflict and can't be tagged on the same 
object.

And because the lack of rendering in osm carto, many people are not going to 
use PTv2 properly in this case, because they can't dual tag it so that it will 
properly show up on the map.

The lack of rendering support for public_transport=platform *as a replacement 
for highway=bus_stop and similar tags* is what prevents widespread adaption of 
PTv2 and deprecation of the old tagging scheme.

Implementing public_transport=platform rendering purely as a 1:1 replacement of 
highway/railway=platform, without properly supporting it as a replacement of 
bus_stop, tram_stop, and so on is not going to fix that issue.

> -Original Message-
> From: marc marc 
> Sent: Thursday, 21 June 2018 02:53
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] public_transport=platform rendering on osm-
> carto
> 
> Le 20. 06. 18 à 17:44, Jo a écrit :
> > Actually I have started to remove public_transport=platform from
> WAYS
> > with highway=platform and railway=platform. As far as I am
> concerned
> > public_transport=platform goes on NODES
> 
> sorry I didn't understand why (or maybe yes I prefer to not
> understand) Zverik's propal that you clone to request that
> public_transport=platform as way should be downgraded to a node-
> only HAS FAILED !
> So if another mapper extend the node to better match the geometry
> of the plateform, why are you revert it ?
> yes wiki is ambigous. but for almost (?) all objects the extend
> from a node into a more precise geometry has always been considered
> an improvement, not a mistkae that need to be fixed.
> So the next contributor will probably add the PTv2 tags you deleted.
> 
> > Removing those tags from ways comes from the objection of some
> people
> > that there would be both a way and a platform with the
> > public_transport=platform tag.
> 
> I remember this talk about that on tranport (french-speaking
> transit) mailing when it became apparent that duplicate objects
> were so common in France that they affected stats at a regional
> scale.
> This resulted in a collective work to add missing PTv2 tags, many
> contributors spent many hours for that and fix a lot of mistake.
> Currently the region of french capital is nearly 100% PTv2 and at
> the country scale in france, there is almost no highway=plateform
> tag left that does not also have its PTv2 equivalent.
> 
> Of course one stop in one direction should have :
> - only one plateform per "passenger waiting area" (including all
> variant public_transport=platform highway=platform and
> railway=platform) and/or
> - one stop_position
> 
> having one "passenger waiting area" mapped as a node + as a way + a
> MP like I already see, with tags randomly distributed or duplicated
> between these osm objects that represent the same thing, it is a
> mess
> 
> and PTv1 tag should of course be put only on one of the same objets.
> If not, you make duplicate objet for the same feature... like
> currently.
> 
> > In other words, the rendering of *=platform on WAYS is just fine
> as it is.
> 
> of course that it is the continuation of Zverik's failed proposal.
> but check current pratice :
> the supremacy of public_transport=platform over highway=platform is
> even clearer if we take into account the duplicate tag 900k for
> public_transport=platform without (highway=platform or
> railway=platform)
> 84k highway=platform + public_transport=platform only 9k
> highway=platform without public_transport=platform the community
> has already twice rejected this unintelligible wish to have a
> PTv2custom with different rules totally useless depending on the
> transport mode.
> PTv2 consists precisely in making things more HOMOGENEOUS.
> So please reconsider your modifications and take into

Re: [Tagging] public_transport=platform rendering on osm-carto

If v2 of the 'new' scheme means that we have to create 2 objects for each
and every bus stop and add both of those to the route relations and
duplicate details across them, then v2 has failed.

We should have exactly 1 object that represents the bus stop. A node next
to the way and only add that node to the route relations.

if there is an actual platform, we can draw a way or an area and tag it
highway=platform/railway=platform. These should not be added to the route
relations.

Neither should the stop_position nodes be added to the route relations, nor
should they get details like name, ref, etc.

So 1 node to represent the bus or tram stops, next to the way on either
side and only add details to those and only add these to the route
relations.

These nodes can get the public_transport=platform tags.

if we can start doing it that way, we will get a way of mapping public
transport that is easy to understand for everyone. If we don't the wiki
will remain murky, unclear and ambiguous.

I rest my case.

Polyglot

Op wo 20 jun. 2018 om 18:53 schreef marc marc :

> Le 20. 06. 18 à 17:44, Jo a écrit :
> > Actually I have started to remove public_transport=platform from WAYS
> > with highway=platform and railway=platform. As far as I am concerned
> > public_transport=platform goes on NODES
>
> sorry I didn't understand why (or maybe yes I prefer to not understand)
> Zverik's propal that you clone to request that public_transport=platform
> as way should be downgraded to a node-only HAS FAILED !
> So if another mapper extend the node to better match the geometry
> of the plateform, why are you revert it ?
> yes wiki is ambigous. but for almost (?) all objects the extend
> from a node into a more precise geometry has always been considered
> an improvement, not a mistkae that need to be fixed.
> So the next contributor will probably add the PTv2 tags you deleted.
>
> > Removing those tags from ways comes from the objection of some people
> > that there would be both a way and a platform with the
> > public_transport=platform tag.
>
> I remember this talk about that on tranport (french-speaking transit)
> mailing when it became apparent that duplicate objects were so common
> in France that they affected stats at a regional scale.
> This resulted in a collective work to add missing PTv2 tags,
> many contributors spent many hours for that and fix a lot of mistake.
> Currently the region of french capital is nearly 100% PTv2 and at the
> country scale in france, there is almost no highway=plateform tag left
> that does not also have its PTv2 equivalent.
>
> Of course one stop in one direction should have :
> - only one plateform per "passenger waiting area" (including all variant
> public_transport=platform highway=platform and railway=platform)
> and/or
> - one stop_position
>
> having one "passenger waiting area" mapped as a node + as a way + a MP
> like I already see, with tags randomly distributed or duplicated between
> these osm objects that represent the same thing, it is a mess
>
> and PTv1 tag should of course be put only on one of the same objets.
> If not, you make duplicate objet for the same feature... like currently.
>
> > In other words, the rendering of *=platform on WAYS is just fine as it
> is.
>
> of course that it is the continuation of Zverik's failed proposal.
> but check current pratice :
> the supremacy of public_transport=platform over highway=platform
> is even clearer if we take into account the duplicate tag
> 900k for public_transport=platform without (highway=platform or
> railway=platform)
> 84k highway=platform + public_transport=platform
> only 9k highway=platform without public_transport=platform
> the community has already twice rejected this unintelligible wish to
> have a PTv2custom with different rules totally useless depending
> on the transport mode.
> PTv2 consists precisely in making things more HOMOGENEOUS.
> So please reconsider your modifications and take into account that
> highway=plateform and public_tramsport=plateform are 2 tags for the same
> concept (a passenger waiting area for a public transport), even if the
> render support only the oldest and less common schema for *=platform
>
> Regards,
> Marc
> ___
> 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] public_transport=platform rendering on osm-carto

Le 20. 06. 18 à 17:44, Jo a écrit :
> Actually I have started to remove public_transport=platform from WAYS 
> with highway=platform and railway=platform. As far as I am concerned 
> public_transport=platform goes on NODES

sorry I didn't understand why (or maybe yes I prefer to not understand)
Zverik's propal that you clone to request that public_transport=platform 
as way should be downgraded to a node-only HAS FAILED !
So if another mapper extend the node to better match the geometry
of the plateform, why are you revert it ?
yes wiki is ambigous. but for almost (?) all objects the extend
from a node into a more precise geometry has always been considered
an improvement, not a mistkae that need to be fixed.
So the next contributor will probably add the PTv2 tags you deleted.

> Removing those tags from ways comes from the objection of some people 
> that there would be both a way and a platform with the 
> public_transport=platform tag.

I remember this talk about that on tranport (french-speaking transit) 
mailing when it became apparent that duplicate objects were so common
in France that they affected stats at a regional scale.
This resulted in a collective work to add missing PTv2 tags,
many contributors spent many hours for that and fix a lot of mistake.
Currently the region of french capital is nearly 100% PTv2 and at the 
country scale in france, there is almost no highway=plateform tag left 
that does not also have its PTv2 equivalent.

Of course one stop in one direction should have :
- only one plateform per "passenger waiting area" (including all variant 
public_transport=platform highway=platform and railway=platform)
and/or
- one stop_position

having one "passenger waiting area" mapped as a node + as a way + a MP 
like I already see, with tags randomly distributed or duplicated between 
these osm objects that represent the same thing, it is a mess

and PTv1 tag should of course be put only on one of the same objets.
If not, you make duplicate objet for the same feature... like currently.

> In other words, the rendering of *=platform on WAYS is just fine as it is.

of course that it is the continuation of Zverik's failed proposal.
but check current pratice :
the supremacy of public_transport=platform over highway=platform
is even clearer if we take into account the duplicate tag
900k for public_transport=platform without (highway=platform or 
railway=platform)
84k highway=platform + public_transport=platform
only 9k highway=platform without public_transport=platform
the community has already twice rejected this unintelligible wish to 
have a PTv2custom with different rules totally useless depending
on the transport mode.
PTv2 consists precisely in making things more HOMOGENEOUS.
So please reconsider your modifications and take into account that 
highway=plateform and public_tramsport=plateform are 2 tags for the same 
concept (a passenger waiting area for a public transport), even if the 
render support only the oldest and less common schema for *=platform

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

Re: [Tagging] public_transport=platform rendering on osm-carto

2018-06-20 Thread osm.tagging

>From my reading of the wiki (I wasn’t involved when PTv2 was designed), the 
>situation as envisioned in PTv2 would be that you have only one node, way, or 
>area with public_transport=platform. So the existing highway=bus_stop and 
>highway=platform (in cases where both are present) are merged into a single 
>public_transport=platform (on the way or area that currently is the 
>highway=platform, and the highway=bus_stop goes away completely).

 

But this requires proper rendering support. That is, the way or area should be 
rendered like highway=platform was, AND it should render an icon in the middle 
of the way like highway=bus_stop did. Because public_transport=platform 
replaces both of these.

 

Trying to see and implement public_transport=platform only as a 1:1 replacement 
for existing highway=platform and/or railway=platform is going to make the 
situation worse, not better.

 

From: Jo  
Sent: Thursday, 21 June 2018 01:45
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] public_transport=platform rendering on osm-carto

 

Actually I have started to remove public_transport=platform from WAYS with 
highway=platform and railway=platform. As far as I am concerned 
public_transport=platform goes on NODES next to the ways in combination with 
highway=bus_stop or railway=tram_stop.

 

Removing those tags from ways comes from the objection of some people that 
there would be both a way and a platform with the public_transport=platform tag.

 

In other words, the rendering of *=platform on WAYS is just fine as it is.

 

Polyglot

 

 

Op wo 20 jun. 2018 om 17:02 schreef Daniel Koć mailto:daniel@ko%C4%87.pl> >:

W dniu 19.06.2018 o 17:40, osm.tagg...@thorsten.engler.id.au 
<mailto:osm.tagg...@thorsten.engler.id.au>  pisze:
> But I do not think that it is reasonable to add rendering for it, and at the 
> same moment drop rendering for highway=platform, railway=platform, 
> highway=bus_stop, railway=tram_stop and everything else that 
> public_transport=platform is meant to replace.
>
> This absolutely needs to be a two step process. Add rendering for 
> public_transport=platform first, then let people work on migrating existing 
> data. At some point in the future it might then become possible to drop 
> rendering for existing tags.

I want to make just one step now - replace *=platform with
public_transport=platform. Next steps might be very different and i
don't see them clearly now. It might even need PTv3 - I don't know, so I
won't touch it.

We could of course migrate by adding new type and removing old ones
after some time and I would do it. However on osm-carto we have a strong
opposition to rendering multiple similar tags (fear of fragmentation),
so I prefer to start with announcing the planned change and then make
the switch in rendering. It's just a different way of migration and if
it won't create (unnecessary in this case) tension and makes the whole
thing more probable to happen, I vote for it.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

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

Re: [Tagging] public_transport=platform rendering on osm-carto