Re: [Talk-transit] Making bus lines more specific

[Phake Nick]

在 2020年4月28日週二 20:45，Robin Däneke  寫道：

> Because the discussion of this thread already ran into the direction of
> changing different aspects about the tagging, I used it for the general
> discussion. If we refine the buses, it could go hand in hand with
> everything else. I’d be interested in which refinements would be needed
> there as part of my general suggestion. But in my current WIP-suggestion
> the „bus=yes,tram=yes“ should not be necesarry, only a route relation type
> for each mean of transport.
>

??? "Because the discussion of this thread already ran into the direction
of changing different aspects about the tagging, I used it for the general
discussion. "??? Your reply was literally the second one in the thread that
hijacked it and directed everyone's attention away from the original topic,
and the feature in your WIP are also irrelevant to the bus type refinement
that was being suggested.


> If I could get a list of types of buses, I could think about how to do
> this.
> Idealy, we leave the „route=bus“ and then add another sub_tag group bus=*
> or bus_type=*. Then the generalized „bus" would still be valid but the
> specification would be available if needed...
>
> Should I open a new thread for the general discussion?
>

Congratulations you have already hijacked this thread successfully and
turned this thread into a thread for general discussion that have nothing
to do with the original topic.


> KR
> RobinD
>
> Am 28.04.2020 um 14:34 schrieb Phake Nick :
>
> Excuse me, I am a bit lost on how refining bus stop/station/platform tags
> will help resolving the issue of making bus route tagging more specific,
> and differentiate between different rype of bus services, which is the
> topic of this email thread?
>
> 在 2020年4月28日週二 15:45，Robin Däneke  寫道：
>
>> Hello everybody,
>>
>> I have lately been thinking about somehow reworking (or giving a new push
>> to) the current p_t:v2 scheme.
>> Especially for the fact, that, since it was first proposed and accepted,
>> not a lot has changed in which tags are rendered, how certain things are
>> hence mapped and the Wiki-Pages on the topic have also changed in the last
>> years without any visible going through another proposal process.
>>
>> When I started mapping in 2011, and first read the german and then the
>> english p:t:v2 wiki pages, it was:
>> - highway=bus_stop is a legacy tag that should eventually be completely
>> phased out
>> - stop positions and platforms are to be both mapped
>> and some other things I already forgot…
>> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
>> platform nodes. The point of the public_transport tags is, among other
>> points, to replace less dedicated highway tags.
>> I think it would be time for a p_t:v2.5 proposal, where we take the
>> innicial ideas of the v2, maybe refine a few small details (like is
>> stop_position required, or just platforms, can relations of route-parts be
>> used in route relations to save on redundancy…) and then put it forward for
>> voting. If accepted, we would possibly now have more leverage to get the
>> editor and render-programers to actually properly implement it this time
>> around.
>>
>> Maybe I could find some time to write my suggestions into a document, and
>> we could collect the ideas for those extra tags in there too. I think it
>> would make more sense that way, than just the addition of a few tags to the
>> current scheme, to then be ignored by the rest of OSM once again.
>>
>> Kind Regards
>> Robin D. (emergency99)
>>
>>
>> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
>> ways, even relations, highway=bus_stop can only be a node. This old tag
>> should go the same way as the farm tag, which was (forcefully) abandoned a
>> couple of years back. There it worked, why not for the „new“ p_t scheme?
>>
>> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
>> gbragaal...@gmail.com>:
>> >
>> > I read your responses and I tend to agree that the opening_hours tag is
>> enough to characterize services that are only operated during peak hours.
>> >
>> > On the other hand, it seems to me that there is also agreement on the
>> relevance of having tags to differentiate bus services.
>> >
>> > How can we expand this debate and expand this discussion? It may be
>> interesting for other members of the list to speak out, and then we can
>> create or redeem a proposal for implementing new tags.
>> >
>> > P.S .: I don't know if this message will enter the reply queue
>> correctly; I hope I'm not opening a new topic. I apologize for my
>> inexperience with maillists.
>> > ___
>> > Talk-transit mailing list
>> > Talk-transit@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
> 

