Proposal talk:Public transport schema

A few comments

• A excellent proposal, thanks - Do please promote discussion on talk-transit.
• Date: I think you have got the meeting date wrong (we haven't got to 16/17 June 2009 yet!)
• It might be worth mentioning in the introduction the other related proposals, including Proposed features/unified stoparea, QROTI and the NaPTAN import.
• Would it be appropriate to allow some of the shared tags (such as electrification voltage) to be represented within a route relation rather than within each way. See Great Eastern Main Line and East Suffolk Line as examples. The gauge, color, ref, name, nat_ref etc would often more conveniently be represented like this.
• Can you added details for loading gauge to the rail text. This is of significant importance in the UK and elsewhere in the EU as loading gauges are harmonised. Thanks. PeterIto 11:20, 28 May 2009 (UTC)

This seems complex - have I got this correct...

Consider for example a simple bus route that starts at point A, goes to point B and returns by the same ways.

Does this proposal rely on ordered relations to define the route, including each stop_point, way, access point and including the ways twice with role=forward or backward to get the ordering correct?

Or do you just include all the ways, stop points and access points and let something cleverer try and work out the route?

And as the stop points are in the middle of the way, am I correct in thinking that the bus stop nodes to one side of the way are essential to correctly indicate access to the bus route?

Thanks

--EdLoach 09:17, 29 May 2009 (UTC)

In your example you will have two relations, one for the route from A to B and one for the route from B to A. Inside these relations the stop_points and access_points are ordered. The forward and backwards roles are not used any more (they are currently sometimes used but ambiguous). You can have stop points and/or platform objects (nodes or ways) for each stop. If both are there, everything is easy. If you only have the platform, the stop position is assumed to be the nearest point on the nearest way in the line relation. If you only have a stop position and no platform, the access will be the nearest point on the nearest way tagged as highway=*. -- Joto 15:49, 29 May 2009 (UTC)

This is not how Basic model for lines and the figure with it are written at this moment. There it clearly states that there is a third relation (line), that combines the other two (line variant). This third relation contains most of the tags. --Cartinus 20:44, 1 June 2009 (UTC)

I was pondering bus routes yesterday, following one as I drove, and realised forward and backwards will usually be used on every way member of the individual line variant relations as effectively each line variant will be one direction of the route only so effectively one way. So rather than them not being used any more, they'll be used more often. --EdLoach 06:39, 21 June 2009 (UTC)

Reusing legs of routes

In the dabbling I've done with routes, I've used nested relations for segments of the routes that several services share. This modular approach seems easier and more robust, but I think it was Frederik who warned me on the list that I should not rely on a child relation inheriting the metadata of its parent. Could this perhaps either be explicitly recommended or not recommended as a practice? Repeating the same sequence of stops and ways for several routes seems cumbersome and wasteful. --Hubne 12:09, 29 May 2009 (UTC)

This proposal doesn't allow it. Recursively resolving relations is complicated to implement and harder to understand for people. And there are more places where things can break. At the workshop we agreed that we would not allow it in the proposal. And yes, it will mean more data duplication and more "cut-and-paste" work. But we felt that the problems were larger than the benefits. We maybe can revisit this at a later time when there is better support for nested relations in editors. -- Joto 15:54, 29 May 2009 (UTC)

OK, thanks for clarifying. I think the place to push for this might be in the API, such that it can be (doesn't have to be) transparent to client apps. I only use Merkaartor, and it seems quite happy at least with entry of nested relations. --Hubne 23:04, 29 May 2009 (UTC)

more metadata for accesses

These seem useful features to note for accesses:

• lighting: lit=* is something of a generic convention, I think
• tactile rubber mats for vision-impaired passengers to feel and for unsteady passengers to grip
• the availability of timetables, route maps, and/or real-time arrival data
• ticket vending facilities --Hubne 12:21, 29 May 2009 (UTC)
• for benches (seating), lighting, and shelter, I have also sometimes noted whether it is supplied as part of the bus stop, or whether it is incidentally available (e.g. street lighting that happens to light the stop vs. its own lights, shelter from nearby shop awnings, places to sit near the stop). I was also doing this for bins, but realised these should be tagged as independent nodes. --Hubne 23:11, 29 May 2009 (UTC)

Standards

Comments in relation to CEN IFOPT and Transmodel compliance[1]

1. IFOPT Oxomoa equivalences

It looks to me that the oxomoa model is actually already close to the IFOPT model in that they both correctly separate the representation of stops into two levels - the actual physical access point and the stop group/station, and contain the same concepts.

If one compares the two one can see the correspondance, and also that IFOPT makes a couple of further distinctions that facilitate relating the elements to public transport information services.

1.1 Oxomoa: Stop Area <--> Ifopt: STOP PLACE : (i.e. a collection of closely related Stop Positions/QUAYs that have a common name such as a Station , pair of bus stops, or airport)

• I have changed Stop Area to Stop Place in the proposal. PeterIto 14:32, 30 May 2009 (UTC)

1.2 Oxomoa: Access (public_transport =platform) <--> Ifopt:QUAY (i.e. the actual labelled physical point of access to the transport, which will typically be a pole for a bus , a platform for trains/ metro, a quay for a boat, or a gate for an airport. A QUAY may have one or more BOARDING POSITIONs.

• I have made no change as yet. We should discuss this one. PeterIto 14:32, 30 May 2009 (UTC)

1.3 Oxomoa: Access (public_transport =Entrance) <--> Ifopt:STOP PLACE ENTRANCE (i.e. an entrance to a QUAY, STOP PLACE, or ACCESS AREA)

• I have made no change as yet. We should discuss this one. PeterIto 14:32, 30 May 2009 (UTC)

1.4 Oxomoa: Stop Position (public_transport =stopposition) <--> Ifopt:BOARDING POSITION - A physical point on a QUAY - may be labelled subdivision of a Quay/Platform.

• I believe that this is a misunderstanding and that the correct IFOPT term for this concept is Vehicle Stopping Place. I have changed Stop Position to Stopping Place in the proposal. PeterIto 14:32, 30 May 2009 (UTC)

1.5 Oxomoa: Stop Area Group = Ifopt: a STOP PLACE that has children, (Because big interchanges such as train stations and airports may have many levels, rather than being limited to just one level of grouping , IFOPT allows a nested STOP PLACE . For example St Pancreas, St Pancreas International, St Pancreas International departures, St Pancreas Domestic, St Pancreas underground, etc )

• I have changed this to Stop Place Group as I don't believe we can handle recursive relations yet. PeterIto 14:32, 30 May 2009 (UTC)

2. Differences

2.1 IFOPT also has an ACCESS SPACE - i.e. a concourse, hall or corridor that is part of a STOP PLACE such as a station, but that is not a named platform/ QUAY i.e. point of access to the transport

• The Access Space concept is likely to be a very useful one when modeling transport interchanges. PeterIto 14:32, 30 May 2009 (UTC)

2.2 IFOPT uses a separate entity & relationships for concept of QUAY, and ENTRANCE, rather than lumping these together.

• I suggest we consider separating entrance and 'quay'. PeterIto 14:32, 30 May 2009 (UTC)

2.3 IFOPT STOP PLACEs and QUAYs are also recursive.

• Don't think we can handle recursion yet. PeterIto 14:32, 30 May 2009 (UTC)

2.4 IFOPT LEVEL allows the logical level - e.g. first floor, underground level 1, level 2 etc to be indicated.

• Sounds like a good optional tag. PeterIto 14:32, 30 May 2009 (UTC)

Question: In IFOPT the fundamental entity is QUAY - one always has one of these for each stop - it may be part of a STOP PLACE and be accompanied by one or more BOARDING POSITIONs. The Quay has a Label i.e. stop name etc assigned by the Public Transport Operator or Authority. One would not have a BOARDING POSITION without a Quay. It looks as if Oxomoa, just for buses but not for rail, conflating QUAY with BOARDING POSITION - how would one handle bus stops with multiple boarding positions ?

• Should we allow Boarding Positions? Important for long platforms with services with booked seats where there are boarding positions defined for each group of seat numbers. PeterIto 14:32, 30 May 2009 (UTC)

Relation types

All current relations have a type=*-key. We should also propose one for this scheme! I used type=public_transport for my tests. --Phobie 03:49, 31 May 2009 (UTC)

I will also use type=public_transport for stations and type=route for the buslines. This does not break old schemas. --Teddych 19:43, 16 October 2010 (BST)

Service Tag Questions

In the part of my city where I tagged bus routes (with route=bus) until now, I have encountered three kinds of bus service: normal, at night only and rush hour only. The first is the default, so I don't tag them especially. "At night only" I have tagged as service=nightliner, because that is what's written on the signposts. The last I have tagged as service=rush_hour_only. Now I am a bit confused about the following bit of the proposal.

Key	Value	Description
line	bus	indicates a bus line or trolley bus line
service	busway / express / hail_ride / long_distance / school / shuttle	special line concept: busway, express bus, hail and ride, long distance bus, school bus or shuttle bus?
by_night	yes / no / only	service by night?
on_demand	yes / no / only	service on demand?

• Why are "by_night" and "on_demand" separated out of the other special line concepts?
• Why are rush hour services missing, as I thought that was a pretty general concept?
• If we want to separate out the most common types of services in their own tags, then I would expect a rush_hour=yes/no/only tag.

But of course I only know a small part of the world. --Cartinus 20:19, 1 June 2009 (UTC)

On this purpose I would add a suggestion, there is a missing special service type for occasional service. There are peak hours only, but here are also services that will work partly on the day independently of the period time.

So it would be good to be able to have a way to have a tag like service = occasional and a way to put it also on a branch only, the main route can work all day long, but some branches are just an occasional service. --M-Rick 17:22, 18 June 2011 (UTC)

line= instead of route=?

I don't see the need why the route tag doesn't work for route=bus, route=tram, etc. as it is in use right now. The only reason you mention is to differentiate between railway numbers and the trains on them, but even that is already solved: use route=rail for the railway number, and use route=train for the train routes (there's a pattern there: bus, tram, train...). By introducing the line tag and dropping the route you're going against common usage, and solving something which isn't a problem at all by making the tag structure a bit more ugly and illogical. --Eimai 15:27, 2 June 2009 (UTC)

I've just reread the page after seeing the answers to my question above and the other points raised. As relations have a type, I'm assuming we would have something like (for my bus route)

type=line
line=bus
<etc>

which would contain two relations for the forward direction and the backward direction of the bus route which would be

type=line_variant
from=A
to=B

and

type=line_variant
from=B
to=A

Whether there is any advantage to type=line/line=bus over type=route/route=bus other than consistency and to aide identifying old style route relations from this proposed scheme I'm not sure. Or perhaps I've misunderstood it all again. --EdLoach 10:07, 9 June 2009 (UTC)

I can see the benefits of separating the entities that correspond to physical tracks and train services, but it seems to me that the terms 'route' and 'line' that are proposed go against natural English usage. For me a train line is the physical track route (see eg East Coast Main Line), while a train route corresponds to the route taken by a particular train service. -- Rjw62 07:52, 1 July 2009 (UTC)

I second that. In general usage and industry terminology, a 'line' is a physical stretch of tracks. The hierarchy (for railways) goes:
One or many Trains (physical boxes on wheels) run passenger services along a certain route,
each route is carried along one or many Lines,
Lines are made up of one or many tracks,
tracks are made up of 2 rails and some sleepers(EN-gb)/rail ties(EN-am), which is beyond what we can map.
As has been established by the need for some sort of "tracks=*" tag, the "railway=rail" tag represents a line, not a track. Therefore all a line (route in your terminology) needs is to be tagged as "railway=rail" and "name=*". If it has to be done in several ways (not unusual) then this can be done using relations (eg "type=route, route=line, name=*") if it felt important to group them together. If you ask me, this makes more sense than changing it all round again. "type=route, route=train" is more intuitive, plus also works for buses, trams etc. For example, the Southern Vectis bus company refer to their services as 'routes'.
There are certainly very few bus/train operators in the UK branding services as 'Line X'. The main exception to this rule is the London Underground - but even here there is the distinction between (for example) 'a District Line service calling at all stations to Upminster' and 'The District Line', which includes several branches and does not coincide with all the services operated on it. I am aware of the German terminology for a bus/tram etc. route 'linie' being very close to the English 'line', but given the map is using English terminology where possible, I see no point in deviating in this particular case. --CunningPlan _{What's on your mind?} 14:56, 7 July 2009 (UTC)

Current usage for several route relations: a bus line (the route a bus follows over roads):

type=route
route=bus
ref=1

a train line (the route a train follows over railway tracks):

type=route
route=train
ref=1234

a road with certain number (e.g. E19, A1 etc.):

type=route
route=road
ref=A1

a railway line with certain number:

type=route
route=rail
ref=12

There's no need at all here to introduce a new type=line, as these seem to work very well already, so please adjust the proposal accordingly. --Eimai 15:28, 7 July 2009 (UTC)

Stops with multiple References

Here in Calgary, the reference number of the stop(s) is also used for a phone information line, and there can be multiple reference numbers for the same physical stop. For example: http://www.flickr.com/photos/24244464@N03/3404394275/in/set-72157616141573713/

Should a mapper place a single 'Stop Area' node, with 'ref=1234;5678' or multiple 'Stop Area' nodes? If multiple nodes, should they be spread out or placed at the same lat/long position? --Mungewell 15:24, 1 July 2009 (UTC)

Never stack nodes! One road sign one node. The meaning of the sign should be represented by tags or relations. 'ref=1234;5678' seems to be a good solution for this. --Phobie 00:39, 2 July 2009 (UTC)

Bus Stops on non-walking ways

In the examples the 'Stop Area' example shows linking 'public_transport=platform' AREA to a node with a 'public_transport=stop_area' relation.

In the situation where there is a bus stop on a non-walkable ('foot=no') way, can we simply have (without the need for a relation) a 'public_transport=platform' WAY linking the nearest footway to 'stop_position' node? If so, would it make more sense the tag this way as 'public_transport=access'? --Mungewell 15:44, 1 July 2009 (UTC)

types of rail service

I think there might be a place for a fifth & sixth type of rail service, lying between the long_distance and regional/commuter services. I also think the services ought to be roughly defined. Based on my experience modelling the economics of various services, I'd suggest something like:

• commuter - typically 4 or more tph (trains per hour) off peak, each way, typically all-stations (this is the level at which passengers just turn up at random, and don't bother looking at the timetable)
• regional - typically all-stations, less than 4tph
• outer_commuter - typically 1-2 tph, runs fast to edge of city built-up area, then serves a series of stops outside the built-up area, sometimes all stops, sometimes only principal stops
• regional_express - runs 100-200km calling at principal stations, and some small stations when there's no regional service available to make the stops
• long_distance - runs 200km+, and calls at principal stations (large towns) only
• high_speed - runs 200km+, with typically at least 30 mins between some stations, and speeds of c200km/h+

--RichardMann 13:11, 8 July 2009 (UTC)

Types of rail services in Belgium for later reference, and to give an idea. Each train has one of these categories:

* IC (InterCity): only stops at major railway stations

* IR (InterRegio): also stops at several smaller railway stations

* L (Local): stops at (almost) every station

* CR (CityRail): Brussels suburb trains, stops at (almost) every station

* P: (Rush hour train): additional trains at rush hour, number of stops vary

* ICT: (tourist train): additional trains to touristic places when there's demand for them, number of stops vary

* Extra: additional trains for several events

* Several international trains (includes high speed services)

Note though that an IC/IR trains don't necessarily stop at major stations only, at the ends of a line they can stop at each station for example. --Eimai 14:00, 8 July 2009 (UTC)

Multiples terminal stop

Hello,

I have a question : I'm a french user and in my region, we have many lines with multiples initial and terminal stop. For exemple, in Paris' region, there is the RER D and his structure is [2]. What is your suggestion for mapping this ?

Thank's

JonathanMM 10:43, 14 March 2010 (UTC)

PS : I'm French, sorry for my english :)

Let humans map, leave processing to computers,

I have read your proposal, and I am very happy that somebody has suggested a standarized approach, but in my opinion this one goes too far, i.e. I see it as being more form than matter.

Here are my comments:

• "Separate relations shall be used for each direction of a line": Why use two relations in each direction? In Europe, 99,9% lines utilize the same route there and back. Does this model intend to include North American bus routing? If not, then from= and to= tags suffice. Otherwise I see two relations per line as hell on wheels to manage. If we want to provide routing info in the future, then Joe-at-the-bus-stop knows whether he is going in the direction of Ortsmitte, or the opposite, from these tags.

• more on the above: I feel the "Model for lines" is too complex. Joe The Mapper is not going to be able to memorize it, and neither will he feel like checking it out every time he wants to add a line. A simple type, route, ref, from, to, network suffices for most uses I can imagine. I started with 'type, route, ref", and those lines are nicely mapped on ÖPNVkarte. Of course, route options can be added, but should not be mandatory. Moreover, I could not find a way how to bind relations into a collection in Potlatch, nor in Merkaartor. Consider the position of a semi-beginner, or is OSM going to be locked out for them?

• In your proposal I see platforms bundled into a relation, which is bundled into another relation, etc. The creators of the idea of relations specifically mention that relations are NOT like a Wikipedia category, that information on OSM is bound by geography, not by relations. While I see the sense and apparent ease in organizing data into B-trees, that is hierarchical relations, I also understand what the authors (of relations) meant. A tag on an element, and the element's location are what distinguishes such elements on a map. A relation is simply not necessary.

• More on the above: I see no need to put all bus/tram routes into a relation called "network" if the bus/tram route has a tag network=.

• Get rid of the "operator=" tag! Who cares whether the bus is yellow-and-blue or white-and-red? The average Joe The User does not; he cares whether he is in VerkeghrsVerbund, that is whether his ticket is valid, and that is what the "network=" tag tells him. Besides, in many countries there is a requirement that the buses be in identical livery all over the network. E.g. is London.

• Coming back to nesting of relations, having more than two, or exceptionally three, levels in B-Tree makes the understanding for a Layman Joe The User quite difficult.

• Last but not least: I am trying to stick to your model as much as possible, but could you please provide some examples for most common combinations? Right now I simply look into nearby cities and copy their solutions, sometimes not correctly. I have mapped so much that people start copying from me, including my mistakes. I would really like to see specific examples, a ZOB with n platforms to start with.

Final remark: I would rather spend time on entering data than organizing it by hand; the latter can be done with a script, the first must be done by humans. I think that the author went too far when designing the schema, because the schema may overgrow the data. I would suggest good slimming. Let humans map, leave processing to computers,

Regards,

LMB 21:34, 19 May 2010 (UTC)