Improve standard stop creator's station building process

[pantierra]

There are very interesting comments about the standard stop creators, mentioned by @nlehuby and @prhod in the PR #66:

There are different possible scenarios on stop creation regarding "parent_stations" (in GTFS) or "stop_area" (in OSM):

• you can create GTFS stops without any grouping [old behavior]
• you can group GTFS stops using OSM StopArea [current behavior]
• you can group GTFS stops by name and proximity [Accra creator)]
• you can mix it all (using OSM Stop Area and grouping them by name and proximity)

And there were some great ideas on maybe mixing them in the standard creator, or find a way how the proximity search can become part of the general code and not exclusive on Accra.

Let's use this issue to develop further on this.

[pantierra]

As a first step I would suggest to move the function get_crow_fly_distance into the newly introduced Helper class. Then it can be easily included and reused by other creators. I created a PR for this: #115

[ialokim]

Related to this is proper name handling: What happens if the OSM stop_position and platform have a different name than the OSM stop_area? I'm thinking of the way we tagged bus station like this one: Only the stop_area presents the "proper" name, the platforms each reflect the destinations of the buses that stop on this stop_position.

Should all the GTFS stops have the OSM stop_area's name or only the GTFS station? @grote What is rendered e.g. in Transportr, GTFS stop or GTFS station names?

[grote]

Navitia needs stop areas for each stop point. If none exists, it creates one on its own. Both can then be shown in Transportr. The auto-completion shows the stop area, but in trips, individual stop points can be shown, so both should have names.

[pantierra]

I'm curious: does Navitia need OSM stop_areas or GTFS "Stations" for each stop?

[grote]

Their debug output talks about stop areas, but I guess they mean GTFS "Stations". The people working on Navitia can probably clarify.

[prhod]

Hi,
there are some cases where the stop_point and the corresponding stop_area don't have the same name, but in general the name is the same.
In navitia, the "stop_areas" are used mainly for autocompletion (or to find the time-tables of all the lines stopping at one of it's stop_points). The stop_points are displayed in the journey to provide the exact name of the stop that is displayed.
When Navitia doesn't have a stop_area for a stop_point, the stop_area is created (as stated by @grote ), but the actual default creation in Navitia is not very efficient for the moment 😛 (WIP).
I think that OSM stop_areas should be used as parent_stations, but I'm not sure osm2gtfs should create them in the default creator because parent_stations are not mandatory for the GTFS feed.

[pantierra]

Thanks for the explanation. Is this happening on top of the OSM data in Navitia or on top of each GTFS?

Yes, OSM stop_area (with at least two stop members) translates osm2gtfs to GTFS "Station", which means Stop with location_type=1 and another (normal) stop location_type=0 with parent_station set to the stations stop_id.

[prhod]

This is happening on top of each GTFS. Navitia relies on transit feeds to provide stop_areas.

[pantierra]

Ah, OK. So these are Navitia own stop_areas? Or has a GTFS also stop_areas? So far I was only able to find the concept of Stations in GTFS.

Does Navitia create those (internal) stop_areas based on GTFS' parent_station? Or anything else?

[pantierra]

I had a quick look at the Navitia code, and indeed there are stop_area and stop_point. So I guess the data flow is the following:

OpenStreetMap	GTFS	Navitia
stop_area	station	stop_area
platform	stop	stop_point

This means - coming back to @ialokim's initial question - that the name of the OSM platform and OSM stop_area should both contain the name of the stop in order to get presented well in Navitia and Transportr. Or you could implement some logic in a custom Estelí stops_creator to apply the GTFS station's (or OSM stop_area's) name to regular stops. However to me it doesn't seem to be a good practice to call the stop ONLY like the headsign of the bus. And what do you do if two buses use the same stop but go to different locations?

[pantierra]

Regarding the specific station @ialokim was linking to, I would do the following, but I'm really not sure about it. Probably @prhod and @grote can provide better practices:

stop_area/station: COTRAN Norte And each platform, like this: COTRAN Norte: Andén Ocotal and COTRAN Norte: Andén Limay... (Where "andén" means basically "platform" ).

Kind of generic name for the station there are also in Europe, like Gare du Nord and then the platforms/stop_points as Gare du Nord: Platform 10, etc.

Or is there a more suitable way to do?

[prhod]

@xamanu I think your proposal is a good one. Specifying both station name and headsign ensure that people will understand (even tourists). 👍

[grote]

I am not sure that line information should be added to stop names in any way. Even a single stop point can serve multiple lines or one line in two directions with a different headsign.

[prhod]

Reading again the thread, I misunderstood something. I thought the Andén Ocotal was the real stop_point name according to local knowledge. If it's not the case, I agree with @grote , Andén Ocotal should be specified in the to property of the route passing by.
Sorry for that.

[pantierra]

Looking at the example @ialokim posted here, it seems to be a terminal station and usually in Nicaragua the platforms are not numbered but called instead by the 'to' destination. 😀
... this doesn't make it easier, though.

[ialokim]

Looking at the example @ialokim posted here, it seems to be a terminal station and usually in Nicaragua the platforms are not numbered but called instead by the 'to' destination. 😀

Almost correct, it depends heavily on the terminal station if they present numbers, destinations or even nothing. In the case of COTRAN Norte, there are numbers and destinations at each platform and we thought that both should be mapped inside OSM. To clarify a bit more, I think @AltNico has some photos of a terminal station in Managua, probably he could post one here.

But I'm not very sure anymore if putting all this information in the name tag is the best idea, because they could get very long with several destinations on the same platform. I'm thinking of adding the information about the destinations in some extra tag in OSM (probably only as a help for mappers) and renaming the platforms like COTRAN Norte (Bahía 4). What do you think @xamanu @AltNico?

[nlehuby]

I think the GTFS stop_desc is more appropriate for these.
In OSM, the numbers should go into local_ref.

[ialokim]

I think the GTFS stop_desc is more appropriate for these.

Is this used in Navitia @prhod and can it be displayed in Transportr @grote ?

In OSM, the numbers should go into local_ref.

Why not putting it in ref as suggested here? Should we implement a standard function inside osm2gtfs to use this tag and rename the platform as suggested above (COTRAN Norte (Bahía 4)), with a new setting in the configuration to set Bahía? See this recommendation on gtfs.org.

Or is it better to tag the platforms directly inside OSM with this name? But then, isn't the ref tag duplicated?

[prhod]

@ialokim yes, stop_desc is used in Navitia as a comment on the stop_point or the stop_area to provide a way of giving complementary infos on the stops ... like in this case :)

[grote]

Transportr doesn't show this information anywhere though as it is also not supported by PTE.

[ialokim]

Thanks both of you, I've now renamed four main terminals as following: name=COTRAN Norte (Bahía 4) and I've moved the destinations to description which could easily be used by osm2gtfs to generate a stop_desc for the GTFS, Navitia and other apps.

[pantierra]

In my opinion this can be closed. Do you agree? Please do.