public transit network dataset does not get off train

[RavenSchmidt]

Hi, I have created a Public Transit Network Dataset out of OSM-street data and official gtfs-data. It mostly works, but one very important connection does not. And I can't find the reason.

The analysis uses the Public Transit Network, get's off the train, traverses the StopConnector, but does not procede to use the street network. The StopOnStreet appears to be snapped, the object is not restricted and there are actualle two objects, one for each direction.
The other way around does not work either.

The only thing I can think of is that the snappig did not work. However, the python script responsible worked seemingly everywhere else and I cannot do it manually since my company does not care to pay for a Standard License.
Does anyone have a tip for me?
Thanks

Edit:
I have now snapped the StopConnector manually to one end of the line in question and now it works. 

However, I wonder how many not working conections are in the whole network that remain undiscovered.
Is there a way to check for that except manually?

[MelindaMorang]

This is a very reasonable question.  Unfortunately, without the Standard license, I'm not sure there's much you can do to fix these snapping problems in batch.  The Snap geoprocessing tool does this but requires the Standard license, and any manual editing tools would likely require the same.

You said you had a Python script that somehow did the snapping for you even without the Standard license.  I wonder if there's some modification you can make to that to fix the problem up front.  How did you do the snapping there?  I know sometimes if you're using various arcpy geometry methods or GP tools, if your input data have different datums, the x and y coordinates can end up a tiny bit off. Could that be your issue?

[RavenSchmidt]

Thank you for your reply. 
First I used someone elses code to transform the vertices of my street network to points, since the StopConnectors must lie on the vertices. Then I used near_analysis to find the next line vertice from the stop location and xyToLined the output coordintates. All fields are populated (seemingly) correctly.
Regarding the projection/datum, I used the original 4326 of the OSM street data all the way.
I got some errors while building the network stating that some elements are to small to be connected, if I remember correctly. Unfortunately I do not find the error report any longer. But this might be the problem.

If I had access to a highe level License I should probably first check and repair the network topology. Maybe that will change soon. However this might not solve the Problem with the StopConnectors, since they are not part of the street network, but in a seperate feature class?

Could you tell me te usual steps of troubleshooting a public transit network? I find very little about it in the net. For example my network analyses suggest routes that are not suggested by Applications like Google Maps and the connections from Arcgis usually take 1/3rd longer. Is there a way to get more information about the connection decisions that ArcGIS makes, like which bus lines and stops it uses, how long the way on foot is before and after entering the bus or how long the waiting times are?


EDIT:

As observable in thes Screenshot, these errors exist in very many places and the network sadly becomes useless.

[MelindaMorang]

Yeah, I think those build errors are a good clue.  Something hasn't worked well in your process to snap the stops to the street vertices, so you're probably missing a lot of connections.  This is likely a big reason that your calculated routes look a lot different from what you get with Google.

(If you had a higher-level license, you could just run the Connect Public Transit Data Model To Streets tool, and it would do all of the above automatically without you having to worry about topology or vertices, etc.)

This documentation page has some information about how Esri's public transit routing works and some links to more in-depth topics: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/network-analysis-with-public-transit...  The "Considerations and limitations" section at the bottom may be especially helpful.

For various technical reasons, it's not possible to determine exactly which transit line or trip was used with out-of-the-box tools.  However, you can do this with a post-process by downloading the Transit Network Analysis Tools toolbox (from GitHub or argis.com) and running the Copy Traversed Source Features With Transit tool.

For more general troubleshooting, the Explore Network tool is helpful for manually clicking on the map and determining what's connected to a given network element (or what isn't).  You could also run a Service Area analysis using the Lines output to visualize areas that are disconnected, although this might miss some disconnected components if there's another connection further up or down the line.

[RavenSchmidt]

Thank you again for your help.
The Service Area Analysis with lines is exactly what I did and what helped me a lot to discover the connection issues in the first place. I will have a look into those post process tools though. 

And now I found the root of the problem. I used a script to extract the line vertices and use them as points to snap on to (using the Near_analysis tool). However, this particular code did not work correctly (I suspect a roundingn error somewhere). I used QGIS for the vertice-extraction instead and this solved the connection issues!

Regarding the Licensing: as a lowly intern creeping about I sadly have little leverage to push the company I'm at to double their expenses. Might change however in the future...