Re: [Tagging] Documentation issues of PT tagging schemes

2018-08-04 Thread Jo
Hi Roland,

I made a fresh attempt to explain things as simple as it gets:

https://wiki.openstreetmap.org/wiki/User:Polyglot/Public_transport_proposal_for_simplification

I might expand this to how I see we could extend this tram and metro
mapping. For trains I would add such nodes for each sub section of a
platform, if there are trains (or parts of trains) that use only 'half a
platform', but I realise that is likely to be met with a lot of resistance.

For mapping the millions of bus stops and itineraries around the world, we
need a schema that is as simple as possible (and no simpler, like you
said). Any unnecessary complication/duplication simply doesn't scale.

I read your proposal, and you talk about platform_edges. No need for that
if there is a node for each direction of travel, even if the (separately
mapped) platform is shared in the middle of the railway lines. Such
platform are very likely to have names like platform 2 for one half, and
platform 3 for the other half.

Polyglot

Op wo 25 jul. 2018 om 19:25 schreef Roland Olbricht :

> Hi,
>
> > What I would like to see is how to map a Public Transport Route in
> > version 3 .. that has the bear minimum of things to have and the rules
> > that make the route valid.
>
> This is where the problem sits; the point of view of what a route is
> vary wildly. Few people are even willing to pinpoint and tell their
> personal definition.
>
> Things that exist under the notion of route:
>
> - Urban bus/tram/subway services (many stops, many departures, route
> taken always or almost always the same, route through the street grid
> practically fixed, often unchanged for years to decades)
>
> - Peak services, special routes to depot, school services (few
> departures, many stops, also many route variants, frequently changing,
> making it impractical to route them all)
>
> - Hail bus services: the bus is promised to serve a certain street and
> stops on hail (many departures, route taken always or almost always the
> same, route through the street grid practically fixed, often unchanged
> for years to decades)
>
> - Urban and regional train lines (many stops, many departures, route and
> platforms fixed). Those routes are often in parts or completely land marks.
>
> - Long distance train lines (many stops, many departures, route and
> platforms may or may not vary, can stop at a different platform of the
> same station for operational reasons)
>
> - Long distance bus services (few stops, few departures, route between
> stops often changing on the fly)
>
> - Ferry lines (often only two stops, completely different
> infrastructure)
>
> Further kinds of routes may exist. For example, some communties use
> virtual metro lines that connect station node to station node. This is
> most often because the communties lack the ressources to map the actual
> underground structures.
>
> I personally map only urban bus/tram/subway services and urban and
> regional train lines (and do not delete other routes). For these
> services it is sane to have marked the stops and the route on the grid.
>
> The route on the grid is straightforward: this is in any PT scheme a
> sequence of way members that together form a continuous trajectory. Hail
> sections get a special role for these members.
>
> The stop part is more tricky. I personally add one element for each stop
> where the bus/train is calling, using the role "platform". The member
> element should have the tag "name" set to ensure meaningful usage and
> pain-free editing of the route.
>
> The minimum required tags on the relation are "ref=",
> somtimes "name=", and "type=route" + "route=bus" for buses.
>
> Please do not forget that a more detailed explaination fits better on
> the transit list
> https://lists.openstreetmap.org/listinfo/talk-transit
> I would suggest to continue the discussion there, but Ilya has for
> unknown reason fear of the talk-transit list. It makes sense to give him
> an easy opportunity to answer.
>
> I read Ilya's proposal such that he wants to feature the virtual metro
> lines, at the expense of mandating to map hail services as empty
> relations. But it would be better if he tells us himself.
>
> Best regards,
> Roland
>
> ___
> 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] Documentation issues of PT tagging schemes

2018-07-25 Thread Roland Olbricht

Hi,

What I would like to see is how to map a Public Transport Route in 
version 3 .. that has the bear minimum of things to have and the rules 
that make the route valid.


This is where the problem sits; the point of view of what a route is 
vary wildly. Few people are even willing to pinpoint and tell their 
personal definition.


Things that exist under the notion of route:

- Urban bus/tram/subway services (many stops, many departures, route 
taken always or almost always the same, route through the street grid 
practically fixed, often unchanged for years to decades)


