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; } } }

Résultats Incohérents du Calcul de la Matrice d'Accessibilité

JosephGarcia

Bonjour,

J'ai un problème avec l'outil Calculate Accessibility Matrix de la boîte à outils Transit Network Analysis. J'ai exécuté ce script en utilisant une sélection de Census Blocks comme origines avec un ensemble plus large de Census Blocks comme destinations. J'ai suivi le même flux de travail que celui montré ici : https://www.youtube.com/watch?v=FAmaK1fVpyY qui a été créé par ESRI. Sur les 5 875 Census Blocks utilisés comme origines, 3 784 blocs ont reçu une valeur TotalDest de 0. De plus, il y a de nombreux cas où des Census Blocks sont situés côte à côte, l'un ayant plus de 10 000 destinations et ceux qui l'entourent ayant 0. Étant donné qu'il s'agit d'une grande zone métropolitaine, les résultats sont particulièrement déroutants. Toute aide ou éclaircissement serait grandement apprécié. C'est mon premier message sur un forum ESRI, désolé si quelque chose a été fait incorrectement.

Trouver plus de publications taguées avec

Accepted answers

MelindaMorang

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!

MelindaMorang

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

MelindaMorang

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

MelindaMorang

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.

MelindaMorang

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.

MelindaMorang

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

MelindaMorang

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.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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