Proposal talk:Unified stoparea

Manchester

I've started to use this scheme a bit in Manchester, eg see [1] and [2]. Let me know if I'm doing anything wrong... Frankie Roberto 10:17, 17 February 2009 (UTC)

In your first example [3], you should add the halts (stop points) to the site-relation as well. And the platform should be highway=platform not amenity. In this case you could use railway=platform if you feel more comfortable with it. The role "platform" would not be necessary. As the name is in the relation, the name-tag would not be needed anymore on the tram_stop. To render nicely until this relation is interpreted, I would keep the name tag on one tram_stop (not both, to avoid clutter).

Thanks, I've made all these changes. Frankie Roberto 00:22, 18 February 2009 (UTC)

If that untagged area next to the platform is some kind of terminal building, It should be tagged accordingly (amenity=station;building=yes??) and added to the site-relation.

That area is actually a kind of pedestrian square with a little bit of grass and a war memorial in it. I haven't quite figured out how to map it yet.Frankie Roberto 00:22, 18 February 2009 (UTC)

In the second example [4] the platform and halts are tagged correctly. station=platform isn't adding anything, though, and should be removed. In the relation you got railway=tram_stop, which should not be there.

I didn't change anything yet, but I could gladly correct the tagging if you like.--Gerrit 21:57, 17 February 2009 (UTC)

I think I've fixed this one now too.Frankie Roberto 00:22, 18 February 2009 (UTC)

Looks good. In one of them you used highway=platform and in the other you used railway=platform. That is OK though (and they will render the same). --Gerrit 00:47, 18 February 2009 (UTC)

I've just mapped this station: [5] - could you have a look at that one too? It has a footbridge to complicate matters, and two of the platforms are joined, with a station building on it. The two island platforms also have a platform number for each side - I wasn't sure how to map this. Frankie Roberto 00:22, 18 February 2009 (UTC)

I would actually map platforms mainly as a way and seldom as an area (example). Anyways, I would split the triangular platform in two and but the building in between (station-building is also added to relation). Btw: if you map the platform as an area, it needs the area=yes-tag just as any other area (this is also true for the other examples). --Gerrit 00:47, 18 February 2009 (UTC)

Oh really, I thought area=yes was mainly a hangover from the past, and was now implied from the data? Seems a bit unnecessary. Frankie Roberto 08:11, 18 February 2009 (UTC)

You may be right. But how does one distinguish circular roads from areas? Should we have different tags for platform areas vs. ways then? --Gerrit 08:38, 18 February 2009 (UTC)

Halt

Where should be halt node placed in case of long vehicles (trains, trams)? Is it the point, where the front side of the train usually stops or the point somewhere in the middle of the train? --Vrabcak 15:36, 17 February 2009 (UTC)

I put the answer on the main page (under "best practices"). I will remove this entry from discussion when it answers your question. Thanks for asking. --Gerrit 21:57, 17 February 2009 (UTC)

I guess it doesn't matter too much - but I've been adding the halts roughly in the middle of where the train/tram would stop. Frankie Roberto 00:09, 18 February 2009 (UTC)

To be backwards-compatible, is it okay to allow railway=station for railway halts? Frankie Roberto 00:11, 18 February 2009 (UTC)

I wouldn't use it. A Halt would be one single stop point, probably amongst many. A railway=station could be seen as an alias to "1 ore more halts around here somewhere". If anything I would understand if it is used synonymously with amenity=station, but I would get rid of it as soon as I start to map a train station in finer detail than single node. --Gerrit 01:09, 18 February 2009 (UTC)

For compatibility reasons, it might be OK to have one central halt also tagged as station (i.e. railway=halt;station), but I wouldn't advocate it. --Gerrit 16:08, 18 February 2009 (UTC)

Sheffield

Okay, so another station mapped, this time a big one: [6]. Some things I found:

• Had to use ways for platforms as it's tricky to be detailed enough to draw them as areas. However, some are split ways as there are a combination of through lines and terminus lines. Frankie Roberto 08:17, 19 February 2009 (UTC)

