Latest Contributions by MelindaMorang

Yes.  The tool simply calculates ordinary Service Areas repeatedly over a time window, so all the usual settings, rules, and assumptions for Service Area apply. ... View more

You might be able to simplify the query a little.  Just calculate a field to a value of 1 (for example) if the street falls within any AA, and then constrain the locating to only locate on streets with that value.  It won't guarantee that the point locates within the correct AA, but hopefully in most cases some usable street within the AA is closer than the nearest street in a different AA. ... View more

Hello Harry. I think the first thing you should consider is whether using a centroid in your analysis is really the best way to go.  If you have large, irregular polygons like the one shown in the screenshot, the centroid (or the network location it snaps to) may not be a good representation of reality.  You could instead, for instance, choose the midpoint of a main road in the area or the location of the most populated building. To answer your question, you may have some success using a search query when loading inputs.  You could first run a Calculate Field on your streets to label each one with the aa it falls in (or None, if it doesn't fall in one).  When you run Add Locations (or however you're loading inputs), you can set up a search query so that each input only snaps to roads with the designated aa value.  Note that the search query applies to all points loaded in a given run of the tool, so you might have to run it separately for each aa so you can tailor the query to each one.  You might be able to preprocess that snapping in a more efficient way (not sure off the top of my head) and then just run Add Locations once. This documentation might be helpful. ... View more

Hi Joseph. First off, WOW!  This appears to be a HUGE problem.  Frankly, I'm amazed that Pro and your machine managed to survive for 630 hours 27 minutes 29 seconds (over 26 days!) of processing.  I can honestly say I've never witnessed any tool run that long, let alone one of mine. This, of course, helps you not at all since the tool died before finishing.  The traceback unfortunately doesn't tell me much.  Basically the OD Cost Matrix calculation must have crashed or died for some reason (reason not apparent from the log), and the parallel process caught the crash and stopped the tool.  Given the size of the problem and the lengthy run time, I would guess some kind of resource limit (your computer ran out of space, ran out of CPU or memory, got tired, etc.) or some kind of process interruption (your computer tried to update, it lost a connection to an output folder if it was on a network, your virus scan did something, etc.).  Unfortunately, I really just don't know what happened. I was actually just talking with someone yesterday about having some kind of retry logic for processes that fail like this, but that's not something currently implemented in the tool's logic.  Right now the entire tool will stop and fail as soon as one of the processes errors out.  Possibly I can consider enhancing this at some point. Regardless, I also note that the OD Cost Matrix calculation was only a quarter of the way through.  That means that even if the process had not failed, you would be looking at running this tool for 3-4 months before you get a solution, and that really just doesn't seem tractable.  Also, it has to do some post-processing in the end once the OD Cost Matrix calculations are done, and if the problem is truly this gigantic, you may run out of memory at that point as well. I think you will have to break this problem down into smaller parts or it just isn't going to be tractable.  Here are some ideas, data points, and suggestions to help you consider how to approach it: The size of the network dataset doesn't really matter.  You can include all your transit agencies in one network and use it for each subset of inputs without substantially impacting the performance. You're right that you probably need to include all or most of the destinations since your job market is regional. Your best bet is to break up the origins by county or geographic area so you have manageable chunks that solve in a reasonable amount of time. Precalculate the network locations in advance to save some time. I noticed from your log that you're using only 5 parallel processes.  If you have the ability to use more, this will definitely help a lot.  Do you have access to a more powerful machine with more logical cores? Do you have access to more than one machine?  If you could distribute the problem onto a couple of machines that can each run a chunk of origins, this would help you get a result in a reasonable amount of time. Consider spinning up some cloud machines.  This problem honestly might just be intractably large for solving on one machine, and if you don't have the resources in house, maybe it would be worth the cost to rent some temporary processing capacity from the cloud. What version of ArcGIS Pro are you using?  We made some substantial performance improvements to the OD Cost Matrix in the 2.9 release, so if you're using older software, updating will definitely help a lot.  ODs may be 20-70% faster, depending on the analysis settings.  If my math is right, it seems like each 1000x1000 OD chunk is taking about 14 seconds to run, which honestly seems rather slow to me. How many origins and destinations do you actually have? ... View more

Hi Katharina.  To get any transit-specific information, you have to download a special tool from ArcGIS.com or GitHub that extends to core functionality of Copy Traversed Source Features to add the transit information, which is not included in the output of the core tool in ArcGIS Pro.  (This download includes several tools; the new one is called Copy Traversed Source Features With Transit.)  You can find more information about this downloadable tool in the user's guide.  The RunDepTime and RunArrTime fields have the departure and arrival times for the LineVariantElement. ... View more

