On 02/02/2011 04:13 PM, Richard Mann wrote:
On Wed, Feb 2, 2011 at 12:12 PM, Michał Borsuk<[email protected]> wrote:
On 01/27/2011 06:56 PM, ant wrote:
3) Whether there should be a new public_transport key, to try to
clarify the bus_stop/tram_stop distinction
a) aim to move tram_stops to alongside the track, and put something
else (tram_stop_group / tram_station?) on the track
b) aim to move bus_stops onto the road, and put something else
(platform?) alongside
c) encourage the use of platforms on tram systems, and use those in
the relation instead of tram_stop
d) add a new public_transport key, so that public_transport=platform
can be used for everything
c and d (we shouldn't redefine tags that are in million-times use!)
c. with pole *or* platform. Ideally there would be some degree of
compatibility between tram stops and bus stops, i.e. a pair of tags on each
side that are at least compatible to a degree.
If you do this, the line-diagram code won't work, and no-one seems to
know how to fix it. For the code to work, you apparently need to use
railway=tram_stop nodes as members of the relation with role=stop.
Unless it can be fixed, I'd probably go for (a). The tool is too
useful to ignore.
+0.5: If I got the history of OSM correctly, it was once common to put
bus stops on the way, and at some point it was changed; hence I would
expect that to work for tram stops as well. I consider that unlikely to
break any application in use today - and if it does, that application
most likely has a solution for bus stops, which I expect could easily be
applied to tram stops. So far I agree.
I don't quite agree about placing something else on the track: The
position on the track can be determined with standard GIS functions:
take the stop, find the way with the lowest ST_Distance(stop,way), then
for that way do ST_Line_Locate_Point(way,stop). Wrap that into
ST_Line_Interpolate_Point to get a POINT geometry representing the stop
on the way.
Hence, in most cases the extra node on the way is what I call courtesy
tagging - it makes things easier for the renderer (less preprocessing)
but can be automated. I would tend towards manual tagging only in those
cases in which heuristics are likely to produce incorrect or
unpredictable results (e.g. bus stop in the middle between two
carriageways).
For the remaining cases - maybe someone comes up with a standard OSM
preprocessor which can be run against a database and adds these courtesy
tags where they are not present yet - or, even better, offers a
preprocessed planet.osm with all these courtesy tags applied. I guess
that would calm down the discussion about the necessity of certain tags:
we would still need to define them, but in most cases they would get
applied by a preprocessor running over the raw OSM data. Enough OT for
now...
Michael
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