Re: [Talk-transit] Making bus lines more specific

[Tijmen Stam]

Hello Robin,

I highly agree with you.
The main reason for PTv2 not having as widespread adoption as it could 
have is that it is not rendered, that is to say, it is not rendered on 
OSM_carto (Osmand's rendering of PTv2 is near-perfect).


However, we're stuck with a rendering "committee" that for years have 
delayed the rendering of PTv2 based on not having the right 
[rendering]datamodel, and now that we have that datamodel, they 
basically say "I oppose the PTv2" and closed all pull requests asking 
for it in may 2019.


See my comment on 
https://github.com/gravitystorm/openstreetmap-carto/pull/3232#issuecomment-491007730


Tijmen / IIVQ





On 28-04-20 13:36, Robin Däneke wrote:
Any tag we could come up with is going to be a partial misnomer for what 
we are trying to model in the Database. In OSM, there are lots of those…


highway=bus_stop on the side of the road is somewhat trivially 
understandable, but that means we need railway=tram_stop, 
railway=train_stop, waterway=ferry_stop and many other tags too, that 
could all be made redundand by the „platform“ node/way/relation being in 
a route relation that is that mean of transport.


The wonderful thing about databases is, that a lot of info kan be given 
on relational levels and inherited by all relation members. We can make 
a bunch of tags redundant by using one. And platform is the most 
truthful there. In Vienna, the Networks (Verkehrsverbunde) are working 
on only having bus stops, that have a visible, higher laying „platform“ 
(or some sort of sidewalk area) at each stop, and I can only imagine, 
the more public_transport gets, the more a bus stop is going to be the 
platform. I think we should not be tagging backwards here.


The pole is a part of the stop, but never „the stop“ itself, even if 
some people tend to see it that way. Alternatively, call it 
public_transport=stop. That would mean one area where pt stops. Then 
that would be the same as a platform, unless it is a node, when that is 
possibly just the pole. But for that, a useful micro-mapping tag 
„public_transport=pole“ would make much more sense, once again then not 
needing bus=yes,tram=yes or something like „bus_stop_pole“ „tram_stop_pole“…


This merging hw=bus_stop, rw=tram_stop into one platform or stop tag 
will make the database much more lean. And in terms of highway=bus_stop 
is difficult to remove: As this tag is the same as the platform (except 
if it is a node connected to a street, then that is a „stop_position" 
and can just be deleted) you could get one mechanical edit to take care 
f it (after getting it approved by the community and/or DWG) So that tag 
is the easiest to just purge from what it’s counterpart in p_t:v2 is!


A stop/platform node on the side of the road does the same, so this is 
just redundancy, and as platform is the more versatile tag, it should 
take precedence in this „tag-fight“.


Thanks for all the input.

KR
RobinD

Am 28.04.2020 um 12:20 schrieb Tony OSM >:


I like node highway=bus_stop for the reasons polyglot gives. bus_stop 
is here to stay cos there are too many to change, by the side of the 
highway they give directionality depending on the customary side of 
the road for driving.


public_transport=platform works well for train and some trams. To me a 
platform is a construct to assist people to get on or off the 
transport vehicle. As a waiting area  - that use is secondary.


In GB some authorities are raising the area around a bus stop to 
enable wheelchair users easier access to buses - so yes a platform tag 
is appropriate, but not for a pole placed in the ground or pedestrian 
part of the road which is the default for buses where I live.


stop_position node - to me has no function - for buses their stop 
position is the bus stop;  for trains they stop at the platform; where 
I live we have 2,3,4,5,6 car trains, the front of the train stops at 
one of two defined positions depending on the number of cars.


Simplification of PTV2 may be helpful, but I have had no strong 
frustrations when using it.


Regards

TonyS999


On 28/04/2020 09:46, Jo wrote:

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. 
(OK, it's not a highway and my preference is to map it next to the 
highway)



public_transport=platform

was designed at first to not need a mode of transport like 
bus=yes/tram=yes. I am the one who proposed adding it, so that it 
COULD start replacing highway=bus_stop back in 2012.


There is not always a platform present, so it's a bit of a misnomer 
as well.


Anyway, someone who wants to render a bus stop ideally wants to look 
at a single tag, not a combination of 2, apparently. For a long time 
it was supposedly a technical problem, but as soon as that was 
resolved somewhere around 2017, it was still considered problematic 
to look at 2 tags.


I wish you good luck with 

Re: [Talk-transit] Making bus lines more specific

[Tijmen Stam]

I have long ago proposed an addition to the PTv2 "route" schedule, which 
is the "formula" tag. Formula's would be defined within a network (or 
within a nation). For example, in the Netherlands, almost every 
transport network has so-called "buurtbus", litterally "neighbourhood 
bus" although they often run for 30-50 km, in areas too sparsely 
populated for a regular bus. They are driven by volunteers and other 
than it being an 8-person-vehicle, they operate like a normal bus. You 
have to pay, they run a fixed route and timetable.


Next to that, we have several transport authorities demanding the brand 
"R·NET" for faster public transport services.


But then some companies have within their branded network several 
formulas. For example, in the area I work for, the company (Connexxion, 
a subsidary of Transdev) has branded itself as "Overal" (Everywhere) and 
has several lines under formulas as "Buurtbus", "Overal Flex" 
(dial-a-ride on fixed routes and times), "Overal Taxi" (reduced tariff 
taxi), "Texelhopper" (island-specific dial-a-ride).


So I guess this key/value can be used for bus lines like you mean.
Alternatively, a key "brt=yes" can be added. I think the term BRT is 
sufficiently well-known worldwide that is has become something of a 
standard, although what would count as BRT in one area will be the 
lowest quality of buses in others, so it's up to the local transit 
authority to label their bus routes as BRT.

Tijmen / IIVQ

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Sorry, I sent this mail only to Dave, sending it to the list for reference too.



> -It is a current, valid tag that's more detailed, clear, precise & more 
> popular than PTv2 equivalent.

That needs 100 other tags in other tagging families to make any sense, and 
hence helps to clutter up the database. I feel like many forget: OSM is not a 
map, it is a database. And sidenote: there are axioms/rules on what not to do 
in a database. OSM is the best example for any of those. 

> Platforms should only be mapped if there's a clear, raised section of 
> pavement for boarding a bus/tram. In OSM we map the physical world.

More and more stops have these. If we do not want the platform to be a simple 
way to say „public transport stops here“ but as this „real world“ definition, 
then that should be only even used when micro mapping, not as a general tag, 
but it is used as a general tag, so your definition is just not the tag 
definition, as that would not be allowed to be a node then...

> highway=bus_stop is far more "dedicated" than public_transport=platform which 
> require further tags to clarify.

if relations are correctly used (as they should be in a database) no 
elaborating tag is needed on the single platform.

> Oh dear.
> PTv2 was sold as a complete schema, fully formed with no requirements for 
> amendments, yet there are these frequent proposals to tweak.

Because no one shouted at each mapper that didn’t adopt the voted for scheme, 
so many kept mapping in old ways or mixed it wrongly. Also, the old tags were 
kept carefully instead of booting them out when they shuld have left the 
dataset 9 years ago. Now that we have the problem, we should solve it and not 
be so ignorant and conservative of the mixed bag of screw-up that this has 
become. 

> PTv2 adds nothing but extra tags & confusion. It runs in parallel to a schema 
> which has worked well since the OSMs inception. 

To me, the singular highway=bus_stop nodes that were strewn across the 
countryside, on the side of many roads with no name tags, no relations and 
nothing else, has not worked in the slightest. It worked as much, if not less, 
than how p_t:v2 could work if everybody would have moved to it in 2010.

Public transport is a complex topic. It is surely not as easy as mapping 
„amenity=waste_basket“ or „highway=street_lamp“. It has it’s complex sides, and 
especially because of that there should not be 100 low level tags to determine 
the type of something but rather one easy-to-map general one (for buses, trams, 
trains, boats, aerialways… alike) to map the area where people wait (as this is 
ALWAYS the same thing, a platform in one valid sense) and deal with what stops 
there in the more complex part (relations), without which, public_transport 
mapping is useless and could be stopped instantly.

> Time to drop it completely.

No, public_transport is its own category that deserves its own tags. Especially 
as the railway=* tags have quite a lot of technical and operational sub-tags, 
that have nothing to do with passenger transit. We should definitely have an 
own category for the, to most people important kind of transport. Disconnected 
from more technical tagging families.

That is my rational here.

Whatever I come up with (and will ask for constructive critisism about here) in 
the future shall be, what p_t:v2 didn’t even try to be. The p_t-community made, 
small attempts at best to make it „the solution“ it was supposed to be. I am 
fighting with this inbetween state since that scheme came into existence. Could 
we please finally fix it, and then have it properly accepted (maybe with 
technical aid of OSMF/DWG) almost 10 years later? Is that truely much to ask 
for?

KR
RobinD

PS: In public transport, there are some things (like routes) that make sense in 
the database, but do not, as such, exist physically. The „we map the real 
world“ is such an outdated view. The world of relevant geo-referenced data has 
become to big to just map trash cans and trees. Because the OSM wouldn’t be 
much more, if not also some theoretical concepts would have made it into it. I 
am sure we could discuss the definition of what a building is, how a company is 
a „real“ thing or whatever, but that would be besides this topic.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Dave F via Talk-transit]

On 28/04/2020 08:45, Robin Däneke wrote:

Hello everybody,

I have lately been thinking about somehow reworking (or giving a new push to) 
the current p_t:v2 scheme.
Especially for the fact, that, since it was first proposed and accepted, not a 
lot has changed in which tags are rendered, how certain things are hence mapped 
and the Wiki-Pages on the topic have also changed in the last years without any 
visible going through another proposal process.

When I started mapping in 2011, and first read the german and then the english 
p:t:v2 wiki pages, it was:
- highway=bus_stop is a legacy tag that should eventually be completely phased 
out


It is a current, valid tag that's more detailed, clear, precise & more 
popular than PTv2 equivalent.



- stop positions and platforms are to be both mapped


Platforms should only be mapped if there's a clear, raised section of 
pavement for boarding a bus/tram. In OSM we map the physical world.



and some other things I already forgot…
Now, iD has a rule in its verifyer, that requires highway=bus_stop on platform 
nodes. The point of the public_transport tags is, among other points, to 
replace less dedicated highway tags.


highway=bus_stop is far more "dedicated" than public_transport=platform 
which require further tags to clarify.



I think it would be time for a p_t:v2.5 proposal,


Oh dear.
PTv2 was sold as a complete schema, fully formed with no requirements 
for amendments, yet there are these frequent proposals to tweak.


PTv2 adds nothing but extra tags & confusion. It runs in parallel to a 
schema which has worked well since the OSMs inception. Time to drop it 
completely.


DaveF

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Because the discussion of this thread already ran into the direction of 
changing different aspects about the tagging, I used it for the general 
discussion. If we refine the buses, it could go hand in hand with everything 
else. I’d be interested in which refinements would be needed there as part of 
my general suggestion. But in my current WIP-suggestion the „bus=yes,tram=yes“ 
should not be necesarry, only a route relation type for each mean of transport. 

If I could get a list of types of buses, I could think about how to do this.
Idealy, we leave the „route=bus“ and then add another sub_tag group bus=* or 
bus_type=*. Then the generalized „bus" would still be valid but the 
specification would be available if needed...

Should I open a new thread for the general discussion?

KR
RobinD

