Re: [Talk-transit] maintenance is very time consuming on public transport routes

[Mike N]

On 12/3/2013 8:10 PM, Paul Schulz wrote:
> Hi Mike,
> Which tool were you using for GTFS?
>

The .NET tool at 
https://trac.openstreetmap.org/browser/subversion/applications/utils/export/OSM2GTFS


  Plan on working directly in the debugger to work out issues in your data.

  I see another JavaScript tool at

https://github.com/sakarp/osm2gtfs

  I have no idea what its scope is; it might just extract a series of 
routes for use by another tool to add schedules.


  Regards,

  Mike

___
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

[Paul Schulz]

Hi Mike,
Which tool were you using for GTFS?


On Wed, Dec 4, 2013 at 11:31 AM, Mike N  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]

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

[Jo]

Adding time of day is not very easy to do. We don't add the schedules to
OSM.

I'm attempting it for school buses, where it's a time window in the morning
and another around 4 (noon on Wednesdays), but I'm not adding many school
bus routes.

I have access to the timetables and what I do is create a separate route
for each different sequence of stops served.

Now say somebody else has the timetables and he/she wants to visualise the
route the bus takes at that particular time of day. They simply need to
find a route with that ref, which serves that same sequence of stops.

No time-of-day needed in this case.

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.

Polyglot



2013/12/3 Paul Schulz 

> On Mon, Dec 2, 2013 at 1:22 PM, Mike N  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
>
>
___
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

[Paul Schulz]

On Mon, Dec 2, 2013 at 7:48 PM, Teuxe  wrote:

> Mike N  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?
>
Some more tool operations:
- List all the route relations between to points/nodes
- Change selected route relations between two points to use another route
___
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

[Paul Schulz]

On Mon, Dec 2, 2013 at 9:40 AM, Arun Ganesh  wrote:

>
>
>
> On Mon, Dec 2, 2013 at 3:55 AM, Jo  wrote:
>
>> That sounds like a totally different ballpark, which will never fit in
>> the organised way it's done here. So the model as it is now doesn't fit and
>> what I'm proposing doesn't fit either. Are there even fixed positions where
>> the buses would stop? How do you know where the bus will take you? If it's
>> on demand, it's more like a (shared) taxi.
>>
>
> To be fair, the problem is not that it is unorganised, but regularly
> changing with routes being added, removed, renamed and merged due to
> varying demand, politics, fleet upgradations, road improvements and a bunch
> of other factors.
>
> Marked bus stops exist, but the public unofficially shifts it by standing
> a little ahead or before based on convenience if the stop is at a bad
> location blocking road traffic (bus bays don't existent).
>
> Big cities have a complex network of routes and service types that may
> number 200-500 total variations and since there is never any official
> online information portals, one cannot definitively say whats happening
> unless they are at the bus stop and find the latest from someone on the
> ground.
>
> Even creating and maintaining an accurate GTFS feed is a big burden. A
> schema that would just enable bus route road type mapping would atleast be
> an intermediate solution for many developing countries to have a basic
> level of useful details onto the map since the bus route road network is
> something that changes less frequently than the routes.
>
> --
>  Arun Ganesh
> (planemad) 
>  
>

Saying this though, if OSM map data for the road network is used in the
planning software that is used by the Transport Authorities/Tranport
Companies (that eventually exports to GTFS) the output would better for
importing and updating route data in OSM.

There are a couple of business drivers here for using OSM for this purpose.
The commercially available rotatable map data is expensive, both initially
and with additional releases, and the data is never up to date for new
transport areas, which is not just an issue for developing countries.
___
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

[Paul Schulz]

On Mon, Dec 2, 2013 at 1:22 PM, Mike N  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] IFOPT-numbers for public transport platforms

[Paul Schulz]

Greetings,
Andreas -  Thank you for your comments and questions. I am replying because
I have an interest in the data once it is in OSM, particularly in closing
the loop with the Transport Authorities. eg. Get the Transport Authorities
to provide the route data for OSM. The GTFS data format[1,2] may play a
part here.

The stops (in Adelaide for example) have been uploaded from an official
source, by the look of it.

- I am looking at using the OSM map data for calculating new bus routes and
schedules.

The unique stop number (in this case, national Australian) is currently
associated with the bus stop location, but it also needs to be associated
with the 'stop_location' on the route relation.

Rather than using an implcit - nearest bus stop to the vehicle stop
location [3]- It would be better to have a relation with allows these to
nodes to be related.

Cheers,
Paul

[1] GTFS - General Transit Feed Specification -
https://developers.google.com/transit/gtfs
[2] http://www.gtfs-data-exchange.com
[3] http://www.openstreetmap.org/edit#map=19/-34.81027/138.61578


On Tue, Dec 3, 2013 at 8:43 PM, Andreas Uller  wrote:

