Latest Contributions by MelindaMorang

Great to hear! For the outputs, the FacilityID and IncidentID fields in the Routes sublayer refers to the ObjectID in the Facilities and Incidents sublayer, so you can use these reliably for joins.  See https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/closest-facility-analysis-layer.htm for a description of all fields in the Closest Facility layer. The trick is to then have some reliable way to join the Incidents sublayer back to the original input data.  If you mapped a reliably unique field like Name (or it got mapped automatically), you can probably use that to join the results back to your original input.  If not, you may need to run the analysis again, but first making sure to include a joinable field. One easy way is to map something unique to the Name field using the field mapping control in Add Locations.  Alternatively, you can run the Add Field To Analysis Layer tool to create a new field in the Incidents sublayer and then use field mapping to map your unique ID to that new field. So, in total, you need two joins: Join Routes back to the Incidents sublayer using Routes.IncidentID and Incidents.ObjectID (or use the Join Field tool to transfer only the field(s) you care about). Join the Incidents sublayer back to the original input layer using whatever field you have available for doing that join. ... View more

Pro is pretty good about taking whatever data you give it, even if the coordinate system is messed up, and displaying it somewhere so that it appears in the map, even if it's in a nonsensical or nonexistent or unknown location.  The problems arise when you try to combine that data with data that does have a valid coordinate system. The basemap is provided by Esri and uses a standard coordinate system.  It should be considered "correct". The data used by the ArcGIS Online network analysis services should also be considered "correct".  So, you need to fix whatever is wrong with your data's coordinate system so that it matches up with the expected locations on the basemap. Fixing data in that way gets outside my area of expertise, so if you're not able to figure it out, I suggest contacting Esri Support or perhaps posting somewhere else in Esri Community. ... View more

Hmm, then it could be a coordinate system issue.  If you add one of the Esri-provided basemaps, do your points line up where you expect them?  Or are they inadvertently floating in the middle of the ocean or in the center of the earth or something? ... View more

Wonderful!  We've made some progress. This documentation page explains all about what it means to "locate" inputs on the network: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/locating-analysis-inputs.htm When you say you're using "point data", can I presume your input is a feature class that displays properly in the map?  In other words, it consists of point features that have some geometry?  Or is it just a table with lat/lon values that does not display in the map?  If it's the latter, you will likely need to run the XY Table to Point tool to convert the lat/lon into points that have some geometry and can display in the map.  Then, when you run Add Locations, it will use that geometry to "locate" the points on the network.  But it doesn't know how to do that if the points just have lat/lon and no geometry. ... View more

Hello.  The answer likely depends on how you're doing this Closest Facility calculation.  I can't quite tell from your question.  Did you create a Closest Facility layer, and are you using the Add Locations tool to insert the incidents?  If this is what you're doing, then perhaps you have forgotten to uncheck the "Append" option.  So each time you add a chunk of incidents, they're being added to the incidents already in the layer, so your layer has more than 5000 incidents in it. But if your workflow is different, please describe it in more detail so we can figure out where the problem is. Also, I presume from your question that you're using ArcGIS Online as your network data source.  Could you please confirm that this is what you're doing? ... View more

You didn't specify whether you're using ArcMap or ArcGIS Pro.  ArcMap is a 32-bit application, and consequently, you are much more likely to run into memory problems.  If you're using ArcMap, please switch to ArcGIS Pro and try again.  You may not encounter the same problem. In general, the speed and memory requirements for Service Area depend on the number and size of the cutoffs as well as whether you're generating Generalized, Standard, or High Precision polygons.  High Precision polygons are more accurate but take considerably longer to generate, so you'll have to weigh your performance requirements against your need for accuracy. If you can write Python, the scripts and DevSummit presentation Dan pointed to are a great example of how to chunk and parallelize a large network analysis solve.  The example there uses OD Cost Matrix, but the same principles apply for Service Area.  However, you would have to make substantial modifications to the script to convert it to work for Service Area. Another possibility is to use the Create Mobile Map Package tool to convert your network dataset to a transportation network in a sqlite geodatabase.  Solves against this type of network dataset have some performance enhancements that may help.  However, the network dataset is not editable once it's in this format.  You can make edits to the original file geodatabase and then repackage it again. ... View more

Hi Phillip.  Sounds like you have multiple questions and problems, so let me separate them by category so we don't get all mixed up and so I don't forget anything. Validation error The validation error you see in the tool appears to me like a python path error.  I made changes to the python files in the latest update, and it looks like Pro isn't picking it up. Have you closed and reopened Pro since you updated the tool files?  If not, do that.  It will probably fix it. If that doesn't work, then my guess is the Python files associated with the tool are messed up, and you have somehow mixed the old files with the new.  Either you downloaded the updated version of the tool and not everything got copied or updated correctly, or if you pulled the GitHub version, something didn't go right.  I would delete all the files associated with the tool and start afresh.   Limiting walk time/distance Regarding the walking problem - yeah, that's a weakness of our implementation of this transit stuff.  There is no way to separately cap the walking time or distance from the overall travel time.  I know this is something we need to do, but the core structure of Network Analyst itself does not give me a way to make this happen.  Best I can suggest is you talk to your Esri representative or leave a post on the ArcGIS Ideas site advocating for this. You could also put barriers around your stops to prevent people from walking further than your desired distance, although you have to make them not cross the transit lines.   Cutoff walk time being ignored "the cutoff walk time in the origins seems to be ignored" Can you tell me more about this?  Please tell me exactly what you're seeing so I can determine if this is a bug.   Joined names "the output of the individual iterations joins the origin and destination names into one field" Are you referring to the Calculate Travel Time Statistics (OD Cost Matrix) tool here, or Calculate Accessibility Matrix? (Super helpful to me if you are very explicit about which tool you're talking about.) Are you referring to the Name field in the output OD Lines?  You can parse that if you want to, but if you want to get the Name fields from the original Origins and Destinations tables, you should just join the output Origins and output Destinations to the output OD Lines using the OriginOID and DestinationOID fields in Lines.  They correspond to the ObjectID fields in the output Origins and Destinations. This documentation page has the complete schema for the outputs.  Calculate Travel Time Statistics (OD Cost Matrix) tool output is described explicitly here. ... View more

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. ... View more

@MichaelVernon  A couple of follow-up questions for when I parallelize and update the Calculate Travel Time Statistics tool.  Are you using an OD Cost Matrix or a Route as input?  Do you have known OD pairs you want to solve for, or do you just need all origins to all destinations? For the per-time-slice outputs from Calculate Travel Time Statistics, what format would be most useful for you?  A file gdb feature class or table? A CSV file? Something else? ... View more

A couple of follow-up questions for when I parallelize and update the Calculate Travel Time Statistics tool.  Were you using an OD Cost Matrix as input?  Or did you have known OD pairs you wanted to solve for, so you were using Route? For the per-time-slice outputs from Calculate Travel Time Statistics, what format would be most useful for you?  A file gdb feature class or table? A CSV file? Something else? ... View more

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. ... View more