Re: [Talk-transit] maintenance is very time consuming on public transport routes
On Mon, Dec 2, 2013 at 1:22 PM, Mike N nice...@att.net wrote: On 12/1/2013 5:32 PM, Jo wrote: Hmm, I was thinking of staying more or less within the lines of what we have now, but take away the burden of 10, 20, 70 relations on the same piece of road. I'm just curious - what type of data consumer could use information from OSM which contains 70 routes in a road segment? It would seem to be too many to fit on a map display, but I suppose a device would be able to highlight a single route variation on demand. I am looking at using the OSM transport data in transport network planning, in particular, how to buiid a network which works more effectively (dare I say efficiently). We need all this information. The routes also need to be described with 'time-of-day' as well. (Locally, we have roads that reverse direction depending on the time-of-day/weekday/weekend.) ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
On 12/3/2013 6:34 PM, Jo wrote: Would it be useful to add all the starting times/ending times as well for a given route? This can be different depending on weekdays/Saturdays/Sundays/weekdays during short school holidays/weekdays during long school holidays. How would we indicate that difference? It's probably not wise to add it, it changes even more often than the routes themselves. It will be very awkward and tag-heavy to add time information to the OSM data. It's possible to add some data as listed above, but - in addition to the variations above: What about route schedule timing points? (Where the bus leaves at a targeted time, waiting if necessary). Technically, each of those points must be updated according to the schedule above. In my tiny area without GTFS, I created the 13 routes in OSM, then created GTFS data with an external tool to add time schedules. The tool was not ideal, but the GTFS and OSM routes matched exactly. There may be better tools available now (For example, I haven't looked at the GTFS editor at https://github.com/openplans/gtfs-editor ) ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
Hi Mike, Which tool were you using for GTFS? On Wed, Dec 4, 2013 at 11:31 AM, Mike N nice...@att.net wrote: On 12/3/2013 6:34 PM, Jo wrote: Would it be useful to add all the starting times/ending times as well for a given route? This can be different depending on weekdays/Saturdays/Sundays/weekdays during short school holidays/weekdays during long school holidays. How would we indicate that difference? It's probably not wise to add it, it changes even more often than the routes themselves. It will be very awkward and tag-heavy to add time information to the OSM data. It's possible to add some data as listed above, but - in addition to the variations above: What about route schedule timing points? (Where the bus leaves at a targeted time, waiting if necessary). Technically, each of those points must be updated according to the schedule above. In my tiny area without GTFS, I created the 13 routes in OSM, then created GTFS data with an external tool to add time schedules. The tool was not ideal, but the GTFS and OSM routes matched exactly. There may be better tools available now (For example, I haven't looked at the GTFS editor at https://github.com/openplans/gtfs-editor ) ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
Mike N nice...@att.net a écrit : On 12/1/2013 5:32 PM, Jo wrote: Hmm, I was thinking of staying more or less within the lines of what we have now, but take away the burden of 10, 20, 70 relations on the same piece of road. I'm just curious - what type of data consumer could use information from OSM which contains 70 routes in a road segment? It would seem to be too many to fit on a map display, but I suppose a device would be able to highlight a single route variation on demand. You're right, we would have to think of ways to integrate the following operations in edit tools: - Adding items to a relation (OK itns available) - Removing items from a relation (one by one, feasible) - Copying a relation - Splitting a relation into two relations (the main issue with our variants issue): how to visually handle this? - Sorting items in a relation? Regarding groups of segments to be represented on a tool, this is already possible since we do that with routes. Now how to call this relationship? Teuxe___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
Mike N nice...@att.net a écrit : On 12/1/2013 5:32 PM, Jo wrote: Hmm, I was thinking of staying more or less within the lines of what we have now, but take away the burden of 10, 20, 70 relations on the same piece of road. I'm just curious - what type of data consumer could use information from OSM which contains 70 routes in a road segment? It would seem to be too many to fit on a map display, but I suppose a device would be able to highlight a single route variation on demand. You're right, we would have to think of ways to integrate the following operations in edit tools: - Adding items to a relation (OK itns available) - Removing items from a relation (one by one, feasible) - Copying a relation - Splitting a relation into two relations (the main issue with our variants issue): how to visually handle this? - Sorting items in a relation? Regarding groups of segments to be represented on a tool, this is already possible since we do that with routes. Now how to call this relationship? Teuxe___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
First of all, it's great to see that the list comes back to life again. I hope we can use the enthusiasm to solve some of the problems that have hade public transport mapping so tedious. One of the core issues is that there are very different concepts of what makes up a bus service. In the cities, bus routes almost always have fixed routes and run every few minutes: An example is the bus route 26 in London: http://en.wikipedia.org/wiki/London_Buses_route_26 These services aims to be easy-to-use for tourists and other strangers. In the countryside and some small towns, bus services are merely a collection of school services. These services often aren't useful to anybody else than the pupils using it. Other types may exist as well. Think for example of shuttle services to ferries or to airports. They may run far fewer than a busy bus service in London, but they are straightforward useful to all ferry or airport passengers. The urban services also tend to be long-term stable, line 26 for example since more than 20 years. A first step would be to clearly distinguish these different types of bus services, and the best I can offer so far would be the subjective criteria if I would suggest a stranger to use that service without knowing the time table: I would encourage to use line 26 instead of a car, but discourage to use an arbitrary school service instead of a car. I also claim that mapping these urban services is much more useful than mapping school services, hence tools should make at least adding these urban services as simple as possible. There is unfortunately less value in adding school services to OSM, because the general public cannot replace their car use by them anyway, regardless if they change frequently or not. The state of affairs is that at least the JOSM relation editor handles such relations well, including splitting ways with multiple relations on it (I've just tested with 35 bus services on a way, and it worked without notable delay). We should keep in mind that urban model simply works and do break things here. Other editors have better chances to get to the same level of comfort if the data model is simple. And the simplest form is indeed: one relation per route and direction, stops and ways added in the order of service. Does it make sense for me to elaborate on this and invest time into an actual proposal? Actually no. None of the above listed problems would be solved by yet another proposal. Proposals help if and only if there are already mulitple conflicting usage patterns around and the proposal process would offer the forum to bring proponents of all sides to an agreement. They don't help if the problem is to choose a data model and to implement it in software. To make a good data model choice the best way is to collect as much examples as possible to check whether proposed data models does cover them and to implement them in software. This helps to understand whether a data model is really simple or just simple-looking. The sub-relation proposal is an example for simple-looking: The code to figure out whether a given relation is a bus route and how to order it for the line diagram generator http://overpass-api.de/public_transport.html is already more than 2000 lines long. Adding support for sub-relations and doing something sensible in all the various error cases will add some hundreds or thousands of lines, precisely because there is plenty of opportunity to create maybe-errorneous route relations with a more complex data model that you have to deal with a a software developer. Requiring a routing capability is even worse: Implementing an A* algorithm that does the core routing is not the hard part. The hard part is to choose which kinds of way to take (sometimes buses may pass through pedestrian areas, sometimes not, sometimes against one-way routes, sometimes not), because you have a good chance to get several kilometers of bogus deviations if you wrongly exclude a way that's actually allowed, and tagging practices do subtlely differ between different local communities. So I'm happy about the initiative, but yet another pile of prose text doesn't make a tool for mappers. By contrast, I would love rather an approach that has a chance to work: Let us collect a structured set of examples and then write code that can handle all these examples. This gives at least the chance that mappers, software developers and data users all have a chance to adopt the data model. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
On Mon, Dec 2, 2013 at 7:34 AM, Roland Olbricht roland.olbri...@gmx.de wrote: This gives at least the chance that mappers, software developers and data users all have a chance to adopt the data model. Here are some examples : In albania, there are minivans (Furgon) that will wait at certain spots and go when enought people are in or enough money is given. there are also popular routes and starting spots : http://www.matinic.us/albania/furgon.php In the dom rep you have guaguas, also overfilled buses : http://wikitravel.org/en/Dominican_Republic#Guaguas_.28local_buses.29 In kosovo they have large private buses are that run between cities, and official city buses see http://prishtinabuses.info/en In Topeka Kansas, there are the city buses which run on normal schedules, I have added a few to osm. then there is the roadrunner http://www.kciroadrunner.com/, it has standard stops, but will pickup when you pay more, it runs only when ordered. So the cheapest pickup for example is at the ramada inn for example, and that would be worthy to put on the map. -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://www.flossk.org Saving Wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
On 12/1/2013 5:32 PM, Jo wrote: Hmm, I was thinking of staying more or less within the lines of what we have now, but take away the burden of 10, 20, 70 relations on the same piece of road. I'm just curious - what type of data consumer could use information from OSM which contains 70 routes in a road segment? It would seem to be too many to fit on a map display, but I suppose a device would be able to highlight a single route variation on demand. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