• I also prefer ways for normal platforms. I don't see the plit ways as a problem. As long as they have the same ref, they belong together. --Gerrit 23:22, 26 February 2009 (UTC)

• Adding platform names to the platforms quickly got messy, as some platforms serve up to 4 'halts'. So I experimented with adding the platform names to the halts themselves. What do you think about this? Frankie Roberto 08:17, 19 February 2009 (UTC)

• OK, I have never seen that actually. You could either split the platform in 4 (naming them ref=7a, ref=7b, ref=7c, ref=7d or whatever their names are). In Sheffield, platforms 2-5, you would tag the lower (single) platform as ref=2a;5a, the one on the upper right corner would be ref=2b;3, the upper right is ref=4;5b. btw. You forgot to add the upper left platform to the relation and I guess you mean "2a" (instead of "3a") for the lower left side of the platform. I wouldn't put this ref on the halt. that would be confusing. Apart from that there may actually be a ref for these halts, I'm not a railway-person, so I wouldn't know. --Gerrit 23:22, 26 February 2009 (UTC)

Hmm, this is tricky. I can see why semantically, it'd be more logical to tag the platform ways/areas with the platform numbers, but adding the platform numbers to the halts give you more information (it tells you where to stand). Perhaps the solution to this is 'boarding points' with the platform numbers as nodes along the platform way or within the platform area? Frankie Roberto 10:05, 26 February 2009 (UTC)

Adding the platform number to the halt's ref might lead to trouble, if there is a platform to both sides of the rails. On the other side it should be sufficient to label the platform 7;8. once you are there it's just a 4 meter walk to the right side of the platform. :)

Boarding points could be some optional feature, but it adds too much hassle for the benefit to make it mandatory. --Gerrit 23:22, 26 February 2009 (UTC)

• There are 4 through lines which don't have any halts. I wasn't sure whether to map these or not. They make the station more 'complete' but don't add any useful information. Frankie Roberto 08:17, 19 February 2009 (UTC)

• I would map the trough lines, (as they are actally there), but they are not part of the stop_area-relation. --Gerrit 13:51, 19 February 2009 (UTC)

Roles

Think it might be useful to be clearer in the proposal where roles should be added to relations, and where not. Frankie Roberto 14:18, 18 February 2009 (UTC)

I haven't come across any need for roles yet. Do you have examples where a role would be helpful? --Gerrit 15:31, 18 February 2009 (UTC)

You're right, I've mostly been using them to duplicate information (my bad). Frankie Roberto 09:34, 26 February 2009 (UTC)

Terminology and modeling

This is all very good stuff however can we however reserve the term Stop Area for what Transmodel calls a Stop Area. This is defined as a group of Stop Points that are close to each other and we should model this as a relationship containing a number of Stop Points.

Can we also refer to the generalised feature where one waits for public transport (be it a bus or a tram or a ferry etc) as a Stop Point (so Stop Points can be aggregated into Stop Areas). This conforms to the international standards used within EU and elsewhere and which are being proposed at ISO level. This is a theoretical concept and might not relate to any actual infrastructure (for example some bus stops in the UK have no pole or anything, people just have to know that is stops outside the farm). Transport schedules should give timings for a list of Stop Points.

Any Infrastructure such as poles, shelters and benches etc are modelled separately, although the shelter or pole will also be coded as the stop point by convention.

Making a distinction between the place where the vehicle stops (a node within the road/rail network) and where the passenger waits (beside the road/track) is very useful and it is also useful to harmonise that across modes.

Stations are mode complex and it might be useful to check out this standards document from pages 42 to 66 IFOPT standard.
PeterIto 04:58, 26 February 2009 (UTC)

• From my very brief scan of the ISO document, the places where passengers wait are called 'Quays' (which belong to a 'Stop Place'), each of which can have many 'Boarding Position' (eg a train station platform has lots of boarding points corresponding to where the train doors are likely to be). Is that about right? Frankie Roberto 09:41, 26 February 2009 (UTC)

