Latest Contributions by MattCrowder

Thank you for your idea. I agree that there is currently no guarantee that you will get the exact same results if you upgrade to a later version of ArcGIS unless to stay on the exact same version of the software and data. Both software changes and data changes can slightly change the results. If your requirement is for the results to remain consistent, I would suggest you deploy your solution on a long-term release of Enterprise, so you do not need to update the software. We are constantly improving our algorithms to fix bugs, improve our heuristics, and improve performance. For simple improvements we make them apply to all users by default. When we make significant algorithmic changes, we attempt to do so in a way that existing users have to opt-in to the new behavior so existing workflows can remain the same without changes. It would be unusual for there to be a dramatic change in the default behavior between releases. It would only be introduced if it was an important fix that we wanted to be fixed for all users by default. I can't think of the last time this occurred. Can you provide an example of where upgrading to a more recent version of the software was problematic for you in the past? This may help us understand how we can improve the process. We do not have any plans on our roadmap to version or release the Network Analyst solvers outside the normal ArcGIS Enterprise system. But we will keep this in mind if their are significant changes that may make this possible or a compelling reason to do so. ... View more

Thank you for your feedback. To be clear - If you're using Pro with a local network dataset or you stand up your own routing service on Enterprise, there is no hard limit to the number of stops per route.   In ArcGIS Online, the limit is 150 stops per route. And if Pro is consuming the online routing service, the limit is also 150. The 200 limit you're referring to is most likely the Vehicle Routing Problem asynchronous service (used by the Plan Routes analysis tool) that has a limit of 200 orders per route.   This is a different, more complex solver than the simple route solver.  And it consumes more credits.  That being said, it's a good point that it appears to be inconsistent. The limit of 150 stops per route was based on what we felt was a reasonable size for the use cases our route solver was designed to solve. I can see potentially bumping it up to 200 to be consistent with the Vehicle Routing Problem service, but we would need a compelling reason to make it higher than that.   Can you provide more details on the problem you’re trying to solve? Are you optimizing the order of the stops? What is the spatial extent of the problem you’re trying to solve? What would the travel time typically be for such a route? Would you be using the synchronous or asynchronous service? What is your expectation for the response time? ... View more

I know this doesn't answer your specific question, but rather than creating a model that performs this workflow, have you tried using the GP Tool "Generate Origin Destination Cost Matrix" that does all these operations within a single tool?  This is what we typically recommend using when possible. If for some reason you need to to use the model as currently defined, can you please share model so we can try to reproduce the problem on our server? Thanks, Matt Crowder ... View more

Given the input size being over 1000 features, you're going to have to chunk up the problem.  There are various different ways to do this.   Here's one workflow that should be easy to automate and doesn't consume many credits: Create a near table by running the GP Tool "Generate Near Table" so you can find the 10 closest facilities to each incident: Input Features = your incidents feature class Near Features = your facilities feature class Location = checked Find only closest matches = checked Maximum number of closest matches = 10 Method = Geodesic Create an XY Event Layer on this output table using the NEAR_X and NEAR_Y for the x,y named "ClosestFaciliites" For each feature in your incidents feature class Select incident feature Select features in ClosestFacilites where IN_FID = incident feature's ObjectID Call Ready-To-Use Services > Logistics > World > OriginDestinationCostMatrix > GenerateOriginDestinationCostMatrix with these parameters Origins = the incident layer that has the 1 incident selected Destinations = the ClosestFacilities layer with the 10 closest features for that incident selected Number of Destinations to Find = 1 Origin destination Line Shape = "Straight Line"   (optional, but nice to see) The Output Origin Destination Lines layer that is returned should have 1 row that has the Total Time and Total Distance and the Destination OID that you can use to get the facility that was closest to that origin. Write this information to wherever you're storing the results Iterate to the next incident feature This workflow could be automated using python (so you don't have to do this process 900 times).  However, I'm not a python programmer so can't really help with the automating step of it. Notes on the above steps: I specified finding the nearest 10 features.  You can reduce/increase this number if you want, but the larger the number, the more credits will be consumed. I chose to use the OD  Cost Matrix Solver instead of the Closest Facility Solver because you just need the time/distance and not the shape or driving directions, so the OD Solver should be faster.  Plus, it will use fewer credits. The credit consumption of running this on the full 900 incidents x 11,000 facilities will be 4.5 credits.  This was figured out because you will be doing 900 origins * ((1 origin * 10 destinations)  * (1 credit / 2000 OD pairs)) = 4.5 credits. If you were to use the closest facility solver (which is 0.5 credit per route returned), it would be 450 credits.  This is because 900 Incidents x (1 incident x 10 destinations, returning closest 1) * .5 credits = 900 x 1 x 0.5 = 450. Hope this helps, Matt ... View more

