[Talk-transit] catching up
grand.edgemaster at gmail.com
Sun Jan 11 15:11:13 GMT 2009
2009/1/11 Peter Miller <peter.miller at itoworld.com>:
> Do remember that NaPTAN is a Database created from 140+ different
> authorities all of whom had their own home grown systems before their are a
> central database or any national standard and we probably need to see the
> data before going much further with this. One of the things that professions
> are interested in is how the OSM community uses the data and what changes
> they make - I do think that we may wish to weed out the long indicators.
> Google use this database and us the short ones directly on Google Maps, but
> dump the long ones and make something up for themselves automatically.
Good point, plenty of scope for data verification whilst we're
importing and even once we're done.
>>> I suggest we do a first pass where we extract the core information and
>>> we can do a second pass at some point in the future and get all the
>>> out of it. I will add a comment to each field in the page you have
>>> constructed to say if I think it is normally populated and if we should
>>> bother with it.
>> Would this comply with the DfT's requirement for the source data to be
>> deleted after import?
> I am sure they would be happy with us doing to passes over a few months. We
> need to introduce ourselves to them early next week.
>> We definitely need an idea of which parts of the schema are actually
>> populated. The schema gives plenty of places for data to be possibly
>> duplicated and thus inconsistant.
>> (For example, I'm thinking of: StopClassification/StopType = AIR,
>> which requires that StopClassification/OffStreet/Air/Entrance is
> I can fill in some idea of what is likely to be populated. Also, there will
> be no problem for us having the data before we make those detail decisions.
> I suggest we propose a process where we have time to make a number of passes
> at importing the data. I see no problem for us saying we will retain the
> data for a few months while we make a number of passes - lets talk to them
> and suggest what we would like to do.
Good, we can decide how much their schema deviates from reality then
for the import process.
>>> This list doesn't include the NaPTANCode which we should import and
>>> some other minor or blank fields.
> Correct. I am not sure why not, either our software is not handling it
> properly yet or some other reason, but it will normally be there and will
> normally be correct.
This was your own comment you replied to :)
>> I've finished the bulk of the schema transcription to the wiki, I've
>> just got to finish the intricacies with the different types of OnRoad
>> and OffRoad bus stops.
>> I've also realised that most of the NPTG data is going to be..
>> interesting, I'm not sure how much of it will be practically usable..
> ? are you saying is is boring data and we shouldn't bother? or that it is
> good stuff but there might be difficulties with using it? Some stuff may
> well be boring, but should we import all of it or make a judgement call
> about what OSM users might want?
Quite a lot of it is directly related to the administration of NaPTAN
data, and thus we won't require it.
Some AdministrativeArea may be worth mapping onto boundary relations
of their respective counties.
District info looks to be essentially useless, with only names being
provided, I guess we could extrapolate the points within each district
to get a rough outline.
We'll get considerable duplication with existing OSM data for
localities, so we're going to have to be clever with the import of
>> (I also note that it gives its data sources too - SourceLocalityType
>> in http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings#Locality I
>> wonder whether the OS will like us if we import a large proportion of
>> what is essentially their place gazetteer data :)
> To be completely clear it is not an OS gazetteer and they have no claim on
> it. The authorities used a different starting point to ensure that they were
> free of restrictions or charges from any third party in relation to its use!
> We definitively have permission to import it.
I wasn't doubting our permission to use it, (although I forgot to
include this in my previous message), if there is any OS sourced data,
they'll just have to take it up with the DfT...
More information about the Talk-transit