Service Area Analysis behaves completely random

[RavenSchmidt]

Hi, I have created a Script to download Street Data from OSM and compile a working and ready to use Public Transit Network Dataset. This Script hast worked several times and the analysis results made sense. Now however, I exported the ND template from that working ND and use it again for the script. All the properties are as they should be and the ND is properly built, of course.

But none of the results make sense. They are even erratic. If I make a Service Area Analysis the resulting isochrone is way to small. I run it as lines instead of polygones and it coveres the complete Network. Once the resulting line neither started nor ended at the facility, despite it being located on a valid street. I double checked all the restrictions, travel modes, etc. All seems to be in Order, but nothing works, and nothing has changed since it last worked...

Has someone encountered a similar problem? For a nifty idea I would be rather grateful. Cheers

[Amir-Sarrafzadeh-Arasi]

Dear Rave,

I hope you are doing well,

I have attached a repo of my github in which I have extracted the railway data of sweden with OSM.

https://github.com/AmirSarrafzadeh/OpenStreetMap_Railway_Sweden

If you need more info please let me know

Best regards

Amir

[MelindaMorang]

This type of behavior is usually a symptom of some kind of network dataset configuration issue.

OSM data usually has long street features that have vertices at intersections instead of endpoints, so you need to use Any Vertex connectivity instead of End Point connectivity.  Otherwise, you'll have a lot of situations where you can't make turns.  This could cause some weirdness in terms of what roads are covered by the Service Area.  All about connectivity: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/understanding-connectivity.htm

Another common problem is if the cost attribute is incorrect.  If you see the whole network being covered or routes erratically squiggling through streets in a nonsensical manner, it could be that the impedance of all the edges is 0.  In that case, the solver has nothing to optimize, because it doesn't cost anything to travel anywhere.  Check the evaluator configuration for your streets.  All about cost attributes: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/cost-attributes.htm

[RavenSchmidt]

Hi Melinda, 
thanks a lot for your quick response. I don't know if it's because I used osmnx to download the street data, however my OSM-streets are all short features from intersection to intersection.
The cost attribute was set correctly as well.

As it turns out the problems appeared because I used supposedly optimized and error-corrected GTFS-data instead of the vanilla one. What this has to do with travel by foot or bike or car, I have no clue, but the strange behaviour disappeared, once I gave it the other GTFS-data.

If you have any idea why it might have caused the problems I would of course like to hear it.
Tanks

[MelindaMorang]

Can you share the bad GTFS dataset with me?  Off the top of my head, I can't think what would cause this problem, but I'd be interested to see it.  I'm always curious about new ways people find to break GTFS data (to make sure my tools can handle it).