- Peak services, special routes to depot, school services (few 
departures, many stops, also many route variants, frequently changing, 
making it impractical to route them all)


- Hail bus services: the bus is promised to serve a certain street and 
stops on hail (many departures, route taken always or almost always the 
same, route through the street grid practically fixed, often unchanged 
for years to decades)


- Urban and regional train lines (many stops, many departures, route and 
platforms fixed). Those routes are often in parts or completely land marks.


- Long distance train lines (many stops, many departures, route and 
platforms may or may not vary, can stop at a different platform of the 
same station for operational reasons)


- Long distance bus services (few stops, few departures, route between 
stops often changing on the fly)


- Ferry lines (often only two stops, completely different
infrastructure)

Further kinds of routes may exist. For example, some communties use 
virtual metro lines that connect station node to station node. This is 
most often because the communties lack the ressources to map the actual 
underground structures.


I personally map only urban bus/tram/subway services and urban and 
regional train lines (and do not delete other routes). For these 
services it is sane to have marked the stops and the route on the grid.


The route on the grid is straightforward: this is in any PT scheme a 
sequence of way members that together form a continuous trajectory. Hail 
sections get a special role for these members.


The stop part is more tricky. I personally add one element for each stop 
where the bus/train is calling, using the role "platform". The member 
element should have the tag "name" set to ensure meaningful usage and 
pain-free editing of the route.


The minimum required tags on the relation are "ref=", 
somtimes "name=", and "type=route" + "route=bus" for buses.


Please do not forget that a more detailed explaination fits better on 
the transit list

https://lists.openstreetmap.org/listinfo/talk-transit
I would suggest to continue the discussion there, but Ilya has for 
unknown reason fear of the talk-transit list. It makes sense to give him 
an easy opportunity to answer.


I read Ilya's proposal such that he wants to feature the virtual metro 
lines, at the expense of mandating to map hail services as empty 
relations. But it would be better if he tells us himself.


Best regards,
Roland

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


Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-25 Thread Dave F



On 25/07/2018 05:58, Roland Olbricht wrote:

Hi,

This would not be the bells and whistles method, but the bread and 
water method. The basics that would have the routing working and the 
map displaying things.


See
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop


I see fundamental problems in the third paragraph. As is says 
public_transport=platform & highway=bus_stop are representing the same 
entity, then it's duplication of data, which leads to confusion & 
errors, and tagging incorrectly for the renderer.



and
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform


And similar here in the first paragraph.


public_transport=platform appears superfluous as there are existing & 
widely used tags to "identify the places where passengers board or 
alight from public transport"


PTv2 schema made the mistake of trying to create an all-encompassing 
Venn diagram like circle around existing transport entities. It's claim 
that "This proposal extends the existing and well known tags" turned out 
to be incorrect. It just repeats them. Duplication is not the way to do it.





Both wiki pages are up to date and pretty prefect. "Up to date" means 
that more than 90% of all public transport objects are mapped that way.


From a semantic way, it would only be necessary to drop a few words for
- tram stops without a platform
- subway stations: if the underground structure is not known then you 
should map at least "railway=station" + "name=" and all entrances

And a decent mapping scheme would be complete.


Bottom line: Nobody, really nobody needs relations of type stop_area, 
stop_area_group, route_master, network, and stop_position information.


I agree, but if public_transport=platform & public_transport=station are 
also redundant, what's left? If all public_transport tags are removed 
will anybody be unable to create routing?


Cheers
DaveF



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


Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-24 Thread Roland Olbricht

Hi,

This would not be the bells and whistles method, but the bread and water 
method. The basics that would have the routing working and the map 
displaying things.


See
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
and
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform

Both wiki pages are up to date and pretty prefect. "Up to date" means 
that more than 90% of all public transport objects are mapped that way.


From a semantic way, it would only be necessary to drop a few words for
- tram stops without a platform
- subway stations: if the underground structure is not known then you 
should map at least "railway=station" + "name=" and all entrances

And a decent mapping scheme would be complete.

I have written routers for passengers, routers for the operators, a 
route display tool

