Hello,
I've forwarded the question on the use of the IFOPT-number to the talk-transit
mailing list
(https://lists.openstreetmap.org/pipermail/talk-transit/2013-December/001663.html).
The operator is not included in the data provided for the import, and often
there will be several bus line operators stopping at the same bus stop.
However, the operator tag is included in the bus route relations, so it can be
deducted from that, if someone wanted an "operator" (or operators) for the bus
stop.
I think the is_in is necessary for the following reason: We only have
boundaries down to the level of communities ("Gemeinden") in OSM, but the bus
stops are often labelled with the name of villages, sub-parts of the
communities, which sometimes don't even have exact boundaries.
Here are some examples, where I think it would be impossible to derive the
"complete name" (town and name of stop) without the is_in-tag:
http://www.openstreetmap.org/node/1487738866: Although this stop is
geographically still in the city of Graz, this stop is in Fölling for
everything related to public transport (most important for tariffs, but also
for a unique name ...).
http://www.openstreetmap.org/node/1801654560: This stop is closer to the node
called "Fölling" in OSM than the above stop, however it is in "Prellerberg"
(there is not even a place in OSM with that name).
http://www.openstreetmap.org/node/1735061993: This stop is named after the
community it is in: Rettenegg, BUT:
http://www.openstreetmap.org/node/1735061989: This is the platform for the
other direction, which of course has the same name, but is geographically
already beyond the border in the next community (Sankt Jakob im Walde).
One could of course state, that the bus stops should be renamed, but since that
is not within our scope, I still think, the is_in-tag is required for
identificaiton of the bus stops.
Andreas
Gesendet: Freitag, 29. November 2013 um 02:56 Uhr
Von: "Jason Remillard" <[email protected]>
Betreff: Re: [Imports] Import of public transport platforms in Styria (Austria)
Hi Andreas,
- ID
We just looked at another bus stop import.
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/SASA_Bus_Stops_Import
This issue of the IFOPT/GFS numbers has already came up, without any
good solution so far. These global routing ids are useful and I think
belong in OSM. We don't have a standard tag, making it very difficult
for somebody to actually use them. Rather than putting them into an
import specific namespace, instead could could you figure out a proper
tag for them, and put it here?
http://wiki.openstreetmap.org/wiki/Public_transport[http://wiki.openstreetmap.org/wiki/Public_transport]
Whatever comes out of that conversation, use it for the import. We
don't have anything...
- You might want to look at the operator tag.
- I don't think we need the is_in, right? We have the town boundaries
in OSM. Its fine if the same name is used over and over again.
Good luck!
Thanks
Jason
On Wed, Nov 27, 2013 at 10:09 PM, Andreas Uller <[email protected]> wrote:
>
> Dear List,
>
> We have received the position of all public transport platforms in the
> Austrian province of Styria from the company responsible for managing public
> transport ("Steirische Verkehrsverbund GmbH").
>
> I have put together all information on the following page in the wiki:
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark[http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark]
> (with all relevant information in German and English).
>
> A short outline of the plan:
> All positions where no platform in a certain area (e.g. 100 m) around the
> available points are present in OSM, would be imported directly into OSM,
> probably using JOSM. All others will have to checked and merged manually.
> This has already been successfully done with an import of all doctors in
> Styria.
>
> A downside of the data provided is, that there are some platforms included
> which are no longer used (they were used during a detour of a route or the
> route has been dismissed). However, most of this disused platforms will be in
> the capital city of Graz, where I and other users know, which stops are the
> ones disused, so they can be excluded during the manual import (all platforms
> in Graz should already be mapped, so this area can be excluded from an
> automated import). In the end, there will probably only be a handful of
> disused platforms in the end. On the long run, all bus routes should be
> mapped; then it will be easy to find unused platforms.
>
> Also included on the wiki page is a suggestion on how to use the provided
> attributes and turn them into OSM-key/value pairs.
> Here, a point is unclear to me: There are varoius IDs provided, one is a
> "global, unique" ID for each platform (Europe-wide normed "IFOPT" number).
> Should this be imported to OSM (as ref=* or something different?) in case we
> later receive open timetable or realtime data which needs to be connected to
> the stops? Or are there other ways to match timetable data to platforms?
> These IDs are not visible to anyone standing at the bus stop and I have not
> yet encountered them anywhere else than in that file - from what I've read so
> far this is a strong reason not to include them. However, I want to be sure
> we don't need them later.
>
> Any feedback is welcome.
>
> Andreas
>
> _______________________________________________
> Imports mailing list
> [email protected]
> https://lists.openstreetmap.org/listinfo/imports[https://lists.openstreetmap.org/listinfo/imports]
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports
