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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