https://overpass-api.de/public_transport.html
and a JOSM plugin for editing public transport. Bottom line: Nobody, 
really nobody needs relations of type stop_area, stop_area_group, 
route_master, network, and stop_position information.


This is also the thing I do not like about the proposal: it is again 
cluttered with also that complexity, mixing the important with the 
unimportant and the commonplace with the obscure.


The upside is: public transport is in a much better state than all the 
discussion contributions suggest. Public transport operators from five 
continents are now voluntarily using OpenStreetMap data for a wide range 
of purposes, because it is good enough to do so.


For discussing details I suggest the relevant mailing list
https://lists.openstreetmap.org/listinfo/talk-transit
It is purely about public transport and has some hundreds of 
subscribers. On this mailing list "tagging" here, between golf courses 
and detached houses relatively few people will find this discussion in 
the long run.


Best regards,
Roland

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


Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-24 Thread Warin

Hi,

As part of the proposal .. I think  a document on how to map PTv3 in the 
simplest most basic way needs to be done.

This would not be the bells and whistles method, but the bread and water 
method. The basics that would have the routing working and the map displaying 
things.

It needs to be done for at least trains and buses. Some would like ferries too.


That would demonstrate how easy PTv3 would be for mappers to map,
without going through the documentation for the extra features that actually 
don't help the routing.

On 25/07/18 00:56, Leo Gaspard wrote:


Hi Ilya,

I unfortunately won't be anywhere near Milan anytime soon, but thanks
for the invitation :)

The problem I can see with your proposal is that it appears to be based
on PTv1, not on PTv2, which looks much more logical to me (even though I
still don't understand it completely). I mean, there are 8 tags in your
proposal for “Stops and Stations”, whereas if I try to adapt marginally
PTv2 I would get to public_transport=platform, bus=yes / tram=yes / ...
; which sounds more consistent and easy to use both for the mapper and
for the data consumer. Same issue with 5 tags for “platforms”.

Basically, I feel like (without anything to prove my point) just
reordering and rewording the documentation for PTv2 (by explicitly
marking some elements as “optional if the mapper feels like mapping
them” and not talking about things that were done once) and maybe minor
changes would be enough for a huge boost in usability of PTv2, without
needing to rollback to PTv1 :) (again, I don't know what I'm talking
about, but the feeling I had from PTv2 is that it tried to unify tagging
so that it's easier to both remember and programmatically use, and the
feeling I have from your current specification is that it's not really
unified)


On 07/24/2018 11:32 PM, Ilya Zverev wrote:

Hi Leo,

As a person who tried for many years not to touch any public transport in OSM 
because of hard to understand tagging, I share your pain about missing 
tutorials and instructions. The situation with these is a bit better in the 
Russian part of wiki, because we don't have hordes of mappers eager to bikeshed 
every explanation.

The title of the proposal is a bit misfortunate. It is not a new schema that coexists 
with previous two. On the contrary, it (if accepted) will be the single reference schema 
that data processors and validators would be built against. The version is misleading, 
and I think I should've taken on SK53's suggestion to rename it to e.g. "Refined 
Public Transport Tagging".

What the proposal really is is a clarification of what PTv1/2 elements really 
mean and how and when to use them. I refrained from wording it as a tutorial, 
because the last time I did that, I've got a lot of rage over every tiny thing. 
Some people here are still angry at me for that. Proposals are not tutorials.

I hope this answers your points 1-5. If you read the new proposal carefully, you'll 
notice that unlike the previous proposals, it spends many words explaining reasons behind 
every decision. It also makes mapping routes simple, while keeping options for 
micromapping (see the "Examples" section).

PTv1 will never vanish, because we didn't have it in the first place. It was just a pile 
of tags (like highway=bus_stop) which everybody understood and which did not form a 
coherent "schema", and route relations that were basically collections of 
everything related to a route.

PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
mapping. It failed with many mappers like you (and me), because it was based on 
industry standards, which are very sensible, but imply a state-of-art editing 
system behind them. Mapping a route in PTv2 is like writing a GTFS feed in the 
Notepad.

