Latest Contributions by MelindaMorang

The problem probably occurred when you tried to persist the in-memory OD layer to disk by saving the mxd.  It probably ran out of memory.  It's a limitation of ArcMap's 32-bit architecture.  I doubt if you can recover your results from a NAX file.  My recommendation for future endeavors is to export the Lines sublayer to a feature class so you will have the results on disk to work with in the future.  That will probably be easier on the system than saving the mxd with the layer inside. If solving a huge NA analysis becomes a problem, you can run it using the 64-bit background geoprocessing extension, and you can avoid running out of memory that way, but that won't help for saving mxds with gigantic layers in them. ... View more

Hi.  Can you post the exact error message you're getting?  Was that class Queue.empty thing all you got? Also, is this actually a path to a network dataset? "F:\\Workspace\\Sandy\\GM_costAnalysis\\streets" Can you add it to ArcMap and create a Route or Service Area with it there?  If not, then your script certainly won't work. As far as looping goes, that shouldn't be too difficult.  If you want to use all the same settings and stuff, you can just create a list of your input orders and depots and loop through it.  Each time you run Add Locations, take the correct ones from your list.  Make sure you set Add Locations to "CLEAR" instead of "APPEND" so that the existing orders and routes are cleared out and replaced with the new ones, rather than the new ones being added to the existing ones.  Then, make sure you're doing whatever you need to do with your solved output before the next iteration of the loop, because it will be overwritten. ... View more

In order to calculate an OD Cost Matrix (or any of the other Network Analyst analyses), you have to add your point locations to the NA layer.  For instance, you have to take your post codes and add them as Origins.  What this procedure does is it examines the original geographic location of the post codes and finds the location on the network where that location falls.  So, if a point falls a few meters off the side of the road, it assumes that the starting point of any journey originating at that point would just be the closest point on the road network to that point.  It's like the point where the driveway touches the street, even if you would have to drive 100  meters down the driveway to actually reach the front door. The Search Tolerance simply determines how far from a road a point is allowed to be before it is considered to be too far from the network to be considered in the analysis.  For instance, if you have a point that accidentally got placed way out in the middle of the ocean, a search tolerance of 5000 meters will generally ensure that that point is excluded from the calculation (and you'll see an error on that point saying it couldn't be located on the network). The reason you would want to use a very small search tolerance is if you have some compelling reason to insist that all points must be very close to the network.  If, for your analysis, you don't care, as long as they're not accidentally placed way out in the middle of the ocean, then the default search tolerance, or any reasonable search tolerance you determine, should be fine. You got the same results for each OD pair when loading them all together with a large search tolerance and when you loaded them in three tiers of search tolerance.  This is completely expected, and correct.  The travel time between two points on the network should be exactly the same if those two points snapped to the same point on the network each time you loaded them.  Since search tolerance is simply a limit after which the point will be ignored, it should always locate at the same point if it locates at all, unless you adjust the location settings in some other way. Now, if you're trying to calculate shops within 800 meters of each postcode, and your search tolerance is 5000 meters, it is conceivable that you might have a few problems.  The 800 meter limit you can set on your OD Cost Matrix is 800 meters of network distance.  The setback from the street isn't factored in.  So, if you have a post code that is set back 4000 meters from the street, and a shop that is set back 4000 meters from the street, but they snap to points on the road that are only 500 meters from one another, then they will show up as below your 800 meter threshold, even though if you consider the distance you have to walk along the driveways to get to the actual locations set back from the street, it would be 8500 meters. If you wanted to get really fancy, you could pre-calculate the distance to the network and add that in as an extra, individual amount of impedance for each Origin and Destination (you can use the Attr_ field). That said, what are your post codes, anyway?  Are they just centroids of some polygon postal code region?  If so, then the actual location of the centroid isn't very meaningful.  I mean, a postal code doesn't have a driveway, right?  So the road setback may not be worth considering to the level of exactness I just described.  It's up to you to figure out what works best for your data, but hopefully the above description will help your boss understand the nuances of search tolerance a bit better.  There's no need to do the analysis in three tiers if the only thing you would be changing is the search tolerance. ... View more

The Global Turn Delay evaluator DOES work, although I can't speak for this particular tutorial and data.  It was written for ArcGIS 9.3 after all, which was quite some time ago.  Perhaps something in the way you need to set it up has changed since then.  Here is the GTDE documentation for ArcGIS 10.2.x: ArcGIS Help (10.2, 10.2.1, and 10.2.2). Have you tried some simple test cases outside the tutorial?  For instance, zoom in on a particular intersection.  Create a Route layer, and drop two points, one on the road just before the intersection, and one on the road just after the intersection so that you would have to make a right turn to travel from the first to the second point.  Run the analysis with the GTDE and without, and see if the total travel time in the Route is the same.  If so, then something isn't working right, but if the one with the GTDE adds the delay time, then you know it's working. ... View more

