Latest Contributions by MelindaMorang

‎04-26-2016

A soft restriction is when travel on a street isn't completely prohibited but is "discouraged". Actually, you can also set it up to prefer certain streets (like truck routes), and that's also considered a soft restriction. You can read more about restrictions here: Understanding network attributes—Help | ArcGIS for Desktop Essentially, the warning you're seeing just indicates that the facility you created has snapped to a street that has one of these soft restrictions applied to it The analysis should still complete successfully. It's just warning you that some streets you might prefer to avoid have to be used because the facility is located on those street segments. You can just ignore the warning. But if you don't want the warning, you could get rid of it by doing one of these things: If you don't care about the restriction, turn it off (in your Service Area layer properties). If you don't want your facilities to locate on streets that have these restrictions, check on the "Do not locate on restricted network elements" option in the Network Locations tab of the Service Area layer properties.

‎04-15-2016

Great! I'm so glad you found a solution. The disadvantage of script evaluators is that they increase solve time because they have be calculated at solve time (as opposed to being baked into the network so the values can just be looked up). But if speed isn't your main concern, this should hopefully work fine for you.

‎04-15-2016

Hi Russ. I understand the problem, and it's a tricky one. I have a couple of ideas, none of which are ideal. Idea 1: Use Point Barriers You could make your census block centroids into point barriers to prevent travel across your virtual lines with 0 cost. However, the problem is dealing with your origin and destination centroids. If they were to locate directly on top of the point barrier at the same location, then they would not be reachable at all. If the origin or destination located on one of your virtual connector lines slightly offset from the point barrier, then it would only be able to use that single exit from the centroid to connect to the road network, so that doesn't work either. However, you might be able to make this work if you calculate routes one at a time and simply remove the point barriers at the origin and destination location for that route and leave the others. This could be automated, but if you're doing every block to every other block, the calculation might take a really long time compared to just running a single OD Cost Matrix analysis. Idea 2: Don't use centroids The cleanest solution might be to simply not use the centroids but to instead use the intersections with the surrounding streets as your origins and destinations. By giving your centroid connectors 0 cost, you're effectively doing this anyway. The disadvantage here is that you will have a bunch of origins and a bunch of destinations associated with each centroid, and you would end up with a bunch of routes instead of just one. But, if you tracked the census block IDs, with a little post-processing, you could just delete all but the fastest route between unique pairs of blocks. Idea 3: Use a Script Evaluator for default turn behavior I haven't experimented with this idea, but you might be able to come up with a solution that works using a Script Evaluator for the default turn values on your cost attribute. For the cost attribute you're using for your analysis, you can open up the Evaluators dialog from the network dataset properties. On the Default Values tab, there's a place where you can set the default behavior for all turns (transitions from one edge to another). Here, you could use a script evaluator to allow all turns except for transitions from one virtual edge to another. Learn more about script evaluators here: Types of evaluators used by a network—Help | ArcGIS for Desktop As I said, this is a tough problem. I hope this gives you a few ideas. If you come up with a good solution, please post it here so others can see!

‎03-30-2016

Hello. Unfortunately, creating a network dataset from scratch cannot be done through python. If you're using ArcGIS Pro, you can create a network dataset using the Create Network Dataset From Template tool, which can be called from python. However, you have to have a template to work from, so you have to have created a network dataset at some point previously to use as a template.

‎03-26-2016

Ah, okay. Let me first clear up one point of confusion: If you want to model multiple routes (one route between each origin and destination) in your Route layer, the correct field to map your ID to in the Stops sublayer is the RouteName field. Stops with the same RouteName value end up in the same route. The "Name" in the Stops sublayer field just the name of each stop. In the Routes sublayer, the route's Name field is just a concatenation of the stop names, unless you specified a RouteName in Stops. Yeah, a little confusing. I still don't know why your code isn't working, but you can try using the old-fashioned string method instead of using NAClassFieldMappings. fieldMappings = "RouteName PRMT_ID #;" arcpy.na.AddLocations(outNALayer, stopsLayerName, inOrigins, fieldMappings,"")

‎03-26-2016

That code looks like it should work, in theory. Is your "PRMT_ID" field a string field? I'm actually not sure how the field mapping would behave if you mapped a field to Name that was, say, an integer.

‎03-22-2016

Hello, Robert. This actually sounds like a problem you could solve with Location-Allocation. You would just need to set the all the fire stations as "required" facilities. You could further limit the results by assigning a weight to each inspection (even if it's just 1) and a capacity to each fire station (the max number of inspections it's allowed to do).

‎03-15-2016