> Dear list,
>
> First I'd like to say hello, my name is Andreas, and I consider it one of
> my main priorities in OSM to map things related to public transport
> (routes, stops) in my home city of Graz, Austria and beyond.
>
> The bus and tram lines in Graz are complete for quite some time now, so I
> started entering all the regional bus lines in Styria (a list of the
> current progress is here: [1]). Of course, I use the current tagging
> scheme, which can be quite tideous for regional buslines, because often
> there are many variants which each should get their own relation. My
> "masterpiece" so far are the bus routes 200/201 with a total of 62 variants
> (the timetable is so long, it's split into two files: [2],[3],
> route_masters in OSM: [4],[5]).
> So far the biggest problem was finding the correct position of bus stops
> in rural areas, where they often can't be seen on aerial images (no
> road-markings, no bays, no shelters...). Therefore, I'm very happy that we
> got the position of all public transport stops in Styria for use in OSM.
> The planned import is outlined here: [6] and a discussion has been started
> on the imports-Mailinglist: [7].
>
> The reason for my mail to you is:
> We also received a lot of attributes for each platform, including a unique
> ID per platform, which has been identified as the IFOPT-number, an
> internationally unique number. It appears unclear, if this number should be
> added to all the platforms in OSM, or if this is unnecessary/unwanted. Has
> there already been a discussion on how (if at all) to use this number? The
> most straigh-forward method that comes to my mind would be to include it as
> ref:IFOPT, but what is the opinion on this list?
> I think it could become important when timetable- or real-time-data
> becomes available, but I don't know if this is true.
>
> I'm looking forward to you answers,
> Andreas
>
> [1]
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Regionalbusse_Steiermark
> [2] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200m_j13.pdf
> [3] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200n_j13.pdf
> [4] http://www.openstreetmap.org/relation/955209
> [5] http://www.openstreetmap.org/relation/2165551
> [6]
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark
> [7]
> https://lists.openstreetmap.org/pipermail/imports/2013-November/002428.html
>
> ___
> 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] IFOPT-numbers for public transport platforms

[Richard Mann]

UK bus stops all have codes (taken from the NaPTAN import), for example:
http://www.openstreetmap.org/node/533877725

If it's not displayed on the stop, any reference should be prefixed with
the source.

That stop also has a publicly-displayed code which is tagged as ref=69345648.
This is actually the numeric equivalent of the NaPTAN code (oxfgjmgt). Both
these codes can be used to look information up on the internet.


On Tue, Dec 3, 2013 at 10:13 AM, Andreas Uller  wrote:

> Dear list,
>
> First I'd like to say hello, my name is Andreas, and I consider it one of
> my main priorities in OSM to map things related to public transport
> (routes, stops) in my home city of Graz, Austria and beyond.
>
> The bus and tram lines in Graz are complete for quite some time now, so I
> started entering all the regional bus lines in Styria (a list of the
> current progress is here: [1]). Of course, I use the current tagging
> scheme, which can be quite tideous for regional buslines, because often
> there are many variants which each should get their own relation. My
> "masterpiece" so far are the bus routes 200/201 with a total of 62 variants
> (the timetable is so long, it's split into two files: [2],[3],
> route_masters in OSM: [4],[5]).
> So far the biggest problem was finding the correct position of bus stops
> in rural areas, where they often can't be seen on aerial images (no
> road-markings, no bays, no shelters...). Therefore, I'm very happy that we
> got the position of all public transport stops in Styria for use in OSM.
> The planned import is outlined here: [6] and a discussion has been started
> on the imports-Mailinglist: [7].
>
> The reason for my mail to you is:
> We also received a lot of attributes for each platform, including a unique
> ID per platform, which has been identified as the IFOPT-number, an
> internationally unique number. It appears unclear, if this number should be
> added to all the platforms in OSM, or if this is unnecessary/unwanted. Has
> there already been a discussion on how (if at all) to use this number? The
> most straigh-forward method that comes to my mind would be to include it as
> ref:IFOPT, but what is the opinion on this list?
> I think it could become important when timetable- or real-time-data
> becomes available, but I don't know if this is true.
>
> I'm looking forward to you answers,
> Andreas
>
> [1]
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Regionalbusse_Steiermark
> [2] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200m_j13.pdf
> [3] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200n_j13.pdf
> [4] http://www.openstreetmap.org/relation/955209
> [5] http://www.openstreetmap.org/relation/2165551
> [6]
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark
> [7]
> https://lists.openstreetmap.org/pipermail/imports/2013-November/002428.html
>
> ___
> 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

[Talk-transit] IFOPT-numbers for public transport platforms

[Andreas Uller]

Dear list,
 
First I'd like to say hello, my name is Andreas, and I consider it one of my 
main priorities in OSM to map things related to public transport (routes, 
stops) in my home city of Graz, Austria and beyond.
 
The bus and tram lines in Graz are complete for quite some time now, so I 
started entering all the regional bus lines in Styria (a list of the current 
progress is here: [1]). Of course, I use the current tagging scheme, which can 
be quite tideous for regional buslines, because often there are many variants 
which each should get their own relation. My "masterpiece" so far are the bus 
routes 200/201 with a total of 62 variants (the timetable is so long, it's 
split into two files: [2],[3], route_masters in OSM: [4],[5]).
So far the biggest problem was finding the correct position of bus stops in 
rural areas, where they often can't be seen on aerial images (no road-markings, 
no bays, no shelters...). Therefore, I'm very happy that we got the position of 
all public transport stops in Styria for use in OSM. The planned import is 
outlined here: [6] and a discussion has been started on the 
imports-Mailinglist: [7].
 
The reason for my mail to you is:
We also received a lot of attributes for each platform, including a unique ID 
per platform, which has been identified as the IFOPT-number, an internationally 
unique number. It appears unclear, if this number should be added to all the 
platforms in OSM, or if this is unnecessary/unwanted. Has there already been a 
discussion on how (if at all) to use this number? The most straigh-forward 
method that comes to my mind would be to include it as ref:IFOPT, but what is 
the opinion on this list?
I think it could become important when timetable- or real-time-data becomes 
available, but I don't know if this is true.
 
I'm looking forward to you answers,
Andreas

[1] 
http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Regionalbusse_Steiermark
[2] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200m_j13.pdf
[3] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200n_j13.pdf
[4] http://www.openstreetmap.org/relation/955209
[5] http://www.openstreetmap.org/relation/2165551
[6] 
http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark
[7] https://lists.openstreetmap.org/pipermail/imports/2013-November/002428.html

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit