Add city name to stop
Opened this issue · 18 comments
When generating national GTFS feeds it is important to have the possibility to add the city name to a stop because it is very likely that one stop name exists in various cities.
Example: Managua, Mercado Mayoreo (Bus stop Mercado Mayoreo in Managua, Nicaragua)
At least Navitia should add the city automatically to stops based on information from OSM. If you add this to stop names, you would see the city twice in Transportr.
In Transportr Nicaragua city names are missing from the stop names, so for example I only see 'Hospital'. Do I need to configure anything anywhere in order to automatically add that name?
You need to talk to the navitia people about this. AFAIK it needs administrative boundaries with admin_level = 8 (cities) to build streets and addresses. Also, make sure that you included OSM data in your server for this region.
All the GTFS i encountered doesn't specify city names in stop names. I don't think adding this information is a god idea if it's a workaround specific to navitia.
Just in case, there is also the difficulty of specifying the city level to take into account, that can be different from a country from an other, and with exceptions for some cities (example of London in UK).
I agree : I don't think adding city to stop name is a good GTFS practice.
In my opinion, this could be handled in a custom creator if really needed
@ialokim I'm not sure to understand your question. Are you asking this in navitia or in osm2gtfs ?
In Navitia, the city construction is automatic but has to be enhanced. In osm2gtfs, I don't think it's a good idea to add the city name to stops.
I was asking about navitia, sorry, my fault.
In Navitia, the city construction is automatic
So can this city name automatically be appended to stop names? Or can it be accessed within the API when requesting stop details?
To keep it simple, Navitia loads cities from OSM with the boundaries. Each point (stop, Point of Interest or address) is associated with administrative_regions. The labelof the object gives a preformated text with the stop name and the city name. The raw stop name and the properties of the adminstrative_regions can also be accessed.
There could be several in case of stop areas grouping stop_points of different cities, for example : https://canaltp.github.io/navitia-playground/play.html?request=https%3A%2F%2Fapi.navitia.io%2Fv1%2Fcoverage%2Ffr-idf%2Fstop_areas%2Fstop_area%3AOIF%3ASA%3A59%3A3681487
Tell me if you want any more details ;-)
Okay perfect, thanks a lot for this explanation! So definitly there's no need to add city names to stops inside osm2gtfs.
Testing it on our own navitia instance, it seems the label is always equal to the name. We've included OSM data for Nicaragua. Do we need some extra settings and would it work on navitia.io anyway or is it a problem with the OSM data?
Looking at pte's source code, I'm fearing this label field isn't supported there, so probably we should open an issue or PR over there.
PTE should already take the city of the first administrative_region and add it to the place variable. The label of the object with the preformated text is not what you want in PTE.
PTE should already take the city of the first administrative_region and add it to the place variable. The label of the object with the preformated text is not what you want in PTE.
Looking at the code, it seems it only does in some cases (hardcoded, in German language), see here. That would definitely not work for Nicaragua.
I am afraid, you are looking at the wrong code. Check this: https://github.com/schildbach/public-transport-enabler/blob/master/enabler/src/de/schildbach/pte/AbstractNavitiaProvider.java#L244
Okay, my fault, the place variable is public, but it isn't used by the uniqueShortName() function which is used inside Transportr. It seems that it could be fixed inside Transportr then by not using the uniqueShortName but combining stop and city name here.
It is used by Transportr for location auto-completion.
Okay, perfect.
I suggest you inspect the API results of your instance directly to see if administrative regions exist there.
We already know that they are not, but I wanted to be sure they could be shown by Transportr. Thanks a lot for your explanations!
I think this could be closed.