Although empty values are allowed in the arrival_time and departure_time fields in the GTFS stop_times.txt file, these empty values pose challenges to analysis tools that rely on knowing the exact stop times for all stops. I have created a little utility that will update your stop_times.txt file with estimated values for the blank times. Currently, it just uses a simple interpolation method, evenly distributing stops in time between time points. If people are interested in a more "accurate" estimate, I might try to do something more complex that considers the locations of the stops along the road network and uses drive time to estimate the stop times. I'm happy to discuss technical details here if anyone is interested. Download the tool here: http://www.arcgis.com/home/item.html?id=040da6b55503489b90fa51eea6483932

‎03-14-2016

Dan is correct that the Curb Approach settings are the way to control which side of the road a vehicle can stop on. However, at this time, Curb Approach settings can be configured only for the orders, not for the vehicles.

‎02-19-2016

Then you won't be able to use Display GTFS Route Shapes because there are no shapes to display!

‎02-18-2016

Hello, Claudio. There is a user's guide included in the download of that tool which should provide instructions for how to use it. You can also access the latest version of the user's guide here: http://transit.melindamorang.com/UsersGuides/DisplayGTFSRouteShapes/DisplayGTFSRouteShapes_UsersGuide.html If that doesn't solve your problem, please provide more details about the trouble you are experiencing.

‎01-20-2016

Hello to those of you who are using the Add GTFS to a Network Dataset tool/code sample. Version 0.5.0.0 has been released. Download it here: http://www.arcgis.com/home/item.html?id=0fa52a75d9ba4abcad6b88bb6285fae1. Please remember to unregister the previous version of the transit evaluator before registering this one. Also, always remember to unregister it before uninstalling ArcGIS, or else you might have problems with your registry getting confused. This tool is now also available on GitHub if you want to play with the source code: https://github.com/Esri/public-transit-tools I highly recommend that everyone using this tool upgrade immediately to version 0.5.0.0, as this update corrects a problem that caused incorrect results. This problem was identified by a user of Add GTFS who ran a large number of OD Cost Matrix calculations. She found that in a small number of cases (<0.1%), the results were incorrect. I will attempt to explain the problem and the solution here for those who are interested. Suppose you use the transit evaluator to calculate the travel time between Point A and Point B. Traveler 0 starts at 10:00 AM, it takes him 1 hour to get to Point B. Traveler 1 starts at 10:01 AM from the same location, and it takes 59 minutes. Traveler 2 starts at 10:02 AM, it takes 58 minutes. This makes sense. All three travelers end up on the same bus, so they all reach Point B at the same time, even though they started at different times. Traveler 0 just had to wait one minute longer than Traveler 1 and two minutes longer than Traveler 2. The problem was that in a very small number of cases, Traveler 1 would miss the bus, and it would take, say, 2 hours to reach Point B: 10:00 – 1 hour 10:01 – 2 hours 10:02 – 58 minutes This clearly does not make sense because Traveler 1 could just wait until 10:02 and reach Point B in 59 minutes instead of starting at 10:01 and taking two hours. The reason for these anomalous results turned out to be a very deep down small rounding error, and version 0.5.0.0 corrects the problem by avoiding these rounding errors. As always, please let me know if you find any problems, and let me know what you’re working on! Thanks! Happy analysis!

‎01-06-2016

Check out Code Sample #4 in the Make Route Layer tool reference in the doc. Make Route Layer—ArcGIS Pro | ArcGIS for Desktop # Get the output Routes sublayer and save it to a feature class RoutesSubLayer = arcpy.mapping.ListLayers(outNALayer, routesLayerName)[0] arcpy.management.CopyFeatures(RoutesSubLayer, outRoutesFC)

‎12-03-2015

Hi Dan. The TargetDestinationCount property refers to the NUMBER of destinations to find for each origin, not the specific destination IDs. With OD, you can control how many destinations to find, but you can't specify which ones.

‎12-03-2015

If you want to specify pairs of origins and destinations and actually control which origin links to which destination, you can use the Route solver. When you load Stops, map the Pair_ID field to the RouteName field. This will ensure that a separate route is created for each pair.

Online Status	Offline
Date Last Visited	3 weeks ago

My Ideas

Latest Contributions by MelindaMorang

Re: Network Analyst - Routing - Location is on a soft-restricted network element - Can't fix it.

Re: Network Analyst With Centroid Connectors

Re: Network Analyst With Centroid Connectors

Re: Network dataset creation

Re: Route "Name" field

Re: Route "Name" field

Re: Find closest x number of points

Interpolating blank arrival_time and departure_time values in GTFS stop_times.txt file

Re: VRP for waste management

Re: Display GTFS directory in ArcMap

Re: Display GTFS directory in ArcMap

Add GTFS to a Network Dataset version 0.5.0.0 released

Re: Python - Saving Results from Network Analyst Processes

Re: OD cost matrix

Re: OD cost matrix

Re: How do I fill in the blank areas where streets...

Re: Route Solver - Add Locations - Convert Model B...

Re: Route Solver - Add Locations - Convert Model B...

Re: Recover Network Dataset from Mobile Map Packag...

Re: Service Area Solve with Python