> Am 28.04.2020 um 14:34 schrieb Phake Nick :
> 
> Excuse me, I am a bit lost on how refining bus stop/station/platform tags 
> will help resolving the issue of making bus route tagging more specific, and 
> differentiate between different rype of bus services, which is the topic of 
> this email thread?
> 
> 在 2020年4月28日週二 15:45，Robin Däneke  > 寫道：
> Hello everybody,
> 
> I have lately been thinking about somehow reworking (or giving a new push to) 
> the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted, not 
> a lot has changed in which tags are rendered, how certain things are hence 
> mapped and the Wiki-Pages on the topic have also changed in the last years 
> without any visible going through another proposal process.
> 
> When I started mapping in 2011, and first read the german and then the 
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely 
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on 
> platform nodes. The point of the public_transport tags is, among other 
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the innicial 
> ideas of the v2, maybe refine a few small details (like is stop_position 
> required, or just platforms, can relations of route-parts be used in route 
> relations to save on redundancy…) and then put it forward for voting. If 
> accepted, we would possibly now have more leverage to get the editor and 
> render-programers to actually properly implement it this time around.
> 
> Maybe I could find some time to write my suggestions into a document, and we 
> could collect the ideas for those extra tags in there too. I think it would 
> make more sense that way, than just the addition of a few tags to the current 
> scheme, to then be ignored by the rest of OSM once again. 
> 
> Kind Regards
> Robin D. (emergency99)
> 
> 
> PS: The problem with bus_stop on platform: platforms can be nodes, lines, 
> ways, even relations, highway=bus_stop can only be a node. This old tag 
> should go the same way as the farm tag, which was (forcefully) abandoned a 
> couple of years back. There it worked, why not for the „new“ p_t scheme?
> 
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves  > >:
> > 
> > I read your responses and I tend to agree that the opening_hours tag is 
> > enough to characterize services that are only operated during peak hours.
> > 
> > On the other hand, it seems to me that there is also agreement on the 
> > relevance of having tags to differentiate bus services.
> > 
> > How can we expand this debate and expand this discussion? It may be 
> > interesting for other members of the list to speak out, and then we can 
> > create or redeem a proposal for implementing new tags.
> > 
> > P.S .: I don't know if this message will enter the reply queue correctly; I 
> > hope I'm not opening a new topic. I apologize for my inexperience with 
> > maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-transit 
> > 
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-transit 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Phake Nick]

Excuse me, I am a bit lost on how refining bus stop/station/platform tags
will help resolving the issue of making bus route tagging more specific,
and differentiate between different rype of bus services, which is the
topic of this email thread?

在 2020年4月28日週二 15:45，Robin Däneke  寫道：

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Any tag we could come up with is going to be a partial misnomer for what we are 
trying to model in the Database. In OSM, there are lots of those…

highway=bus_stop on the side of the road is somewhat trivially understandable, 
but that means we need railway=tram_stop, railway=train_stop, 
waterway=ferry_stop and many other tags too, that could all be made redundand 
by the „platform“ node/way/relation being in a route relation that is that mean 
of transport.

The wonderful thing about databases is, that a lot of info kan be given on 
relational levels and inherited by all relation members. We can make a bunch of 
tags redundant by using one. And platform is the most truthful there. In 
Vienna, the Networks (Verkehrsverbunde) are working on only having bus stops, 
that have a visible, higher laying „platform“ (or some sort of sidewalk area) 
at each stop, and I can only imagine, the more public_transport gets, the more 
a bus stop is going to be the platform. I think we should not be tagging 
backwards here.

The pole is a part of the stop, but never „the stop“ itself, even if some 
people tend to see it that way. Alternatively, call it public_transport=stop. 
That would mean one area where pt stops. Then that would be the same as a 
platform, unless it is a node, when that is possibly just the pole. But for 
that, a useful micro-mapping tag „public_transport=pole“ would make much more 
sense, once again then not needing bus=yes,tram=yes or something like 
„bus_stop_pole“ „tram_stop_pole“…

