|
POST
|
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
01-15-2015
08:47 AM
|
2
|
1
|
735
|
|
POST
|
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
01-06-2015
11:59 AM
|
0
|
1
|
1684
|
|
POST
|
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
01-06-2015
09:19 AM
|
0
|
3
|
1684
|
|
POST
|
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 mmorang@esri.com
... View more
12-30-2014
05:54 PM
|
0
|
0
|
4989
|
|
POST
|
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
12-18-2014
08:12 AM
|
0
|
0
|
464
|
|
POST
|
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.
... View more
12-02-2014
04:22 PM
|
2
|
3
|
5406
|
|
POST
|
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
09-13-2014
12:39 PM
|
0
|
0
|
1353
|
|
POST
|
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
07-30-2014
03:31 PM
|
1
|
1
|
1193
|
|
POST
|
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
07-25-2014
05:39 PM
|
0
|
1
|
1063
|
|
POST
|
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
07-25-2014
05:25 PM
|
0
|
3
|
1063
|
|
POST
|
Hmm...then I'm not sure what's going on. Are you able to share your data? If so, I could take a look.
... View more
07-25-2014
04:26 PM
|
0
|
6
|
1965
|
|
POST
|
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.
... View more
07-25-2014
03:36 PM
|
0
|
8
|
1965
|
|
POST
|
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.
... View more
07-03-2014
07:25 AM
|
0
|
0
|
917
|
|
POST
|
Are you trying to use the same tutorial and tutorial data on both your 9.3 machine and your 10.1 machine? I wouldn't expect that to work. Various improvements to network datasets have been made throughout the years, so the procedures and data used for the 10.1 tutorial might not work in 9.3. The 9.3 version of the tutorial is here: http://webhelp.esri.com/ArcGISdesktop/9.3/index.cfm?TopicName=Tutorials ArcGIS 9.3 is very old software. You should upgrade if possible.
... View more
07-02-2014
10:44 AM
|
0
|
0
|
1967
|
|
POST
|
Is there some reason that barriers won't work for this application? Barriers are point, line, or polygon features that can be added to the analysis in order to simulate impassible roads due to accidents, construction, floods, etc. They do not modify the underlying network but simply affect the results of an individual analysis. The barrier features can be edited prior to the analysis. http://resources.arcgis.com/en/help/main/10.2/index.html#/Barriers/004700000056000000/
... View more
07-02-2014
07:09 AM
|
0
|
0
|
1225
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 02-03-2023 01:53 PM | |
| 1 | 11-14-2025 08:00 AM | |
| 1 | 09-03-2025 09:18 AM | |
| 1 | 08-22-2025 07:14 AM | |
| 2 | 08-07-2025 07:06 AM |
| Online Status |
Offline
|
| Date Last Visited |
3 weeks ago
|