• I'm the original author of the unified stop area proposal. I am very happy about the attention this whole bus/train/etc stop thing finally gets. When I tried to figure out names for the elements, I mostly used existing tags or those close to them (railway=platform => highway=platform). This happened for two reasons. 1) to use as many existing elements as possible and 2) because as I'm not a native english speaker and I was unsure about good terms. Reason 1) still stands, but I would gladly agree to rename things like platform to quay.

There are three main points I deem important:

1. Easy to understand/logical/simple, but still extensible (as few mandatory elements as necessary as many optional refinements as possible)
2. As compliant as possible to standards as Transmodel, Naptan, etc.
3. Able to satisfy all possible usages inside OSM (displays well, suits automated usage in e.g. routing, ...)

The most difficult part is to not give up one of these principles in favour of some other. If we took over Transmodel one-to-one, we would definitely loose 1. and probably on 3. also. This just as a short reminder to keep in mind. --Gerrit 19:25, 26 February 2009 (UTC)

• We are also fortunate to have input from the main author of the CEN IFOPT document (User:NickK) into this proposal. I suggest we continue to work on it to see if we can reconcile the ideas in both. I am keen that we Transmodel terms and modelling for the features in OSM where there is a direct relationship, and for these features we refer to Transmodel for the definitive definition. There are probably only about 10 fundamental elements we need from Transmodel, but it will make it much easier for us to accept professional public transport data from Europe and beyond if we follow the standards. PeterIto 05:26, 9 March 2009 (UTC)

Cascading Stop Places

The NaPTAN standard allows for StopAreas to belong to other StopAreas, for example the bus stop grouping outside of a railway station will 'belong' to the station's stop grouping. Currently I've implemented it in the NaPTAN importer to just make the child relations a member of the parent relation without any explicit role. --Thomas Wood 16:06, 14 March 2009 (UTC)

Highway=Platform

The highway=platform combination is unknown, please propose it first, I see difficulties with piers (Und mit Einstiegszonen von Ski-Liften, ...)

--Lulu-Ann 10:46, 27 March 2009 (UTC)

Perhaps I missunderstand anyting, but when I read Approved_feature/platform highway=platform is defined and approved. --Teddych 06:12, 25 October 2010 (BST)

also, why would amenity=parking be added to the relation but not highway=platform? --sargas 20:06, 18 April 2009 (UTC)

Probably someone thought about an amenity=parking next to a train station. I didn't put it in that list and I'm not sure it should be there, either. highway=platform isn't in that list as it is mandatory. The lists items are optional. I added an "also" to the title to reflect this.

type=site and site=stop_area

Couldn't we use public_transport=stop_area instead of the combination of type=site and site=stop_area for a stop relation? For this would save us one tag and nevertheless identify the relation as a stop area. Also, the relation type site is still a proposal. -- Oxomoa 14:59, 21 April 2009 (UTC)

Well, why do we use highway=service + service=parking_aisle instead of highway=parking_aisle? Because the majority of applications don't really need to know what type of service way it is and can ignore the additional tags, which makes using the data easier. For the same reason, it's desirable that an application can handle this just as any other site if it isn't optimized for public transport. (Render a label in the center, highlight the whole site when selected, whatever.) --Tordanik 22:10, 21 April 2009 (UTC)

Oh, and btw, its common for relations to always have a "type" tag. Don't see a reason to give that up. --Tordanik 22:12, 21 April 2009 (UTC)

Exactly. type=site is enough information for most purposes ("things that belong together"). Its similar to type=route which can be either bus/tram/cycle/... --Gerrit 18:16, 24 April 2009 (UTC)

when a stop is considered one

it says on the page : "A simple bus stop often consists of two Halts and two Platforms (one on each side of the road)".

are there any limits to when stop is considered one, like how far apart individual halts/platforms are, or is it all depending on the name ?

for example, see the three bus stops at this intersection : http://www.openstreetmap.org/?lat=57.18265&lon=25.03531&zoom=17&layers=B000FTF - would that be a single stop ?