Hmm. Okay, here's how I set up a test problem. I have a layer with two stores, and they have a unique ID field called STORE_ID: I have a layer with customers that has a non-unique field called STORE_ID that assigns each customer to a store. Then I set up and run the tool: It runs successfully and calculates a route between each customer and their assigned store.  (The example is made somewhat confusing by the fact that the ID fields have the same name, but they don't have to.) So, the ID field in origins need not be unique, but the ID field in destinations does. If you're still having trouble...I'm not too sure how to help you.  Might be best if you contact Esri Support, and they can look at your specific data and figure out what you're missing. ... View more

The destination IDs need to be unique.  The field in Origins relating to the Destination ID field need not be unique because multiple origins can be assigned to the same destination. The example under the "Using multiple origins and destinations" section in the tool documentation may be helpful in illustrating how it should work. ... View more

I looked at the network you shared with me privately, and here's what I found: On my machine, building the network as is takes 4 hours and 22 minutes. (You must have a faster machine!)  This is an "incremental rebuild" where it senses that it has dirty areas (places where it's been edited) and builds only the dirty areas.  Hypothetically, this should make the build quicker if there are only a few small areas in the network that have been changed. If I instead force the network dataset to do a full rebuild (so it ignores dirty areas and builds the whole thing whether or not it's dirty), it actually takes less time.  For me it took about 2 hours and 5 minutes. Unfortunately, I've seen this type of behavior before.  Sometimes it just takes forever to sift through a large number of small dirty areas and handle them individually, even longer than it takes to rebuild the network from scratch.  I will log a bug for our developers to investigate your particular use case to see if there's a way we can improve performance; however, this isn't something we can fix in the short term.  You should probably consider some kind of workaround. One workaround is to make your automated process force a full rebuild.  This will still take a considerable time, but it does seem to be faster than your incremental rebuild speed. Here's two ways to force a full rebuild: Method 1: Open the network properties and add a new restriction attribute. Click OK to close the property page Reopen the network properties and delete the restriction attribute. Click OK to close the property page.  The network now thinks an attribute has been modified and that it requires a full rebuild. Method 2: Run the Create Template From Network Dataset tool to create an xml template with your network dataset's schema. Delete the network dataset. Run the Create Network Dataset From Template tool to recreate your network using the xml template file you just created.  The network is now completely fresh and requires a full rebuild.   If I've understood your original question correctly, though, it sounds like you're working in a production environment where edits are being made daily, and you want this build to run quickly.  I'm curious what edits are being made daily to your network.  When I looked at the network's dirty areas, I see a LOT of them.  Tons of little overlapping dirty areas all over the place.  It looked to me as if the entire network was effectively dirty, but probably all the small changes accumulated over time in a way that left a ton of these little overlapping dirty areas.   What kind of edits (automated or manual?) are being done to cause all these changes?  Perhaps you can consider streamlining this part of the process to avoid this large accumulation of edits. Another thing you could consider: It looks like your network includes a bunch of small areas spread around the country that are not connected. If you are hosting a network analysis service, there's a way you can configure it to use separate network datasets and broker between them depending on the location of the user's analysis inputs.  So, if my inputs are in New York City, use the New York City network, but if they're in Los Angeles, use the Los Angeles network.  This way, edits could be kept contained to only a single network, and smaller networks build faster.  This is more complicated to set up than I can describe to you here on Esri Community, and if you want to go down this route, you should talk to Esri Support (or whoever your usual contact is - I believe I recognize the name of your company as a partner/start-up). Hope this helps! ... View more

Okay, thanks for the info.  You can upload your data to whatever file sharing site works for you and send me a private message with the link through the Esri Community private message function. ... View more

You could also try installing ArcGIS Pro 3.0 (the latest release available as of today) and seeing if the crash has been fixed. ... View more

Hello.  From your screenshots, it appears that Pro has crashed.  The best thing for you to do is to add your e-mail and a description of your workflow in the crash dialog (the one shown in EditIssue3.jpg) and click "Send Report".  These reports are sent to a sorting system here at Esri, and it will be sent to the best team to address the problem.  If you include your e-mail, the team may be able to reach out to you to help you find a workaround. You can also call Esri Support for more immediate help. ... View more

Hello.  Could you please provide more specific information about the errors you're getting?  Your workflow is not quite clear to me from this description.  Please also tell us what version of ArcGIS Pro you're using. (You might also consider calling Esri Support.  This sounds like the type of trouble that may be best addressed by having someone walk through the process with you.) ... View more