-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use GTFS data for transport platform, area, route and route_master #163
Comments
A GTFS is just a CSV in a ZIP. If no join on the CSVs is required we can already do this. |
Indeed, we need some type of join on the CSV...
Directly parsing stops.txt without join can be done, but we loose some useful informations : we know it is a transport platform where passengers board or disembark from a transit vehicle, its name, its id, and its location, but we do not know which lines use it (and which type of PT : is it bus/rail/metro???). Is it enough to be useful ? Note : there are realy many GTFS feeds around the world, see here : https://transitfeeds.com/about |
TrasitFeeds does not seem to provide data licence. There is also https://navitia.opendatasoft.com and they provide a licence field in metadata. |
The GTFS format puts no constraint on that : the GTFS stop is a logical stop (whereas OSM ones are physical ones). A GTFS stop can be a platform, a stop_position, or even the center of the stop area. You have the same fuzz with the routes : they are a group of trips so they can be lines (type = route_master), but they also can be just routes (type = route) or group of routes (nothing in OSM). |
A good solution would be to let the user determine if it is a platform or a
stop_position. A good hint for bus is the distance to nearest route: for
most cases in Ile de France GTFS stops for busses are platform.
Le 20 juin 2017 8:12 AM, "Noémie" <notifications@github.com> a écrit :
… The GTFS format puts no constraint on that : the GTFS stop is a logical
stop (whereas OSM ones are physical ones). A GTFS stop can be a platform, a
stop_position, or even the center of the stop area.
If you have a stop served by 3 bus lines, you can have 1 GTFS stop, 3 GTFS
stops, but even 2 GTFS stops 😕
So you have to analyze the GTFS modelization to determine what to do
precisely with the stops.
I think for the buses, stops are mostly platform or center of stop area,
whereas for trains, they are mostly stop_position
You have the same fuzz with the routes : they are a group of trips so they
can be lines (type = route_master), but they also can be just routes (type
= route) or group of routes (nothing in OSM).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#163 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALG88nUScEhbkBQyqSogeL9rsCPrX8oIks5sF2K4gaJpZM4LFsrl>
.
|
We do it with stop. The others can't feet easly in Osmose. |
Manu public transport operators publish GTFS open data (for exemple STIF https://opendata.stif.info/explore/dataset/offre-horaires-tc-gtfs-idf/information/ ). As it is a technical standard, it would bé useful to implement a parser in osmose back-end, so we can integrate at least transport platform and area easily for manu PT operators worldwide (for stop, route and route_master it is more difficult as we need to find the nearest way, and the used way segments). We need a convenient key between GTFS and OSM, perhaps a gtfs_id or ref:GTFS key?
The text was updated successfully, but these errors were encountered: