Connecting Public Transit Stops to Streets - No geometry for any StopConnectors

[RyanSnead]

Hello, I am trying to build a network data set for the public transit system in Allegheny County, Pennsylvania by following the steps in the "Create and use a network dataset with public transit data" tutorial (link below) and template. Everything works exactly as it is described in the tutorial except for the creation of the StopConnectors feature. For some reason, none of my stops snap to any street. All features from the GTFS to Network Dataset Transit Sources seem to have been populated correctly. I made sure to project the streets file to match all the other features in the geodatabase/feature dataset that was created. Additionally, I tried increasing the snap distance from 100 meters to 1000 meters but no change.

When I zoom in and compare matching Stops IDs to StopsOnStreets IDs found to have missing geometry in the StopConnectors table, they all seem to completely overlap one another. Most stops are reasonably close to a street as well. I'm at a bit of a loss. Any idea why I'm not getting any StopConnector geometry?

I attached the project below with the model I created to run the entire process. I tried to include the GTFS files and street centerlines but they are too big to attach. The template can be found following the link below but the issue arises before it is necessary and the template has worked without issue.

Thanks!

https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/create-and-use-a-network-dataset-wit...

[MelindaMorang]

Unfortunately, that aprx file by itself isn't helpful.  Because the data and all the associated files and stuff are missing, it's not possible to see the toolbox or anything in the map.

Anyway, I'm happy to try to help you with this problem.  If I understand correctly, when the tool runs, the stops are not getting snapped to the streets, which results in StopConnector features with null geometry (because they are connecting two points that are directly on top of one another).  It sounds like this is a true for the entire dataset, not just a few features in select locations.  This makes me think you have accidentally used an incorrect SQL query when running the tool.  Did you use something there?  Or, there could be some problem with spatial references.  You said the data draws correctly on the map.  Does it match up with with one of Esri's basemaps?  (It's not in Antarctica, the ocean, or out in space, is it?)

Maybe post some screenshots?

[RyanSnead]

Thanks, Melinda! You are correct that no stops are being snapped to the street and this is true for the entire data set. When you say the two points are directly on top of one another, are you referring to the Stops and StopsOnStreets features or one of the former and the Streets feature? The Stops and StopsOnStreets do completely overlap but they are, I believe, on the rail line and not the street. I attached a screenshot with one example. The brown line is the street and the green line is the rail. The two points represent stops on either side of the rail going in opposite directions. Those points both have overlapping Stops and StopsOnStreets features on them.

Regarding your SQL comment, I didn't use SQL except for one expression during the Connect Network Dataset to Streets tool which says to restrict pedestrians from walking on certain streets. But that field is completely null as I only added it to run the template. I tried running this with and without the expression and it didn't seem to make a difference. I didn't knowingly use SQL in this process outside of that.

The spatial reference was my thought. You can see the streets are not out in the ocean or anything but also don't line up exactly with the basemap. All the layers have the same projection, though (NAD 1983).

If there is another way to share the files, I'm happy to do that as well! Any thoughts?

[MelindaMorang]

Yes, the way the Connect Public Transit Data Model to Streets tool works is that it creates a copy of the Stops feature class and uses the Snap tool to snap the copied stops to the streets.  It then generates straight lines between the original Stops and the copied StopsOnStreets.  But if the copied stops fail to snap to streets, then the Stops feature and its corresponding copy in StopsOnStreets will be spatially coincident.

If you want to share your data, I can take a look.  You can put in on any fileshare where I can download it, and that should work.  If you don't want to make it public, you can send me a private message through Esri Community with the information.

I still think the problem is likely to be with the SQL expression you used.  If you want to post a screenshot of the tool parameter and the field in your data that was used, that might give me a clue.

[RyanSnead]

Oh, I see what you're sharing. This link will give you all the data and files you need. It is all publicly available anyway. https://drive.google.com/drive/folders/1jq629D0R7oQcIHvHWjDY6fWVp1c7ugXy?usp=sharing

I attached a screenshot that shows the SQL expression as well. I hope it's as simple as a SQL issue. Thanks so much for your help!

[MelindaMorang]

Okay, I was able to download your data and play with your model this time.  I still don't know quite what's going wrong, but it seems like if I just remove the Expression entirely from Connect Network Dataset Transit Sources To Streets, the problem goes away.  Since you're adding the RestrictPedestrians field in the model and not populating it with any values, there is no reason to use the expression anyway.

When I run your model this way, the stops successfully snap to the streets, and the StopConnectors are created as expected:

There are still a small handful of build errors where StopConnectors have no geometry, and this is likely just a few locations where the Streets doesn't cover the area where the Stops are located.

I will keep hunting for the root cause of the problem, but I think this should resolve the problem for your specific case.

[RyanSnead]

Thank you so much! I added the expression in there since the tutorial states that GIS would see the Null values as a street not being restricted. I'll take it out and check the handful of locations for now. Did you use the model that I had built or did you go through each step manually?

[MelindaMorang · Accepted solution]

Yes, I used your model.  The model itself seems fine.

I believe what's going on is that the SQL Expression ignores rows with null field values when checking for RestrictPedestrians <> 'Y'.  Since all your rows have null values for the field, no rows are returned, and the tool tries to snap the stops to an empty feature layer.  You wouldn't think it would work this way since null is not equal to 'Y', but I guess this is how the SQL Expression control works, or maybe SQL more generally.  You can test this behavior using the Select Layer By Attribute or Make Feature Layer tools.

The reason the tutorial instructs you to use an Expression is that it earlier instructs you to populate the RestrictPedestrians field with values of "Y" and "N" to designate which streets are restricted to pedestrians and which are not.  Since your model skips that step, there's no need to use an expression.  But, once I confirm the behavior of the SQL Expression with null values, I'll see if I can update the tutorial and the tool doc to make a note of this unintuitive behavior.  The network dataset itself, if created using the provided template, will have no problem with the null field values.  The only issue is in the Connect Network Dataset Transit Sources To Streets tool when snapping the stops to the street features.

(FYI, the Connect Network Dataset Transit Sources To Streets tool was renamed to Connect Public Transit Data Model To Streets in ArcGIS Pro 2.9 and moved to the new Public Transit Tools toolbox.  Since your model includes the tool's old name, I presume you're using an older version of ArcGIS Pro.  Updating to the latest version is always a good idea so you can get the latest bug fixes and new functionality.  Nothing in that particular tool has changed since then, and the old tool names will continue to work in models and scripts, but it's still a good idea to get the latest if you can.)

[MelindaMorang]

Okay, I got confirmation from a colleague about how SQL is behaving in this case, and my suspicion is correct.  Apparently nulls are considered separately, and this is standard behavior for the version/flavor of SQL used in Esri's file geodatabases.

As I said before, if all your RestrictPedestrian row values are null, you don't need an expression at all.

If you have some null rows, you should include another clause like this:

Or use the SQL editor and use:
RestrictPedestrians <> 'Y' Or RestrictPedestrians IS NULL

I've updated the tutorial with a cautionary note about this, but you won't see the changes until the next Pro release, probably.

[RyanSnead]

Excellent. Glad that is sorted and it was a simple solution! Thanks so much. I really appreciate all of your help!