Yes, it is possible to set an individual break value for each Facility in your Service Area.  The Facilities sublayer has fields named Breaks_[name of impedance attribute on your network].  So if your impedance attribute was called Distance, there would be a field called "Breaks_Distance".  If you enter in a value for a particular facility in Breaks_Distance, this will override the default break value you set in the Service Area layer properties.  Any facility that has no value in Breaks_Distance just uses the default break value. To see the above described in the ArcGIS documentation, check out this page: ArcGIS Help (10.2, 10.2.1, and 10.2.2).  Scroll down to the table showing input and output fields under "Facility Properties". Since it sounds like you have a field in your input data called Distance, you can just use field mapping when you Load Locations to map the values in your distance field to the Breaks_Distance field in the Facilities sublayer. Some information about field mapping is included on this page in the ArcGIS documentation: ArcGIS Help (10.2, 10.2.1, and 10.2.2). ... View more

Hi.  Since the OD Cost Matrix tool requires points as input, you will have to figure out some way of converting the parks into points.  Since the centroids aren't adequate in this case, you need to find a better way of representing the parks. If you know where the park entrances are (assuming there are official "entrances), you could manually create points at the entrances, and use those as your OD input. If the parks can be entered from anywhere, you might try using street intersections within a certain small buffer around the park feature.  So, take your street junctions feature class and select by location for the junctions that fall within 10 meters (or whatever distance makes sense) of your park polygons.  Export those selected junctions as a park point feature class and use that as the input. ... View more

Oh, so the route returned might be a compromise between length and safety, because the shortest route might be somewhat unsafe, but the safest route is too long.  Got it. Hmm...I'm not sure if there is a way to do that in Network Analyst.  We don't really have a way to constrain Routes in that way.  Perhaps you could take a slightly different approach and create a few more cost attributes that balance length and safety.  The user couldn't input a % longer/faster amount, but maybe they could choose from a few different options ranging from safest to shortest, and then pick the one that seems best to them. I'll pass your question on to some of my colleagues and see if anyone else wants to weigh in.  It's an interesting problem. ... View more

Hello Hamish.  So, you essentially want to constrain your route to fail (or something) if it exceeds cost + x% of the shortest route (in time or distance).  Unfortunately, I don't think there's a way you can set up a restriction attribute to do this.  Restriction attributes (and, in fact, all network attributes) have values specific to network edges.  They don't know about the Route as a whole while you're solving it.  When you click Solve, the network edges are searched to find the shortest path.  Each time a new network edge is reached, the cost attribute's evaluator returns a value indicating the cost of traversing that edge.  The restriction attribute kicks in just before that, to indicate whether traversal is prohibited across that edge or whether the result should be scaled by some factor.  Neither the restrictions nor the cost attributes have any other information about the network edges already queried or traversed, though, so you couldn't create a restriction that kicks in after your total travel time for that Route has reached a certain value. I think your best bet is to do some clever post-processing.  You'll have to check the results of your third Route (the one based on the statistics) and compare the value with the values obtained in your previous length-based and time-based solves, and then mark the ones that are outside your acceptable range. If you describe your end goal a bit more thoroughly, I'm happy to help you continue brainstorming. ... View more

Hi Tim.  If you are referring to the Add GTFS to a Network Dataset tool, I have not yet posted a 10.3 version (as of Dec 18).  I'm working on a complete overhaul and upgrade which should hopefully be done soon.  In the mean time, if you want a 10.3 version of the existing tool, e-mail me privately, and I can send it to you. ... View more

Sometimes geodatabases get corrupted and won't let you create a network dataset.  Try creating a new geodatabase with a new feature dataset in it and trying again from the beginning. ... View more

Hi.  I just learned about the new StreetLytics product from Citilabs, an Esri partner company.  They have extensive traffic flow and volume data for a bunch of large cities around the country.  It looks like Philadelphia is one of them. StreetLytics by Citilabs‌ ... View more

Oh, I see.  Is there some reason why you don't want the points to locate directly on the origins?  If you're assessing travel time between stops, then having the stop located on the stop junction features wouldn't be a bad thing. ... View more

Hi Sheldon.  I see the same behavior as you.  It's rather baffling.  We're going to look into it further on our end. However, you might be able to work around the problem on your end.  I noticed that you have a junctions source in your network called "origins".  Origins should really be part of your network analysis layer and not built into the network itself.  When I remove the origins junction source, your origin points load correctly into the OD Matrix. ... View more