Re: [Tagging] Documentation issues of PT tagging schemes
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
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
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
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
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)
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
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)
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)
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
[Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)
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 of redundant concepts. > We've seen a couple proposals aiming to fix some of issues, but nothing stuck. > > Please consider this new revision for the PT schema, which addresses most of > the issues, while keeping as backward compatible as possible: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3 > > I'd be happy to hear any suggestions. Next week, I'll be presenting it, among > other things, during my talk "What's up with the public transport" at the > State of the Map conference. > > Thanks, > Ilya > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