This merging hw=bus_stop, rw=tram_stop into one platform or stop tag will make 
the database much more lean. And in terms of highway=bus_stop is difficult to 
remove: As this tag is the same as the platform (except if it is a node 
connected to a street, then that is a „stop_position" and can just be deleted) 
you could get one mechanical edit to take care f it (after getting it approved 
by the community and/or DWG) So that tag is the easiest to just purge from what 
it’s counterpart in p_t:v2 is!

A stop/platform node on the side of the road does the same, so this is just 
redundancy, and as platform is the more versatile tag, it should take 
precedence in this „tag-fight“.

Thanks for all the input.

KR 
RobinD

> Am 28.04.2020 um 12:20 schrieb Tony OSM :
> 
> I like node highway=bus_stop for the reasons polyglot gives. bus_stop is here 
> to stay cos there are too many to change, by the side of the highway they 
> give directionality depending on the customary side of the road for driving.
> 
> public_transport=platform works well for train and some trams. To me a 
> platform is a construct to assist people to get on or off the transport 
> vehicle. As a waiting area  - that use is secondary.
> 
> In GB some authorities are raising the area around a bus stop to enable 
> wheelchair users easier access to buses - so yes a platform tag is 
> appropriate, but not for a pole placed in the ground or pedestrian part of 
> the road which is the default for buses where I live. 
> 
> stop_position node - to me has no function - for buses their stop position is 
> the bus stop;  for trains they stop at the platform; where I live we have 
> 2,3,4,5,6 car trains, the front of the train stops at one of two defined 
> positions depending on the number of  cars.
> 
> Simplification of PTV2 may be helpful, but I have had no strong frustrations 
> when using it.
> 
> Regards
> 
> TonyS999
> 
> 
> 
> On 28/04/2020 09:46, Jo wrote:
>> The basic objection they voice is why need 2 tags, if 1 does the job.
>> 
>> highway=bus_stop
>> 
>> is not exactly nonsensical. It's concise and expresses what is meant. (OK, 
>> it's not a highway and my preference is to map it next to the highway)
>> 
>> 
>> public_transport=platform
>> 
>> was designed at first to not need a mode of transport like bus=yes/tram=yes. 
>> I am the one who proposed adding it, so that it COULD start replacing 
>> highway=bus_stop back in 2012.
>> 
>> There is not always a platform present, so it's a bit of a misnomer as well.
>> 
>> Anyway, someone who wants to render a bus stop ideally wants to look at a 
>> single tag, not a combination of 2, apparently. For a long time it was 
>> supposedly a technical problem, but as soon as that was resolved somewhere 
>> around 2017, it was still considered problematic to look at 2 tags.
>> 
>> I wish you good luck with proposing another way of mapping public transport. 
>> Many have tried before you. It's really hard to beat status quo. And the 
>> status quo is not the same across the planet. If you can propose something 
>> that is both simpler, more elegant and still expressive enough for all 
>> usecases, I'll vote yes on it.
>> 
>> Polyglot
>> 
>> On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke > > wrote:
>> Indeed, these are good points. I would say, that the „platform“ is enough. 
>> This could then mean either the „stop pole“ of the station (which I would 
>> not say is the most important piece as 

Re: [Talk-transit] Making bus lines more specific

[Tony OSM]

I like node highway=bus_stop for the reasons polyglot gives. bus_stop is 
here to stay cos there are too many to change, by the side of the 
highway they give directionality depending on the customary side of the 
road for driving.


public_transport=platform works well for train and some trams. To me a 
platform is a construct to assist people to get on or off the transport 
vehicle. As a waiting area  - that use is secondary.


In GB some authorities are raising the area around a bus stop to enable 
wheelchair users easier access to buses - so yes a platform tag is 
appropriate, but not for a pole placed in the ground or pedestrian part 
of the road which is the default for buses where I live.


stop_position node - to me has no function - for buses their stop 
position is the bus stop;  for trains they stop at the platform; where I 
live we have 2,3,4,5,6 car trains, the front of the train stops at one 
of two defined positions depending on the number of cars.


Simplification of PTV2 may be helpful, but I have had no strong 
frustrations when using it.


Regards

TonyS999


On 28/04/2020 09:46, Jo wrote:

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. 
(OK, it's not a highway and my preference is to map it next to the 
highway)



public_transport=platform

was designed at first to not need a mode of transport like 
bus=yes/tram=yes. I am the one who proposed adding it, so that it 
COULD start replacing highway=bus_stop back in 2012.


There is not always a platform present, so it's a bit of a misnomer as 
well.


Anyway, someone who wants to render a bus stop ideally wants to look 
at a single tag, not a combination of 2, apparently. For a long time 
it was supposedly a technical problem, but as soon as that was 
resolved somewhere around 2017, it was still considered problematic to 
look at 2 tags.


I wish you good luck with proposing another way of mapping public 
transport. Many have tried before you. It's really hard to beat status 
quo. And the status quo is not the same across the planet. If you can 
propose something that is both simpler, more elegant and still 
expressive enough for all usecases, I'll vote yes on it.


Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke > wrote:


Indeed, these are good points. I would say, that the „platform“ is
enough. This could then mean either the „stop pole“ of the station
(which I would not say is the most important piece as that could
also just be a sticker on a shelter or a lamp post) close but not
at the station (sadly there are big inconsequent uses in real
life), or the area of the visible platform, if applicable.

But the rest of the community will have to accept the death of
(old) tags, when it is voted for. If this mailing list could come
up with a proposal most users here could live with, we all vote
for it (with the spelling of the end to certain tags) and it is
accepted that way, the community will have to accept that. The
first iteration was just to „nice“ to that conservative fraction.
Public transport can be complex, but this is why it needs
dedicated (own, simple) tags instead of legacy nonsense.

This is, why I would be happy to have many people work on this
„ideal“ solution, that is simple on the one hand, but powerful on
the other hand. I will make a Document where I put in my personal
critique and goal for a new scheme, and am then looking forward to
input on it. Will share it here when I have a framework of what
the current scheme says and have some changes in it. Then, the
specifying of the bus lines, the simplifying of the bus stations
(so that one or two tags can replace bus_stop but still do the
same thing functionally) and other points could be put in there.
Maybe we actually end up with a useful consensus, that one could
propose.

The more people get on board, the more acceptable it can become...

KR
RobinD


Am 28.04.2020 um 10:07 schrieb Jo mailto:winfi...@gmail.com>>:

For years and years we have tried to convince the people working
on carto, our default rendering to start supporting
public_transport=platform/bus=yes instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to
drop public_transport=platform on the bus stop nodes, but that's
not straightforward either anymore,, since the editor software
started to depend on them.

stop_position nodes, I have never considered them to be
important, so I never mapped them for ALL the stops. I do map
them for initial and terminus stops, was I want to split the way
there anyway. What I will definitely not do, the way I see it
done in 

Re: [Talk-transit] Making bus lines more specific

[Jo]

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. (OK,
it's not a highway and my preference is to map it next to the highway)


public_transport=platform

was designed at first to not need a mode of transport like
bus=yes/tram=yes. I am the one who proposed adding it, so that it COULD
start replacing highway=bus_stop back in 2012.

There is not always a platform present, so it's a bit of a misnomer as well.

Anyway, someone who wants to render a bus stop ideally wants to look at a
single tag, not a combination of 2, apparently. For a long time it was
supposedly a technical problem, but as soon as that was resolved somewhere
around 2017, it was still considered problematic to look at 2 tags.

I wish you good luck with proposing another way of mapping public
transport. Many have tried before you. It's really hard to beat status quo.
And the status quo is not the same across the planet. If you can propose
something that is both simpler, more elegant and still expressive enough
for all usecases, I'll vote yes on it.

Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke  wrote:

> Indeed, these are good points. I would say, that the „platform“ is enough.
> This could then mean either the „stop pole“ of the station (which I would
> not say is the most important piece as that could also just be a sticker on
> a shelter or a lamp post) close but not at the station (sadly there are big
> inconsequent uses in real life), or the area of the visible platform, if
> applicable.
>
> But the rest of the community will have to accept the death of (old) tags,
> when it is voted for. If this mailing list could come up with a proposal
> most users here could live with, we all vote for it (with the spelling of
> the end to certain tags) and it is accepted that way, the community will
> have to accept that. The first iteration was just to „nice“ to that
> conservative fraction. Public transport can be complex, but this is why it
> needs dedicated (own, simple) tags instead of legacy nonsense.
>
> This is, why I would be happy to have many people work on this „ideal“
> solution, that is simple on the one hand, but powerful on the other hand. I
> will make a Document where I put in my personal critique and goal for a new
> scheme, and am then looking forward to input on it. Will share it here when
> I have a framework of what the current scheme says and have some changes in
> it. Then, the specifying of the bus lines, the simplifying of the bus
> stations (so that one or two tags can replace bus_stop but still do the
> same thing functionally) and other points could be put in there.
> Maybe we actually end up with a useful consensus, that one could propose.
>
> The more people get on board, the more acceptable it can become...
>
> KR
> RobinD
>
> Am 28.04.2020 um 10:07 schrieb Jo :
>
> For years and years we have tried to convince the people working on carto,
> our default rendering to start supporting public_transport=platform/bus=yes
> instead of highway=bus_stop.
>
> They have clearly stated that this will never happen. Conclusion:
> highway=bus_stop is NOT a legacy tag.
>
> That's my conclusion anyway. In Belgium I'm even considering to drop
> public_transport=platform on the bus stop nodes, but that's not
> straightforward either anymore,, since the editor software started to
> depend on them.
>
> stop_position nodes, I have never considered them to be important, so I
> never mapped them for ALL the stops. I do map them for initial and terminus
> stops, was I want to split the way there anyway. What I will definitely not
> do, the way I see it done in Germany is to duplicate information.
>
> I want to have a single object, preferably a node, that has all the
> details of the stop AND I want to include this object in the route
> relations. 1 object per stop, so not a sequence of
> stop_position/platform/stop_position/platform.
>
> As I don't consider the stop_position nodes to be important enough to map
> them everywhere I don't put name/ref/ etc on them. In Belgium most
> stop_position nodes will have only 1 extra tag, the mode of transport.
>
> For me it's an advantage that highway=bus_stop can only be used on a node.
> I want to map the object that represents the bus stop as a node anyway,
> next to the highway on the side where the passengers wait.
>
> If there is a physical platform, then it makes sense to map it as a way or
> a closed_way/area. In that case it gets highway=platform and possibly
> tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
> repetition of name,ref,route_ref,operator,network, etc.
>
> If there is to be a next version of how we map public transport we should
> think about making it simpler. What I see in Germany is way too complicated
> and error prone, as information is duplicated across objects.
>
> Polyglot
>
>
>
>
> On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

Re: [Talk-transit] Making bus lines more specific

[Jo]

For years and years we have tried to convince the people working on carto,
our default rendering to start supporting public_transport=platform/bus=yes
instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to drop
public_transport=platform on the bus stop nodes, but that's not
straightforward either anymore,, since the editor software started to
depend on them.

stop_position nodes, I have never considered them to be important, so I
never mapped them for ALL the stops. I do map them for initial and terminus
stops, was I want to split the way there anyway. What I will definitely not
do, the way I see it done in Germany is to duplicate information.

I want to have a single object, preferably a node, that has all the details
of the stop AND I want to include this object in the route relations. 1
object per stop, so not a sequence of
stop_position/platform/stop_position/platform.

As I don't consider the stop_position nodes to be important enough to map
them everywhere I don't put name/ref/ etc on them. In Belgium most
stop_position nodes will have only 1 extra tag, the mode of transport.

For me it's an advantage that highway=bus_stop can only be used on a node.
I want to map the object that represents the bus stop as a node anyway,
next to the highway on the side where the passengers wait.

If there is a physical platform, then it makes sense to map it as a way or
a closed_way/area. In that case it gets highway=platform and possibly
tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
repetition of name,ref,route_ref,operator,network, etc.

If there is to be a next version of how we map public transport we should
think about making it simpler. What I see in Germany is way too complicated
and error prone, as information is duplicated across objects.

Polyglot




On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
>