Latest Contributions by MelindaMorang

‎01-15-2015

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.

‎01-15-2015

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).

‎01-15-2015

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.

‎01-06-2015

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.

‎01-06-2015

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.

‎12-30-2014

I have just released a new and improved version of the Add GTFS to a Network Dataset tools. Here are the improvements I’ve made: - You can now “turn off” specific routes or trips in your analysis. For instance, you could assess the impact of cutting service on a particular line by running the analysis once with the existing service and again after turning off a route or set of trips. The included User’s Guide explains how to set this up. - There’s a new Transit Identify tool that prints out the schedule for a selected transit line feature. This is primarily to make debugging easier. - There are some behind-the-scenes improvement that make network set-up and schedule caching faster, and your network will take up slightly less hard disk space. - The download now comes with a Troubleshooting Guide document containing solutions to common problems. Download the new version here. Don’t forget to uninstall the old version if you’re going to use this one. http://www.arcgis.com/home/item.html?id=0fa52a75d9ba4abcad6b88bb6285fae1 Note that you will have to re-create your network datasets before using the new version. The improvements above required some restructuring of my data model, so your existing networks aren’t compatible. As always, please let me know if you experience any problems or have any suggestions for improvement. Also, I love to hear what you’re using these tools for and am happy to help you brainstorm. Happy New Year! Melinda Morang Product Engineer Esri - Network Analyst Team 380 New York Street Redlands, CA 92373 909-793-2853 x3315 [email protected]

‎12-18-2014

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.

‎12-02-2014

Hello, everyone. There are several downloadable tools for public transit analysis in ArcGIS. Please feel free to use these and to send feedback so we can make these tools better. Add GTFS to a Network Dataset allows you to add GTFS data to an ArcGIS network dataset so you can run schedule-aware analyses using the Network Analyst tools. BetterBusBuffers maps the frequency of transit service, showing either buffers around transit stops or user-selected input points, weighted by the number of transit trips available within a specified time window. Display GTFS Route Shapes is a simple tool to generate a feature class of your GTFS route shapes for display on a map. Edit GTFS Stop Locations allows you to edit your stop locations and/or attributes in ArcMap and generate an updated GTFS stops.txt file. Generate GTFS Shapes allows you to create a shapes.txt file for your GTFS dataset using Network Analyst and the ArcMap editing tools.

‎09-13-2014

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.

‎07-30-2014

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‌

‎07-25-2014

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.

‎07-25-2014

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.

‎07-25-2014

Hmm...then I'm not sure what's going on. Are you able to share your data? If so, I could take a look.

‎07-25-2014

Hi Sheldon. From your descriptions, it really sounds like the network edge is restricted. - When you use a small search tolerance, the point can't find a non-restricted network element to locate on, so it shows up as unlocated. - When you increase the search tolerance a lot, it finds another network edge that isn't restricted and locates on that network edge as well. Note that the point always shows up in the location of the original input no matter which network edge it's getting located on. The point doesn't move to show you that it located on a different edge. - When you uncheck Exclude restricted portions of the network, it is now able to locate on the restricted edge that it's right next to, so it still works with the small search tolerance. Try using the Network Identify tool (on the Network Analyst toolbar). Click on that network edge that's causing problems. You should be able to see the restriction values for it for any restrictions in your network. There must be something happening that you didn't expect.

‎07-03-2014

First, is there a compelling reason that the properties (houses) have to be included as feature in the network? Will these houses simply be used as origins, destinations, stops, facilities, etc. in your analyses? If so, you don't need to build them into the network. When you load them as locations into your NA layers (Service Area, Route, etc.), the layer will automatically locate the points on the closest network edge. You can adjust the location settings as needed. The actual points don't need to be part of the network. If you DO need all those properties to be junctions in the network, here's how you can do it (you need the at least the Standard (ArcEditor) license for this method): 1) Create a copy of your 300,000 houses that aren't attached to the network. 2) Use the Snap tool (http://resources.arcgis.com/en/help/main/10.2/index.html#//001v00000007000000) on the copy of the houses to snap them to the closest street feature. 3) Use the Points to Line tool (http://resources.arcgis.com/en/help/main/10.2/index.html#//00170000003s000000) to create a straight line between the original house location and the snapped house location. Make sure to match up the points by ID so you get one line between each pair. 4) Include this line feature class in your network. You can set up your impedance attribute to calculate the travel time based on the line length or whatever else you want. 5) You need to ensure that the street feature class has a vertex or endpoint at the location of the snapped house location or else the network won't connect in that location. The easiest thing to do is to run the Integrate tool (http://resources.arcgis.com/en/help/main/10.2/index.html#//00170000002s000000) to create a vertex on the streets in the location of the snapped houses. This will create vertices in those locations. Then, when setting up your network, make sure you include the snapped houses as junctions, and use Override as the connectivity policy for the snapped houses.

Online Status	Offline
Date Last Visited	2 weeks ago

My Ideas

Latest Contributions by MelindaMorang

Re: Does global turn delay evaluator really work in network analyst?

Re: Network analyst - service area: defining individual distances for each location

Re: Can you use a polygon dataset when creating a O-D Matrix?

Re: Set variable distance/time limits in Model Builder for Network Analysis

Re: Set variable distance/time limits in Model Builder for Network Analysis

Update to Add GTFS to a Network Dataset tools

Re: Compatibility with 10.3

ArcGIS public transit analysis tools

Re: Cannot create or delete Network Dataset

Re: Mapping Travel Flows

Re: Inconsistent behavior in Network Analyst when adding origins

Re: Inconsistent behavior in Network Analyst when adding origins

Re: Inconsistent behavior in Network Analyst when adding origins

Re: Inconsistent behavior in Network Analyst when adding origins

Re: Connecting House Points to City Street Network

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