@Polyglot:
I do think you are thinking to much of software that uses the date rather than
of the mappers and the database. For both of those, it is better to habe less
objects to contend with (mapper) and less objects with potentially redundant
values/positions (database). The fact that maybe a
The target of OSM is to map physical objects, however, a node that is
„highway=bus_stop“ is not really a physical object. You could say it is the
station pole, but what if there is no station pole, as the schedule is mounted
on the wall of a house or inside a shelter, or just doesn‘t exist to
Why does all the info need to be in one node and not on a way? Also, if there
is a platform, it should be a polygon, not just a line. That should not be to
micro to be mapped in true dimensions. If that object is the true only thing
that defines the stop, it should be able to have the tags in
When the platform is a really existing built thing, you would need
highway=platform on it, and an additional highway=bus_stop at the stop pole or
wherever. That is more clutter and worse state of the database, than if we
would finally move to the more versatile public_transport=platform. As it
Yes, one object would be nice, however, I think it should be versatile enough
to be able to be a node, line or polygon.
So basically what public_transport=platform is.
I also don't mind it being called "platform", even if there is only a pole
stuck in a field.
That would not make p_t:v2 mapping
I think someone in this discussion is confusing the idea of a new scheme with
the current one.
As it stands, the highway=bus_stop tag is a legacy tag for a node. If the
platform is a node, it can be put on there (for legacy sake, although the
p_t:v2 scheme suggests to sunset that tag) but if
Hello everyone,
I will briefly jump into this conversation, as I have mapped quite a few bus
routes in and around vienna, austria, and amended most Stops there to fit the
definitions of the pt:v2 from the wiki.
In my view, it would, at least for bus stops, be enough if there was a (bus)
stop
Hi,
I would also be OK with only the stop in the relation (with all tags possible
(Way 1) or as Way 2 (see below)) and the other aspects just as additional
pieces, however, a bit of redundance could be there to make the platform and
relations also human-readable. I know, people dealing with