The new proposal is about shedding off all the complexity, and leaving only 
elements required for using stops and routes. Once (if) it is accepted, it 
would be very easy to write a tutorial, because then you would be able to learn 
it gradually. First with collecting bus_stop nodes in a relation, then with 
platforms, and so on. The new proposed schema is flexible, which means you 
don't have to learn all of it to map a proper route. I believe that will 
attract many new mappers to add their public transport routes.

Thank you for your opinion, and I would very much like to discuss how can we 
make mapping routes simpler. If you're in Milan these holidays, come to my talk 
on Sunday morning, and look for a public transport BoF meeting, most likely on 
Monday.

Ilya


24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):

My point of view, as a beginner in OSM who still hasn't understood how
PTv1 and PTv2 are supposed to work (and thus didn't read this specific
proposal, take this as generic comments on PT tagging in OSM):

1. Beginners are already at a loss, introducing a third (!) tagging
scheme will just make things worse

2. If I were developer of an OSM tool, I'd be facepalming 

Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Leo Gaspard
Hi Ilya,

I unfortunately won't be anywhere near Milan anytime soon, but thanks
for the invitation :)

The problem I can see with your proposal is that it appears to be based
on PTv1, not on PTv2, which looks much more logical to me (even though I
still don't understand it completely). I mean, there are 8 tags in your
proposal for “Stops and Stations”, whereas if I try to adapt marginally
PTv2 I would get to public_transport=platform, bus=yes / tram=yes / ...
; which sounds more consistent and easy to use both for the mapper and
for the data consumer. Same issue with 5 tags for “platforms”.

Basically, I feel like (without anything to prove my point) just
reordering and rewording the documentation for PTv2 (by explicitly
marking some elements as “optional if the mapper feels like mapping
them” and not talking about things that were done once) and maybe minor
changes would be enough for a huge boost in usability of PTv2, without
needing to rollback to PTv1 :) (again, I don't know what I'm talking
about, but the feeling I had from PTv2 is that it tried to unify tagging
so that it's easier to both remember and programmatically use, and the
feeling I have from your current specification is that it's not really
unified)


On 07/24/2018 11:32 PM, Ilya Zverev wrote:
> Hi Leo,
> 
> As a person who tried for many years not to touch any public transport in OSM 
> because of hard to understand tagging, I share your pain about missing 
> tutorials and instructions. The situation with these is a bit better in the 
> Russian part of wiki, because we don't have hordes of mappers eager to 
> bikeshed every explanation.
> 
> The title of the proposal is a bit misfortunate. It is not a new schema that 
> coexists with previous two. On the contrary, it (if accepted) will be the 
> single reference schema that data processors and validators would be built 
> against. The version is misleading, and I think I should've taken on SK53's 
> suggestion to rename it to e.g. "Refined Public Transport Tagging".
> 
> What the proposal really is is a clarification of what PTv1/2 elements really 
> mean and how and when to use them. I refrained from wording it as a tutorial, 
> because the last time I did that, I've got a lot of rage over every tiny 
> thing. Some people here are still angry at me for that. Proposals are not 
> tutorials.
> 
> I hope this answers your points 1-5. If you read the new proposal carefully, 
> you'll notice that unlike the previous proposals, it spends many words 
> explaining reasons behind every decision. It also makes mapping routes 
> simple, while keeping options for micromapping (see the "Examples" section).
> 
> PTv1 will never vanish, because we didn't have it in the first place. It was 
> just a pile of tags (like highway=bus_stop) which everybody understood and 
> which did not form a coherent "schema", and route relations that were 
> basically collections of everything related to a route.
> 
> PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
> mapping. It failed with many mappers like you (and me), because it was based 
> on industry standards, which are very sensible, but imply a state-of-art 
> editing system behind them. Mapping a route in PTv2 is like writing a GTFS 
> feed in the Notepad.
> 
> The new proposal is about shedding off all the complexity, and leaving only 
> elements required for using stops and routes. Once (if) it is accepted, it 
> would be very easy to write a tutorial, because then you would be able to 
> learn it gradually. First with collecting bus_stop nodes in a relation, then 
> with platforms, and so on. The new proposed schema is flexible, which means 
> you don't have to learn all of it to map a proper route. I believe that will 
> attract many new mappers to add their public transport routes.
> 
> Thank you for your opinion, and I would very much like to discuss how can we 
> make mapping routes simpler. If you're in Milan these holidays, come to my 
> talk on Sunday morning, and look for a public transport BoF meeting, most 
> likely on Monday.
> 
> Ilya
> 
>> 24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):
>>
>> My point of view, as a beginner in OSM who still hasn't understood how
>> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
>> proposal, take this as generic comments on PT tagging in OSM):
>>
>> 1. Beginners are already at a loss, introducing a third (!) tagging
>> scheme will just make things worse
>>
>> 2. If I were developer of an OSM tool, I'd be facepalming as soon as I
>> saw the word “PTv3”
>>
>> 3. What is *really* needed is a clarification of what PTv[12] actually
>> mean. This is first and foremost a documentation issue, not a tagging
>> scheme issue.
>>
>> 4. If I understood correctly, it's possible to use PTv2 with as few
>> tags as PTv1, but noone really understands it because the documentation
>> is such a mess. So I think a proposal of “Clarification of the relative
>> importance of tags 

Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-24 Thread Leo Gaspard
On 07/24/2018 11:17 PM, Jo wrote:
> The whole point of wanting to move to a simpler tagging scheme is to become
> able to write simple to understand documentation.