as an opposite situation, what if two bus stops are on the opposite sides of a road, but they have different names on the signs - like http://www.openstreetmap.org/?lat=57.18703&lon=25.05216&zoom=17&layers=B000FTF - would there be two relations ?

Good points. Hopefully others will share their ideas. In my opinion, the only feasable way for the mapper to do it is to consider everything with the same name as one stop entity. Everything else is wishy-washy. :) If a stop is hundreds of meters from another one with the same name, that is strange, but than it's the bus operators fault. Maybe there is a reason, we don't see yet, so I would always use the stops name to form a relation.

On the other Hand, two stops next to each other might have different names and thus form different relations. I don't see a problem here either. Routing algorithms could still use this for bus changes, as the position and thus proximity is given in the data. One often seen similar szenario is a train station with a central bus station near to it. They usually have different names, so I would have two different relations and I don't see a problem with it. But if the need arises, I would propose a new kind of relation to group them.

--Gerrit 16:28, 27 April 2009 (UTC)

thanks for the answer. that confirms my feeling that name should be the primary factor (even though sometimes names on the signs do not match despite being very close to each other). as for stops being far apart and operator's fault, at least here that's hardly a case, as bus stops are formed on historical, local municipalities reasoning and who knows what reasons ;) - there might be several operators, using the same set of stops.

so i'll settle for grouping with relations based on names - but what about quay/halt coupling ? should they be connected in any way, so that software knows which quay is connected to which halt[s] ?

as a purely theoretical example, constructed in josm (no, i did not upload it :) ), see :

would it be needed to know how quays correspond to halts - which would also allow to determine which quay/halt is applicable in which direction ?

--Richlv 19:25, 27 April 2009 (UTC)

Relation:route for public transport defines member forward/backward_stop. It will be easy to identify for which direction is halt applicable. And, if halt has only one quay, then it is easy to select (find) needed quay.

But here will be still a problem, if one halt has more then one quay linked. And we don't need to have so complicated situation like on image above, it is enough to have one road with one halt for both directions and two quays on each side of road. Need to use driving rules, to solve this? -- Aleksejs 09:57, 22 July 2009 (UTC)

IFOPT names

Why don't we use the IFOPT names for parameters? there are not cryptic or something. STOP_PLACE, VEHICLE STOPPING POINT, BOARDING POINT, QUAY (and ACCESS_AREA). These 4(5) terms we need for a useful/better routing. --Cbm 11:23, 18 July 2009 (UTC)

Waggon stop positions next to a platform

In large railway stations in Germany there are letters used to indicate the positions where the passenger waggon stops. This enables the waiting passenger to stand near the correct door if he has a seat reservation (or at least wants to travel first or second class or want to enter the bistro waggon).

These capital letters can be used as a routing information for pedestrians, so they shall be tagged like a housenumber (works with letters). Then the standard routing algorithmm can catch them.

This will be used for pedestrian navigation for the blind, see project LoroDux.

Lulu-Ann

Transport modes

I'm writing related proposal -- Proposed features/Transport modes and features, so i would like coordinate some tagging. In particular this text:

"If not clear, Platforms can have additional information what kind of vehicle it serves. For example, if bus- and tram is served from the same platform: services=bus;tram. Likewise services=light_rail might exist.",

is directly a subject of my proposal, so I suggest to use my scheme: transport=bus;tram and transport=light_rail repsectively. I also think that other tags proposed by me would be useful. -- Vovanium 20:33, 8 February 2010 (UTC)

Adding to this there may be different types on busses. open top bus, air conditioned bus, etc. --User:andrewfenn

Railway halts and platforms

I do not agree that explicit separation between railway stations and halts should be deprecated. There is palpable difference between these: station is the place where trains are routed and parked but halt is not. Also there are more related technical and administrative differences. Maybe it not so important to a man-on-the-street, but why should they mapped? --Vovanium 20:46, 8 February 2010 (UTC)