[OSM-legal-talk] public transport routing and OSM-ODbL

Frederik Ramm frederik at remote.org
Wed Jul 7 15:56:03 BST 2010


Hi,

    I talked to a public transport operator today. They want to build a 
routing engine for their network with special focus on accessibility 
(e.g. taking into account that if you have a certain type of wheelchair 
you may perhaps not be able to reach bus stop X from your starting point 
and rather need to use bus stop Y, or a certain changeover is unsuitable 
if you're blind and you'd better use something else etc.).

Because there's an endless list of things that might affect 
accessibility, they would like to use OSM data for that, so that their 
users can fix things themselves.

They have no problem releasing information about their halts/stops and 
their route network, but what they want to keep private is their 
schedule database, i.e. which bus stop or underground station is 
serviced by which line when.

I would really like to find a way to make this possible because it would 
be a brilliant application of OSM data (and nobody in OSM is interested 
in when a bus calls at a station anyway). However, in terms of ODbL the 
route description they produce will be a produced work which is based on 
a database derived from OSM, so they will have to release that database. 
It is probably going to be very painful to try and separate OSM data 
from their schedule data.

Would you agree with me when I say:

1. If you have a pre-processing step that mixes your schedule data with 
OSM data and then something else that does routing on the resulting data 
set, you will have to release it all.

2. If you manage to do your pre-processing in a way that only mixes your 
static network data with OSM, resulting in a data structure that 
contains information like "transit from stop X to stop Y possible for 
these types of vehicles" and so on, and then your router process, upon 
startup, reads this file plus another file with all the schedule data, 
then you can get away with only releasing the static network file.

Bye
Frederik




More information about the legal-talk mailing list