From what I understood (so, second-hand information) PTv2 can be used
with as few objects and tags as PTv1, so it's not inherently more
complex. However, it allows more things to be tagged. Putting these
“more things” in small font at the end of the wiki page would be enough
to have a simple, yet complete documentation, and leave people who like
PTv2 the ability to tag complex things :)

> Dropping the "v1" tags that some like to call 'deprecated' is not possible,
> because then your stops don't render.

Honestly… proposal, mass-edit, renderers (that will have had a say in
the discussion, obviously, but I don't think they wouldn't welcome a
reduction of the number of tagging schemes) will be forced to adapt, done.

There seems to be strong resistance in OSM against re-tagging and
mass-edits, but in this special case, so long as it can be done in a
loss-less way, I couldn't understand how all data consumers and all
mappers (interested in having newcomers understand the documentation)
wouldn't agree.

So long as there will be 2+ tagging schemes in operation it'll not be
possible to have a simple documentation, and things will be a mess.

> Replacing highway=bus_stop by public_transport=platform doesn't work
> either, as you lose the information about the mode of transport,
> bus=yes/tram=yes.

https://wiki.openstreetmap.org/wiki/Public_transport seems to mention
that `highway=bus_stop` could be relatively well replaced by
`public_transport=platform, highway=bus_stop` (so just adding
`public_transport=platform`? Then again I don't understand what is PTv1
and what is PTv2 and what is a mix of “people actually do that” in this
page).

I personally don't care if “PT” is not exactly PTv2 but a mix of PTv1
and PTv2. All I care about is having clear guidelines, and I've been
told PTv2 is basically more featureful than PTv1 but still allowing
simple mapping, so PTv2 looks like the thing to use to me.

Then, once this “PT” tagging scheme would have been documented,
incremental improvements could be proposed to it, like having `bus=yes`
/ `tram=yes` tags on platforms or whatever.

All I'm saying is that *before* changing the way we tag, we should first
document clearly what people currently do and make the Grand Public
Transport Unification happen.

> Dropping the public_transport tags on stops seems somewhat more
> straightforward, but isn't completely either. (For example, I don't like
> stop_position nodes and won't add them everywhere, but I had started to add
> them where the itineraries terminate).

Maybe in my list I inverted stop_position and platform, I don't know.
But such a “simplify the documentation” effort would have to decide
which one is important and which one is not, and then make it explicit
so that everyone can tag just the important one and forget the
non-important one if they don't feel like it.

> We're stuck.

Until there is a clearly documented reasonably usable **unambiguous**
tagging scheme, then I agree with you, unfortunately. And a mass edit
would likely help for tools to be able to become *much* simpler by
handling only one tagging scheme and not trying to support 2,5 tagging
schemes :)

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


Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Ilya Zverev
Hi Leo,