dtrolling  - A couple questions:  Are you trying to find the closest 1 facility (of 11,000) for each of the 900 incidents or are you trying to find the time/distance/directions to all 11,000 facilities for each 900 incidents? If just finding the closest 1 facility from each incident, would it be OK to somehow chunk the problem so you iterate through the problem for each incident, just passing in the 100 closest facilities to chose the best 1 from. What is the extent/density of this problem?  For example, are the 11,000 facilities/900 incidents spread throughout a single town, metropolitan area, state, county, or country? Do you need the route shape and/or directions or do you just need the time/distance to reach the facility? Do you have any programming experience and if so, in what language? Matt ... View more

This definitely looks weird.  It doesn't look like the service areas are lining up with the street data either.  What version of ArcGIS are you using?  Where is your network coming from?  Are you sure you're solving on the same network that you're displaying in the map?  What happens if you generate service area lines? ... View more

Most likely, you don't have an evaluator established for your impedance attribute.  As a result, the cost to travel across every edge is 0 so any route (no matter how many edges it travels on) is the same.  At minimum, you should set up a length cost attribute based on shape. ... View more

Run the Add locations tool 2 times.  One time to load in your origins and another time to load in your destinations. ... View more

I don't know what you're doing differently.  When I pass in the following, it works correctly for me (the 2 orders get added to the route): orders: { "displayFieldName": "POIs", "geometryType": "esriGeometryPoint", "spatialReference": {   "wkid": 3857,   "latestWkid": 3857 }, "features":[ { "attributes":{ "Name":"POI1", "TimeWindowStart1": 1368784800000, "TimeWindowEnd1": 1368828000000, "ServiceTime":10 }, "geometry":{"x":738459,"y":6403815} }, { "attributes":{ "Name":"POI2", "TimeWindowStart1": 1368784800000, "TimeWindowEnd1": 1368828000000, "ServiceTime":10 }, "geometry":{"x":738747,"y":6403143} } ] } depots: { "displayFieldName": "Start- and Endpoint", "geometryType": "esriGeometryPoint", "spatialReference": {   "wkid": 3857,   "latestWkid": 3857 }, "features": [ { "attributes":{ "Name":"myStartPoint" }, "geometry":{"x":739213,"y":6403433} },   { "attributes":{ "Name":"myEndPoint" }, "geometry":{"x":739213,"y":6403433} } ] } routes: { "displayFieldName": "Route", "features": [ { "attributes":{ "Name":"myRoute", "StartDepotName":"myStartPoint", "EndDepotName":"myEndPoint", "EarliestStartTime": 1368784800000, "LatestStartTime": 1368784800000, "MaxOrderCount": 30 } } ], "exceededTransferLimit": false } default date: 1368784800000 ----- output: info from routes: "features": [{    "attributes": {     "ObjectID": 1,     "Name": "myRoute",     "ViolatedConstraints": null,     "OrderCount": 2,     "TotalCost": 28.204576460644603,     "RegularTimeCost": 28.204576460644603,     "OvertimeCost": 0,     "DistanceCost": 0,     "TotalTime": 28.204576460644603,     "TotalOrderServiceTime": 20,     "TotalBreakServiceTime": 0,     "TotalTravelTime": 8.204576460644603,     "TotalDistance": 2.1846002201207435,     "StartTime": 1368784800000,     "EndTime": 1368786492275,     "TotalWaitTime": 0,     "TotalViolationTime": 0,     "RenewalCount": 0,     "TotalRenewalServiceTime": 0,     "Shape_Length": 0.03965315719801789    }, from out_stops:   "features": [    {"attributes": {     "ObjectID": 1,     "Name": "POI1",     "PickupQuantities": "",     "DeliveryQuantities": "",     "StopType": 0,     "RouteName": "myRoute",     "Sequence": 3,     "FromPrevTravelTime": 1.9393302872776985,     "FromPrevDistance": 0.4956385305662407,     "ArriveCurbApproach": 0,     "DepartCurbApproach": 0,     "ArriveTime": 1368785587343,     "DepartTime": 1368786187343,     "WaitTime": 0,     "ViolationTime": 0,     "ArriveTimeUTC": 1368778387343,     "DepartTimeUTC": 1368778987343    }},    {"attributes": {     "ObjectID": 2,     "Name": "POI2",     "PickupQuantities": "",     "DeliveryQuantities": "",     "StopType": 0,     "RouteName": "myRoute",     "Sequence": 2,     "FromPrevTravelTime": 1.1830458752810955,     "FromPrevDistance": 0.35046338018190065,     "ArriveCurbApproach": 0,     "DepartCurbApproach": 0,     "ArriveTime": 1368784870983,     "DepartTime": 1368785470983,     "WaitTime": 0,     "ViolationTime": 0,     "ArriveTimeUTC": 1368777670983,     "DepartTimeUTC": 1368778270983    }},    {"attributes": {     "ObjectID": 3,     "Name": "myStartPoint",     "PickupQuantities": "0.000000",     "DeliveryQuantities": "0.000000",     "StopType": 1,     "RouteName": "myRoute",     "Sequence": 1,     "FromPrevTravelTime": 0,     "FromPrevDistance": 0,     "ArriveCurbApproach": 0,     "DepartCurbApproach": 0,     "ArriveTime": 1368784800000,     "DepartTime": 1368784800000,     "WaitTime": 0,     "ViolationTime": 0,     "ArriveTimeUTC": 1368777600000,     "DepartTimeUTC": 1368777600000    }},    {"attributes": {     "ObjectID": 4,     "Name": "myEndPoint",     "PickupQuantities": "0.000000",     "DeliveryQuantities": "0.000000",     "StopType": 1,     "RouteName": "myRoute",     "Sequence": 4,     "FromPrevTravelTime": 5.082200298085809,     "FromPrevDistance": 1.338498309372602,     "ArriveCurbApproach": 0,     "DepartCurbApproach": 0,     "ArriveTime": 1368786492275,     "DepartTime": 1368786492275,     "WaitTime": 0,     "ViolationTime": 0,     "ArriveTimeUTC": 1368779292275,     "DepartTimeUTC": 1368779292275    }}   ],   "exceededTransferLimit": false } } ... View more

for your orders and route, you are passing in the times as strings, rather than the number of milliseconds since epoch (January 1, 1970) in UTC.   The string based representation of dates has been deprecated at 10 and is no longer supported. I'm pretty sure when converting from REST, these values are not being converted into proper dates and are treated as 0 (which would equal 12 AM). I have verified that if you pass in the correct numeric values corresponding to 10 AM UTC (passing in 1368784800000) and 10 PM UTC (passing in 1368828000000) and passing in the default_date = 1368784800000, then things work correctly. Can you confirm? matt ... View more

Can you please include all the parameters that you're passing in to the REST request so I can reproduce locally and understand what's going on? Thanks, Matt ... View more

That date/time doesn�??t look right.  For example, 1367820000 is Fri, 16 Jan 1970 19:57:00 UTC.  Why aren�??t you passing in the real date instead of one from 1970? If you wanted to set the start time window for 10 AM, you should pass in 10 AM UTC.  We will them interpret that as 10 AM local time. So for Fri May 17 10:00:00 UTC 2013, that would be TimeWindowStart1 of 1368784800000. You�??d also need to specify the defaultDate.  For this, you can just pass in the same as EarliestStartTime from   the route. Here�??s what I passed into my service that worked: default_date: 1368784800000 orders: { "displayFieldName": "POIs", "geometryType": "esriGeometryPoint", "spatialReference": { "wkid": 3857, "latestWkid": 3857 }, "features":[ { "attributes":{ "Name":"POI1", "TimeWindowStart1": 1368784800000, "TimeWindowEnd1": 1368784800000, "MaxViolationTime1":0, "ServiceTime":10 }, "geometry":{"x":739116,"y":6404262.603} }, { "attributes":{ "Name":"POI2", "TimeWindowStart1": 1368784800000, "TimeWindowEnd1": 1368813600000, "MaxViolationTime1":0, "ServiceTime":10 }, "geometry":{"x":739216,"y":6404262.603} } ] } depots: { "displayFieldName": "Start- and Endpoint", "geometryType": "esriGeometryPoint", "spatialReference": { "wkid": 3857, "latestWkid": 3857 }, "features": [ { "attributes":{ "Name":"myStartPoint" }, "geometry":{"x":739612,"y":6404755} }, { "attributes":{ "Name":"myEndPoint" }, "geometry":{"x":739612,"y":6404755} } ] } routes: { "displayFieldName": "Route", "features": [ { "attributes":{ "Name":"myRoute", "StartDepotName":"myStartPoint", "EndDepotName":"myEndPoint", "EarliestStartTime": 1368777600000, "LatestStartTime": 1368784800000, "MaxOrderCount": 30 } } ], "exceededTransferLimit": false } By the way, change your GP service parameters to have Message Level = "Info".  That way, you can sometimes get good info as to what the problem may be. For example, if I didn�??t set the DefaultDate, it didn�??t work.  Looking at the messages, I saw these that indicated a potential problem: �?� esriJobMessageTypeInformative: Running script SolveVehicleRoutingProblem... �?� esriJobMessageTypeWarning: Depots, Routes, Orders and Breaks contain time windows with dates but the DefaultDate value does not have a date. �?� esriJobMessageTypeWarning: WARNING 030088: Solve returned an error, but errors were converted to warnings. �?� esriJobMessageTypeWarning: WARNING 030092: VRP Solver failed due to invalid input. I then went here: http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#/Vehicle_Routing_Problem_Service/02r3000000n4000000/  and read the doc on what to pass for Default Date. Anyway, hope this helps. matt ... View more

Thanks for the sample input that doesn't work.  We currently do not have consistent coverage for geocoding by city, zip for the entire world.  As a result, in this case we are just geocoding to Singapore.  We are currently investigating what we can do to add support for city, zip into the next update of the geocoding service. Thank you for your feedback. Sincerely, Matt Crowder ... View more