GTFS parser has difficulties with stoppoints without stoparea. about navitia

[l-vincent-l]

The wanted behavior is too create a stop_area for stop_point which don't have one.

This should be done in: https://github.com/CanalTP/navitia/blob/dev/source/ed/connectors/gtfs_parser.cpp in the function StopsGtfsHandler::handle_stop_point_without_area
What is the GTFS file you are using?

[antoine-de]

To complete Vincent's answer, we create a stop_area for the stop_points only if no stop_area were provided.

If at least one stop area was in the file we consider a stop_point without a stop_area as not consistent.

If you think this is too harsh, maybe it would be useful to have the possibility to soften the coherence checks with a parameter, but I think the default behavior should be quite strict with the coherence of the imported data.

[koch-t]

Thanks for the clarifications on this.

I'm using the GTFS file of The Netherlands (gtfs.ovapi.nl/nl), where there are quite a few stops without stop area's. That is partly because the Dutch IFOPT dataset is still in the development stages at this point. The other reason is that some operator's do not consider a single stoppoint to be a stoparea, this situation can for example occur in a oneway street.

I would suggest to also artificially create stoparea's for feeds where not every stop has a stoparea. I strongly suspect there will be other feeds exported this way.

Oh and i found that piece of code already and last night i made this commit on it, which should have been a pull request already.
koch-t@f2ba9ec