As a person who tried for many years not to touch any public transport in OSM 
because of hard to understand tagging, I share your pain about missing 
tutorials and instructions. The situation with these is a bit better in the 
Russian part of wiki, because we don't have hordes of mappers eager to bikeshed 
every explanation.

The title of the proposal is a bit misfortunate. It is not a new schema that 
coexists with previous two. On the contrary, it (if accepted) will be the 
single reference schema that data processors and validators would be built 
against. The version is misleading, and I think I should've taken on SK53's 
suggestion to rename it to e.g. "Refined Public Transport Tagging".

What the proposal really is is a clarification of what PTv1/2 elements really 
mean and how and when to use them. I refrained from wording it as a tutorial, 
because the last time I did that, I've got a lot of rage over every tiny thing. 
Some people here are still angry at me for that. Proposals are not tutorials.

I hope this answers your points 1-5. If you read the new proposal carefully, 
you'll notice that unlike the previous proposals, it spends many words 
explaining reasons behind every decision. It also makes mapping routes simple, 
while keeping options for micromapping (see the "Examples" section).

PTv1 will never vanish, because we didn't have it in the first place. It was 
just a pile of tags (like highway=bus_stop) which everybody understood and 
which did not form a coherent "schema", and route relations that were basically 
collections of everything related to a route.

PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
mapping. It failed with many mappers like you (and me), because it was based on 
industry standards, which are very sensible, but imply a state-of-art editing 
system behind them. Mapping a route in PTv2 is like writing a GTFS feed in the 
Notepad.

The new proposal is about shedding off all the complexity, and leaving only 
elements required for using stops and routes. Once (if) it is accepted, it 
would be very easy to write a tutorial, because then you would be able to learn 
it gradually. First with collecting bus_stop nodes in a relation, then with 
platforms, and so on. The new proposed schema is flexible, which means you 
don't have to learn all of it to map a proper route. I believe that will 
attract many new mappers to add their public transport routes.

Thank you for your opinion, and I would very much like to discuss how can we 
make mapping routes simpler. If you're in Milan these holidays, come to my talk 
on Sunday morning, and look for a public transport BoF meeting, most likely on 
Monday.

Ilya

> 24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):
> 
> My point of view, as a beginner in OSM who still hasn't understood how
> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
> proposal, take this as generic comments on PT tagging in OSM):
> 
> 1. Beginners are already at a loss, introducing a third (!) tagging
> scheme will just make things worse
> 
> 2. If I were developer of an OSM tool, I'd be facepalming as soon as I
> saw the word “PTv3”
> 
> 3. What is *really* needed is a clarification of what PTv[12] actually
> mean. This is first and foremost a documentation issue, not a tagging
> scheme issue.
> 
> 4. If I understood correctly, it's possible to use PTv2 with as few
> tags as PTv1, but noone really understands it because the documentation
> is such a mess. So I think a proposal of “Clarification of the relative
> importance of tags in Public Transportation tagging” would be great.
> 
> 5. Such a proposal would “just” improve the documentation for PTv2 and
> erase completely any reference to PTv1 from the wiki (or move it to a
> “historic tagging scheme, no longer to be used, but that could be
> necessary to understand for consumers until the migration has ended”
> section)
> 
> 6. I personally spent at least half an hour (didn't count) trying to
> understand how to tag public transportation. After having tried to read
> the wiki, I just ragequit. The *documentation* is the issue for public
> transport, and adding a third tagging scheme will only make things worse.
> 
> 7. Once the documentation about PTv1 will have vanished and about PTv2
> will be clear (and once the names PTv* will have disappeared to just be
> called “PT tagging”, in order to be less frightening for the beginner),
> *then* it would be interesting to discuss incremental modifications of
> the PT scheme. I guess that's where the changes you're proposing for
> “PTv3” (something that I think should not ever happen, would it be just
> for its name) would be interesting to integrate.
> 
> 8. For my desiderata about the documentation, I think it should:
> 1. Be simple to read
> 2. Go from the simplest tagging elements to the most complex. For
> example, if I understood correctly PTv2 (ie. likely not), something like:
> 1. 

Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Jo
The whole point of wanting to move to a simpler tagging scheme is to become
able to write simple to understand documentation.

Dropping the "v1" tags that some like to call 'deprecated' is not possible,
because then your stops don't render.
Replacing highway=bus_stop by public_transport=platform doesn't work
either, as you lose the information about the mode of transport,
bus=yes/tram=yes.

Dropping the public_transport tags on stops seems somewhat more
straightforward, but isn't completely either. (For example, I don't like
stop_position nodes and won't add them everywhere, but I had started to add
them where the itineraries terminate).

We're stuck.

When PT_Assistant stabilizes and becomes usable with josm_tested.jar, I'll
create some videos on what I consider to be "reasonable practices". That
will be in about 3 weeks, normally.

Polyglot

Op di 24 jul. 2018 om 15:56 schreef Leo Gaspard :

> My point of view, as a beginner in OSM who still hasn't understood how
> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
> proposal, take this as generic comments on PT tagging in OSM):
>
>  1. Beginners are already at a loss, introducing a third (!) tagging
> scheme will just make things worse
>
>  2. If I were developer of an OSM tool, I'd be facepalming as soon as I
> saw the word “PTv3”
>
>  3. What is *really* needed is a clarification of what PTv[12] actually
> mean. This is first and foremost a documentation issue, not a tagging
> scheme issue.
>
>  4. If I understood correctly, it's possible to use PTv2 with as few
> tags as PTv1, but noone really understands it because the documentation
> is such a mess. So I think a proposal of “Clarification of the relative
> importance of tags in Public Transportation tagging” would be great.
>
>  5. Such a proposal would “just” improve the documentation for PTv2 and
> erase completely any reference to PTv1 from the wiki (or move it to a
> “historic tagging scheme, no longer to be used, but that could be
> necessary to understand for consumers until the migration has ended”
> section)
>
>  6. I personally spent at least half an hour (didn't count) trying to
> understand how to tag public transportation. After having tried to read
> the wiki, I just ragequit. The *documentation* is the issue for public
> transport, and adding a third tagging scheme will only make things worse.
>
>  7. Once the documentation about PTv1 will have vanished and about PTv2
> will be clear (and once the names PTv* will have disappeared to just be
> called “PT tagging”, in order to be less frightening for the beginner),
> *then* it would be interesting to discuss incremental modifications of
> the PT scheme. I guess that's where the changes you're proposing for
> “PTv3” (something that I think should not ever happen, would it be just
> for its name) would be interesting to integrate.
>
>  8. For my desiderata about the documentation, I think it should:
>  1. Be simple to read
>  2. Go from the simplest tagging elements to the most complex. For
> example, if I understood correctly PTv2 (ie. likely not), something like:
>  1. how to place public_transport=stop_position
>  2. how to make a route relation
>  3. how to make a master route relation
>  4. how to add public_transport=platform for people who feel like
> it
>  3. Fit in a single page (having to switch back and forth between
> dozens of pages for PT is just impossible to do while keeping focus)
>  4. Potentially, *at the end, once all important concepts will have
> been explained*, link to pages of individual transportation methods
>  5. Be written in a didactic style. Currently it's full of “There
> was this for a long time, and also that and that, but that is made
> possible by PTv2”. BUT WHAT SHOULD I DO? (sorry, that's not to be read
> yelling, just my internal thoughts when reading this kind of
> paragraphs). That's just not how we can make people do something, that's
> just a way to mix up everyone's mind but the minds of people who
> actively designed the scheme.
>  6. Give instructions as for what to do when the information is
> incomplete (eg. I saw a few stops but not the full route, but I've got a
> picture of the list of stations, what should I do?)
>
> Again, these are my 2¢ as a beginner who tried to understand the current
> way of tagging PT and just didn't understand it enough to try actually
> mapping with it. Also, obviously, I can say how I would want the page to
> be, but I can't do it myself because I just didn't manage to understand
> in a reasonable amount of time the PT tagging scheme. So I'll have to
> rely on you (yes, thou who readeth me) to write it, sorry!
>
>
> On 07/20/2018 10:48 PM, Ilya Zverev wrote:
> > Hi folks,
> >
> > As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot