Hi Christian, Am 28.03.2018 um 16:21 schrieb "Christian Müller": > In your proposal you complain about subjectively felt things like "history > won't go away", but at the same time you are trying to revert a part of > history itself - "the public_transport tags are seven years old now". Many > people were involved creating those tags, they are well understood and > discriminate the features they describe in a thoroughly documented and > plausible way. > > Just because a lot of deprecated tags have not vanished in favor of the new > ones yet does not mean there is a preference on the deprecated tags. A lot > of users and apps have adopted the new public_transport tags. It simply does > not make any sense to do a rollback on these for the observation of a > sluggish adoption/transition rate. > > The proposal has been long thought about and delivers, in itself, a coherent > way of tagging public transport infrastructure. It has learned from previous > tags, it is thus a refinement of the previous tagging. There will be lots of > people -unheared and not- that oppose breaking a (slow moving) transition > process at this point in time. Just be patient and give it some more years.
I am in favour of PTv2 but have to admit that PTv2 is a great example how proposals can fail. I joined OSM a few months after PTv2 was adopted and started using it in 2014. The reasons for its failure are: - PTv2 has a long and detailed proposal page but after the proposal was accepted, it was only documented on the proposal page for a long time while many other pages (some might still do) explained the old schema. - If someone propose a tagging schema which is not just a new tag or a few new tags but includes a new type of relation (stop areas, routes which contain stops etc.), he should provide a application which demonstrates the usage and/or serves as validator. That did not happen. Adding support for that type of relation to at least one widely used data consumer tool like Osm2pgsql will make more users use the data (currently you have to rely on the slim tables of Osm2pgsql which is a hack because they are not considered to be stable). - If someone writes such a complicated proposal, he should ask the authors of map styles (if he isn't someone himself) for their opinion on the new tags. public_transport=stop_position/platform isn't easy to render without taking highway=bus_stop into account because (1) platforms do not have to be tagged with bus/tram/train/subway=yes and because you do not have to map both the platform and the stop. If you render only stop positions or only platforms, you will miss features in some areas. If you render both, you will have duplicated map icons. Checking if there are nearby features, does not work as good as manual selection (I wrote my own SQL queries to group stops and platforms to form stations in the past – it doesn't work very good). - The proposal was not understood by significant parts of the community. Many mappers think that highway=bus_stop and railway=station/halt/tram_stop are deprecated and use them because some important applications do not use public_transport=*. (see the quoted posting above) However, they aren't. All in all, I would like to thank Ilya for investing time into this topic even if I do not agree with him on all questions and do not like some parts of his approach (change tagging in foreign cities using non-local staff which does not declare its affiliation). Best regards Michael PS This email was written before I read the new proposal by Ilya. -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
