[Talk-gb-westmidlands] [Spam] Re: [Talk-transit] NaPTAN data import

[Peter Miller]

On 6 Mar 2009, at 21:16, Gerrit Lammert wrote:

> Hi Peter.
>
> Peter Miller wrote:
>> On 6 Mar 2009, at 18:28, Andy Robinson (blackadder-lists) wrote:
>>>>
>>>> Gerrit - NaPTAN references nodes as being part of a StopArea,
>>>> somewhat
>>>> like our relation structure. The converter is already pulling  
>>>> them in
>>>> according to the unified stop area spec. (Except for not having the
>>>> stop-points on the road way, just beside, but thats just a moot
>>>> point)
>>>>
>> In the EU a Stop Point is the place that the person waits for the
>> vehicle, which is beside the road/track and the place where the
>> vehicle stops in called a Stopping Point is on the road/track.
>>
>> Can we agree that a Stop in OSM is the same as a Stop Point and is
>> therefore correctly positioned beside the track. What OSM is  
>> proposing
>> to call a Halt is on the track and is the same as a Stopping Point.
>> The unified Stop Area proposal is a great one to settle this one for
>> good for all public transport modes.  I do hope we can drop that as a
>> 'moot point' soon!
>> http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea
>
> I started the unified stop_area to find a common approach to all these
> similar locations (bus stop, railway station, pier, ...).
> I do not really care about what everything is called as long as  
> everyone
> agrees.
snip
> In my opinion "stop point" ans "stopping point" are two phrases two
> close to each other.
> So if everyone agrees, lets try and brainstorm better names for the
> elements in the unified_stoparea-Proposal.
>

There are a number of issues here:

1) We are aware that there is not consistency between transport modes  
within OSM and that is confusing. For example it is railway=station  
and aeroway=station but it is amenity=bus_station. Places where people  
wait for transport are nodes within the highway for some modes  
(railway/tram) but beside the road normally for others (buses).

We need to sort this out carefully but need to get it right. Note that  
the phase 'halt', being proposed as the tag for where a vehicles stops  
on the highway is actually already used in OSM, as in 'railway=halt'  
for "A small station, may not have a platform, trains may only stop on  
request. ". Designing a model that works, that is well defined and  
that is consistent is very hard and we should give ourselves time to  
get it right.

2)Within different standards the same term is often used for the  
different things. For example we have the concept of a 'Stop' and so  
does GTFS but they are subtlety different (GFTS has a flag called  
parent_station). This makes sharing schedules harder than it should be  
and harder to share stop data with GTFS data providers.
http://code.google.com/transit/spec/transit_feed_specification.html#stops_txt___Field_Definitions

3) Sometimes different terms are used by different organisations for  
the same thing and after careful investigated one can determine that  
there is an exact correspondence between them and can say that 'what  
we call a Stop is what they call a Stop Point'. Note that in Europe  
many standards were originally written in the native language and then  
terms were converted (sometimes badly) into English. See VDV453 as an  
example of a German standard that was then converted into English (the  
VDV site seems to be down at present). Sometimes one assumes that  
there is an exact modelling correspondence and there is not. I  
remember a huge panic some years ago when we discovered that what we  
called a 'route' in our company was not what was being provided to use  
in the 'route' field by the ticket machine provided by another  
company. We discovered this *after* fitting 200 buses in Cardiff with  
devices that then needed to be reprogrammed at night in the rain just  
before the launch.

4) Most models and terminology are created for one particular use and  
fall down when applied to other applications.  GTFS is great for  
journey planning, but is not so good for creating printed timetables  
(important information about special days is lost so one can't say  
'school days only' one can only list the dates on which it runs). That  
doesn't make GTFS a bad standard but it makes it a limited standard  
suitable for a limited range of purposes. Here is the sort of analysis  
one needs to do to compare two standards.
http://www.transmodel.org.uk/schema/doc/GoogleTransit/TransmodelForGoogle-09.pdf

Ok, so That was the context behind the creation of Transmodel. There  
were hundreds of companies from 15 different countries speaking  
different languages with different models that worked in their country  
for their application - it was a mess.

Transmodel was created as a general model for public transport that  
worked for all modes for all purposes and allowed companies and  
authorities to mix and match products from different countries. The  
lead country for Transmodel was France and now all tenders in Europe  
for this sort of stuff will use Transmodel terminology and all CEN  
standards will also use it. Transmodel is also used as a standard  
informally in many other countries when specifying systems because it  
is there and it works.

So... OSM could decide to work it out for itself as it goes along with  
its own modelling concepts and terminology and that might be  
interesting and sort of fun in parts. But that approach does run into  
all of the above potential problems when connecting with other projects.

I propose that we determine to migrate towards Transmodel terms and  
modelling concepts over time and where we need to introduce new  
elements we use their terms and modelling concepts for preference. I  
know that the terms are sometimes a bit nerdy and arbitrary but we do  
know that they are tested, self-consistent, respected and work for  
many many applications. Our terms would probably also be pretty  
arbitrary.

Also, we know that there is a huge amount of data already coded as  
Transmodel and it might be easier to tempt authorities to give it to  
us if we speak their language!

I propose that we create a 'Proposed Transmodel Migration' page to  
work up what we would need to change to achieve this - based on the  
unified stop area page, but with a new name. This proposal would then  
be put to a vote when it is complete, there would not be an assumption  
that it would happen until we saw how it worked out.

I also propose that we treat this project as separate from the NaPTAN  
import. Let's get on with that and then over the next month work up  
the 'unified modelling' conversion, get agreement for it and then do a  
conversion to the new format in a controlled way.




Regards,



Peter



>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit