Re: [Talk-transit] GTFS compatibility
But we are still in the thinking-about-this stage, haven't made any decisions, and are looking for suggestions and comments (hence this posting). Let me make a suggestion: instead of producing duplicates and leaving mappers with the frustrating task of tiding up, you could use JOSM to do a semi- automatic import. JOSM will offer quite powerful and versatile editing capabilities to solve conflicts immediately. I've extended the Public Transport Plug-In to offer an experimental GTFS import (for stops only at the moment). The aim of this software is to avoid cluttering the database with duplicates and to maintain the data model as consistent as possible. At the moment, the stops as treated as bus stops, because I can't find a stop type in the GTFS specification. Installation instructions: - download JOSM: http://josm.openstreetmap.org - Run with java -jar josm-tested.jar - Open Edit Preferences Plugins and select public_transport - Restart JOSM I suggest the following workflow: - Download an area to work on into JOSM - Import the respective GTFS file (stops.txt) with the plug-in - The plugin will pre-sort on load - work through the nodes that remain pending: mark a line in the dialogue, press Enable to add the node, the Show and Mark to center on the node. If you want to join it with an existing node, this What happens on load of stops.txt: - Every stop that is outside the bounding box of the currently loaded area in JOSM will be set to state outside - Every other stop that is more than 1000m away from any existing bus stop (recognized as highway=bus_stop) will be added to the map (state: added) - Every stop nearby existing bus stops is set to state pending. What you can do within the plugin: - The button Enable adds all stops currently marked as lines in the dialogue as nodes with highway=bus_stop stop_id=[stop_id] name=[stop_name] to the map. - The button Disable removes the stops marked as lines from the map. - The button Catch drags an existing, marked node on the map to the position of the imported stop and tags it as explained above. An existing name is preserved. - The button Join does the same as Catch, but the node remains at the position of the existing node. - The buttons Mark and Show mark resp. show a stop (must be enabled) from the dialogue on the map. The button Find marks lines the dialogue that correspond to marked nodes in the map. Possible extensions or modifications to make life easier: - Use remote control and a server application to only detect those areas where conflicts exist. - Reuse existing stop_ids to match imported stops there. This would greatly simplify later updates. - Use other attributes from stops.txt - Make the workflow smoother, e.g. use key shortcuts for sequences like Enable, Show, Mark. - do something with agency.txt. and of course any idea you might have. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS compatibility
On Thu, Jul 1, 2010 at 2:48 PM, Roland Olbricht roland.olbri...@gmx.de wrote: capabilities to solve conflicts immediately. I've extended the Public Transport Plug-In to offer an experimental GTFS import (for stops only at the moment). The aim of this software is to avoid cluttering the database with Fantastic! moment, the stops as treated as bus stops, because I can't find a stop type in the GTFS specification. One design goal of GTFS was to represent things in a way that matches the rider's model of the world as closely as possible. Therefore, a stop doesn't have a single inherent vehicle type, because there are many stops which are serviced by multiple types of vehicles (for instance, both buses and street-running trams). It'd be possible to artificially create two semantic stops with the same name at the same location, one for each vehicle type, but that wouldn't match the rider's perception when they look at a single shelter/sign and see a single stop. In order to determine which types of vehicles stop at a particular stop point in GTFS data, you need to cross-reference the stops table with the routes and stop_times tables. Cheers, Joe ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS compatibility
Since the JOSM plug_in will become the defacto standard since it will be used by many people who don't read posts here or understand the issues may I request that it uses the GTFS tag of stop_name and stop_code rather than the tag of name. In one location two stops with the same stop_name actually have different buses serving them. At one intersection in Ottawa I have four different bus stops each with different routes heading in different directions. Each stop has a physical stop_code on the stop. When I ran the import it imported one stop at a different location to the four on the junction. I'm unable to tell if it is one of the four at the junction and should replace the existing mapped ones or it is the stop before the junction. The same value in the stop_name field appears to be used for different stops on the same route. That way if we are consistent then the rules in the renders can just render the appropriate stop_code or stop_name if not present. Many thanks Cheerio John On 1 July 2010 09:48, Roland Olbricht roland.olbri...@gmx.de wrote: But we are still in the thinking-about-this stage, haven't made any decisions, and are looking for suggestions and comments (hence this posting). Let me make a suggestion: instead of producing duplicates and leaving mappers with the frustrating task of tiding up, you could use JOSM to do a semi- automatic import. JOSM will offer quite powerful and versatile editing capabilities to solve conflicts immediately. I've extended the Public Transport Plug-In to offer an experimental GTFS import (for stops only at the moment). The aim of this software is to avoid cluttering the database with duplicates and to maintain the data model as consistent as possible. At the moment, the stops as treated as bus stops, because I can't find a stop type in the GTFS specification. Installation instructions: - download JOSM: http://josm.openstreetmap.org - Run with java -jar josm-tested.jar - Open Edit Preferences Plugins and select public_transport - Restart JOSM I suggest the following workflow: - Download an area to work on into JOSM - Import the respective GTFS file (stops.txt) with the plug-in - The plugin will pre-sort on load - work through the nodes that remain pending: mark a line in the dialogue, press Enable to add the node, the Show and Mark to center on the node. If you want to join it with an existing node, this What happens on load of stops.txt: - Every stop that is outside the bounding box of the currently loaded area in JOSM will be set to state outside - Every other stop that is more than 1000m away from any existing bus stop (recognized as highway=bus_stop) will be added to the map (state: added) - Every stop nearby existing bus stops is set to state pending. What you can do within the plugin: - The button Enable adds all stops currently marked as lines in the dialogue as nodes with highway=bus_stop stop_id=[stop_id] name=[stop_name] to the map. - The button Disable removes the stops marked as lines from the map. - The button Catch drags an existing, marked node on the map to the position of the imported stop and tags it as explained above. An existing name is preserved. - The button Join does the same as Catch, but the node remains at the position of the existing node. - The buttons Mark and Show mark resp. show a stop (must be enabled) from the dialogue on the map. The button Find marks lines the dialogue that correspond to marked nodes in the map. Possible extensions or modifications to make life easier: - Use remote control and a server application to only detect those areas where conflicts exist. - Reuse existing stop_ids to match imported stops there. This would greatly simplify later updates. - Use other attributes from stops.txt - Make the workflow smoother, e.g. use key shortcuts for sequences like Enable, Show, Mark. - do something with agency.txt. and of course any idea you might have. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
