|
POST
|
Try using this tool to clean up the OSM data prior to turning it into a network dataset. ArcGIS Editor for OpenStreetMap | Overview
... View more
05-18-2017
04:44 PM
|
1
|
1
|
2964
|
|
POST
|
I don't completely understand the problem. Are you saying that your Lines sublayer has a DestinationID value that is not an ObjectID value in the Destinations table? That shouldn't happen, unless you deleted something from Destinations and did not yet re-solve the layer. If the problem is the other way around, where you have an ObjectID value in Destinations that does not appear in Lines, it could be that that particular destination was not reachable from any Origin.
... View more
05-18-2017
12:53 PM
|
0
|
0
|
1575
|
|
POST
|
Hi Rogier. To do this sort of thing, you have to use joins. The OriginID and DestinationID fields in the output OD Lines table correspond to the ObjectID fields in Origins and Destinations, so you can join Origins/Destinations to Lines based on those fields. To link Origins and/or Destinations to your original input tables, you need to use field mapping when you run Add Locations to map, say, district_id into the Name field. Or, you can use Add Field to Analysis Layer to add a district_id field directly into Origins or Destinations, and then use field mapping to map district_id to district_id (if that makes sense...).
... View more
05-18-2017
09:57 AM
|
0
|
2
|
1575
|
|
POST
|
Hello again, Rogier. The OD Cost Matrix solver does not preserve the "traversal result", the actual network path from the origin to the destination. So, you will not be able to determine which transit stops were used. However, if you use the Closest Facility solver or Route solver, you CAN access the "traversal result" by using the Copy Traversed Source Features tool. This tool will create feature classes showing the network edges, junctions, and turns that were used in the route, and you could extract which metro stop was used from the junctions feature class.
... View more
05-18-2017
09:53 AM
|
0
|
1
|
1370
|
|
POST
|
I think he's trying to model a sort of park-and-ride scenario where you bike to the station, leave your bike parked there, and then take transit somewhere else. Since you no longer have your bike, you now have to walk the remainder of the way.
... View more
05-12-2017
09:14 AM
|
0
|
3
|
2337
|
|
POST
|
Having multiple origins and destinations shouldn't pose a problem, unless you mean that you need some of them to locate on bike edges and some on walking edges. That could prove challenging. You might have to resort to a definition query: Snapping network locations with Build Query—Help | ArcGIS Desktop Unfortunately, despite the awesome and wonderful power of the Network Analyst tools, we really don't have a good way to solve a true multimodal problem like what you're trying to do. If I understand you correctly, you want to model a trip like this: Traveler rides his bike to a BRT station and leaves it parked there, rides the BRT, gets off somewhere, and walks the rest of the way. There is an algorithmic reason for the difficulty. Basically the solver (Route or OD Cost Matrix or whatever) would need to know something about the state of the traveler (bike or no bike) and would need to keep track of this bike/no-bike state throughout the graph search that's going on under the hood when you solve an analysis. Our solvers aren't set up to do this, and if they were, we would have to use different algorithms and heuristic methods because a fast and exact solution can't be guaranteed to be found. So...hmm...maybe having a separate bike layer and walking layer IS the best solution. Then you could have those oneway restrictions that sort of prevent people from biking off the metro and BRT. Or maybe you need to break the analysis up into two parts. Solve some biking routes from the origins to the stations, and then solve the routes from the stations to all the destinations. It's not perfect, because the optimal solution might be to bike or walk directly from origin to destination without using the transit lines at all.
... View more
05-11-2017
04:36 PM
|
0
|
1
|
2337
|
|
POST
|
The problem with having overlapping lines is that a stop or facility or whatever will "snap" to the closest network edge. When they are directly on top of one another, it's sort of arbitrary which one it picks. I think maybe in the example above, it snapped to the bike line instead of the pedestrian line. The bike line has a oneway restriction, so it won't let you travel in that direction. You would have had to snap to the walk line instead in order for that route to work. You can control where your stops and facilities a little using the location settings tab on the NA layer, but that gets ugly quickly. It would be much neater to merge it all into one dataset and use restrictions. When you turn on, say, your biking restriction, and you turn on "Do not locate on restricted network elements", then the stops or facilities won't get located on network edges that don't allow bikes. To answer your question about pedestrian time, you need to create two different cost attributes, one for walking and one for biking. You would set up the evaluators for each attribute to model the correct travel time based on walk speed or bike speed. So, pedestrians and cyclists use the same lines, but the travel time is calculated differently. When you run your analysis, you just choose the correct cost attribute (and restrictions) for the mode you're trying to model.
... View more
05-11-2017
04:02 PM
|
0
|
3
|
4195
|
|
POST
|
Is either of your "false stations" restricted? Because even if the lines are unrestricted, if the junction between them in restricted, then it might not be possible to travel through the junction. Even if one junction is unrestricted, the restricted one still blocks the path. Is there a reason you've chosen to duplicate your lines for the walking and biking modes? I think it would make a much cleaner network and less confusing network if you just used a single set of line features for both walking and biking. You can add some attribution to the line features, like a field called "BikesAllowed" and one called "PedestriansAllowed" or something like that, and then you can just create restrictions that control whether or not travel is allowed on those network edges.
... View more
05-11-2017
01:47 PM
|
0
|
0
|
4195
|
|
POST
|
How are you calculating the impedance on the blue lines? It sounds like it's only letting you travel on the blue line in one direction. Or, do you still have a oneway restriction, and is it restricting travel in a particular direction along the blue line?
... View more
05-11-2017
01:12 PM
|
0
|
1
|
4195
|
|
POST
|
This network looks very complicated. Even if your connectivity policy is correct, the points of connection still need to have either a vertex or an endpoint. In your second screenshot, does the blue line have an endpoint or vertex where the pink line touches it?
... View more
05-11-2017
12:29 PM
|
0
|
3
|
4195
|
|
POST
|
Hello Rogier. I am not sure what's wrong with your Oneway restriction in this case, but a Oneway restriction doesn't seem like the best way to model a difference in travel time between entering and exiting the metro. When you set up your cost attribute's Evaluators, you have the option to calculate the travel time differently in the "From-To" direction and the "To-From" direction, which refers to the direction of digitization. So, you do NOT need two different line features. You just need one line feature, and you can determine the impedance differently depending on the direction of travel along that one line feature. See my example below. In this example, I'm setting the impedance for Streets to a constant of 1 in the From-To direction and a constant of 2 in the To-From direction. You don't have to use a constant. You could use a Field or a Function evaluator or whatever. It works the same.
... View more
05-11-2017
08:48 AM
|
0
|
1
|
4195
|
|
POST
|
Hi. It sounds like you have a reproducible crash. Sorry for your trouble! The best thing for you to do is to submit it to Esri Support, and they can work with you to resolve it or work around it, and also forward it on to the development team as appropriate: Esri Support Home
... View more
05-04-2017
11:36 AM
|
0
|
0
|
861
|
|
POST
|
There is a special Model Builder utility called Select Data, and that's what you should do to extract one of the sublayers from an NA layer. In ArcMap, you can find Select Data in the Insert menu -> Model Only Tools. In Pro, it's under Utilities on the ModelBuilder tab.
... View more
04-12-2017
07:54 AM
|
2
|
5
|
4096
|
|
POST
|
So, you have a feature class with a field called MAX_SPEED, and you're using that field in a descriptor attribute in a network dataset. Are you asking how to determine the largest MAX_SPEED value in a solved route, or something like that? So, a route from Point A to Point B travels along some streets, and you want to know the largest MAX_SPEED value of the streets used in that route? If this is the case, I think you can use the Copy Traversed Source Features tool after solving your route to get what you want. This tool will create a feature class showing the actual street segments that were traversed. You can use the SourceOID field to join your source feature class to this by ObjectID, and you can transfer the MAX_SPEED field over. You don't actually need to add MAX_SPEED as a descriptor in the network dataset.
... View more
04-04-2017
02:59 PM
|
0
|
0
|
1222
|
|
POST
|
Hello. What do you mean by "META-DATA"? What information are you trying to get?
... View more
04-04-2017
09:41 AM
|
0
|
2
|
1222
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 3 weeks ago | |
| 1 | 4 weeks ago | |
| 1 | 4 weeks ago | |
| 1 | 06-12-2026 01:53 PM | |
| 1 | 04-21-2026 08:39 AM |
| Online Status |
Offline
|
| Date Last Visited |
3 weeks ago
|