nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Resultados Inconsistentes de la Matriz de Accesibilidad Calculada

JosephGarcia

Hola,

Tengo un problema con la herramienta Calculate Accessibility Matrix del conjunto de herramientas Transit Network Analysis. Ejecuté este script usando una selección de Census Blocks como mis orígenes con un conjunto más grande de Census Blocks como mis Destinos. Seguí el mismo flujo de trabajo que se muestra aquí: https://www.youtube.com/watch?v=FAmaK1fVpyY que fue creado por ESRI. De los 5,875 Census Blocks ejecutados como orígenes, 3,784 bloques recibieron un valor TotalDest de 0. Además, hay muchos casos de Census Blocks ubicados uno al lado del otro, donde uno tiene más de 10,000 destinos y los que lo rodean tienen 0. Siendo esta una gran área metropolitana, los resultados son especialmente desconcertantes. Cualquier ayuda o información sería muy apreciada. Esta es mi primera publicación en un foro de ESRI, disculpen si algo se hizo incorrectamente.

Encuentra más publicaciones etiquetadas con

Accepted answers

Melinda Morang

Okay, I figured it out, and I have a fix for you. It was a bug in my code.

The code was assuming that the origins always use a field called "ObjectID" as the ObjectID field, but your data was using "ObjectID_1" for whatever reason. This situation arises when you do joins or various other operations that combine multiple tables. It's nothing you did wrong, just a situation I neglected to account for.

It was a simple fix, and the updated tool is available either from ArcGIS Online or GitHub.

All comments

JosephGarcia

Thank you for that suggestion, it really helped! I'll leave this next part here for any future viewers of this thread.

Using the Explore Network tool I was able to see exactly what was described in the last post, with some roads being erroneously restricted to pedestrians and others being not quite connected to the network. One thing that contributed to the my problem is tied to my use of Open Street Map data for my Streets layer. I found in a number of cases, Open Street Map has line features representing elevated walkways between buildings which fall under the "footpath" highway categorization. These features included skyways between hospital buildings downtown, parking garages to hotels and office buildings etc. These would not necessarily be a problem for this analysis if they weren't the closest feature to the Census Block centroid, and therefore the Street segment the point snapped to. If you are getting weird results in downtown areas and your dataset is derived from OSM data, I would suggest identifying your elevated walkways, they may be the culprit!

Thanks again Melinda for all your help!

Melinda Morang

Hmm, my guess is those remaining problems are some sort of issue in your street data. The census block centroid has to snap to the closest street feature, and my guess is the street is disconnected from the nearby streets. You can investigate those street features using the Explore Network tool, and it will show you which adjacent streets and junctions it's actually connected to. This might help you diagnose the problem. For instance, maybe there is a little gap between the street and the one it's supposed to be connected to.

There could also be some problem with the pedestrian restriction. Maybe those roads are erroneously restricted to pedestrians. Explore Network can tell you that as well if you set the travel mode.

JosephGarcia

Thanks so much for your help with this, the results look much more like they ought to. A few census blocks remain outliers but I believe this is due to some kind of bad connectivity in the network. I've attached some images just in case because I am still learning to use network analyst.

It appears that for the outlying census blocks, if I run Service Area analysis, the results are in line with Calculate Accessibility Matrix, and you can see that the connectivity is limited when lines are displayed. If I change the streets layer in the Network Dataset to "any vertex" more of the census blocks have expected outputs (but not all, these have been selected in blue).

If there is any suggestion you might have on how to adjust, repair or account for these weird phenomena in the network it would be greatly appreciated. I will mark your last post as the solution though --- as I believe for anyone else experiencing an issue like mine, your bug fix will likely fix their issue. Again, thank you so much!

badly_connected_blocks.PNG

service_area_endpoints.PNG

bad_network_connection.PNG

service_area_any_vertex.PNG

Melinda Morang

Okay, I figured it out, and I have a fix for you. It was a bug in my code.

It was a simple fix, and the updated tool is available either from ArcGIS Online or GitHub.

JosephGarcia

I am using ArcGIS 2.9.2

Melinda Morang

Your network dataset looks fine. I'm still trying to figure out what's going on.

What version of ArcGIS Pro are you using? The tool behaves slightly differently depending on the version.

JosephGarcia

Thank you so much for offering to take a look at this, I uploaded a zipped file geodatabase here: https://arcg.is/u1P8j0 that should have all necessary data as well as a readme file.

Melinda Morang

If you're able to share your data (network dataset as well as origin and destination points), I would be happy to take a look at it. It's always possible there is a bug in the Calculate Accessibility Matrix tool, or maybe I could easily identify the problem with the network.

Melinda Morang

Well, if the Service Area results look sensible (and the screenshot results look okay to me), then the problem is not likely with your network dataset. Don't change the connectivity from End Point to Any Vertex blindly without understanding why. That change is intended for specific situations when your streets extend for several blocks and have vertices at intersections instead of being broken up into separate features.

JosephGarcia

Hi Melinda, thank you for your expedient response! An especially perplexing element to this is that I took a sampling of Census Blocks that were given a TotalDest value of 0 and ran a Service Area analysis on these points and got an output of expected results which would include thousands of destinations had it been run through Calculate Accessibility Matrix. I also tried running this sampling through Calculate Accessibility Matrix again by itself and still got TotalDest values of 0. I will try your suggestion of changing the streets feature in my network from End Point to Any Vertex and see if this works. The tool takes about 8.5 hrs to run so I will report back the results later.

The attached image shows 22 points that Calculate Accessibility Matrix gave a TotalDest value of zero, ran through Service Area which shows a large area that does not indicate zero total destinations.

ServiceArea_ran_on_22_points_with_TotalDest_value_of_zero.PNG

Melinda Morang

Hello Joseph. Yes, I agree that these results don't look correct.

My first thought is that something is wrong with your network dataset. Possibly the connectivity of the street features is incorrect. Maybe you need to switch from End Point to Any Vertex.

Have you done any testing of this transit network using an ordinary Service Area or Route, just to see if the results are sensible? OD Cost Matrix is a bit more abstract, making it hard to see what's really happening. The Calculate Accessibility Matrix tool is even more abstract.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.