Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I am trying to figure out how to preserve the original line direction of NHD High Resolution data that I am selecting out and creating a route with. I'm using ArcGIS 9.3.1 and this is a python script.

I am selecting out some of the NHD streams by the ReachCode field into a new feature class (I have also tried this with a feature layer in the context of the issue I'm posting about but creating a separate feature class allowed me to debug further), and then am taking that feature class and dissolving it. I then take that dissolved NHD section and am creating a route with the gp.CreateRoutes_lr tool.

I've narrowed down the issue to the step when the script creates the route and it seems that the direction of the line feature gets flipped when I create the route (I have definitively verified this is happening). Is this what is supposed to happen? I've never worked with the linear referencing tools before this so am unsure if this is what should be happening.

Each of the line segments have a defined FROM and TO node direction which is important for streams in terms of correct flow direction. The reason the direction matters to me for my script is that I am creating the vertices via the gp.FeatureVerticesToPoints_management tool get the elevations of the FROM and TO node to determine the stream slope for points located along the NHD section. This impacts the slope calculation obviously.

I just compared a site that had a negative slope (with assumption that a negative slope implies an instance where the route direction got flipped as I describe) with a site that had a positive slope (with assumption that a positive slope indicates an instance where the route direction did not get flipped). Both assumptions were true, and it seems for the former the direction got flipped, and the latter it did not. So it seems that this tool does not flip the directions consistently...

Is there any way to preserve the original direction of the NHD segments when I create a route? Or, what would influence the direction of the output route line feature??

thanks, Tom

share|improve this question
    
Instead of creating new Routes, have you considered using Events instead? The Hydrography Event Management Tool might help you do this. –  Kirk Kuykendall Jun 29 '11 at 16:13
    
I looked at it but haven't tried it. My code is working, I'm just trying to figure out this anomaly which will allow me to tweak accordingly and was hoping someone might have a definitive answer. My next step is to verify it's doing this for all of the streams dissolved by reachcodes (flipping the direction, that is). –  turkishgold Jun 29 '11 at 16:42

4 Answers 4

So after trying every possible scenario I could imagine, I finally stumbled on why the Create Routes tool was arbitrarily flipping the direction of the NHD stream segments. In the tools's online information, you can choose to either use the geometric length to obtain the routes, or custom fields you have created as one field or two field for the input of specifying how routes will be obtained. The default is the "Length" option and I had actually used that default for another script that was calculating a per-NHD-segment feature class, and it worked fine in that script. But, because I was using multiple NHD segments to create the route, such a scenario is when apparently you need to use the two field option.

So I added a "FromM" field for the "from measurement", and a "ToM" field for the "to measurement" to the dissolved NHD segments before creating my route. I calculated the "FromM" value to zero, and the "ToM" value to "!Shape_Length!". I then modified the CreateRoutes input accordingly, and the script worked fine.

This is exactly why "default" selections for software tools like this is really dangerous. I know I should be more diligent in researching all options for each input of a tool and for the most part I am. But even in this case had I done that, and I had poured over the online help and searched online high and low, not sure I would have been enlightened. This is not the first time ESRI default values have tripped me up. But, it's a double problem when the information on the tool really doesn't elucidate the implications of the options for a particular input when a default is specified (at least as far as I can tell with tis particular instance). Either way, note that during my testing and debugging that the tool was not consistently flipping the direction for every dissolved set of segments, only certain ones (and not sure what drives that) which made it even more tricky to figure out what the issue was. Anyhow...onward and upward

share|improve this answer

I just went through this crap, too, a very long and frustrating day with the agonizingly slow toolset.

Worse yet, my base layer of water pipe arcs was an SDE layer I have no write access to - so I had no field to use as the FROM field, though there was a LENGTH field that could serve as the TO.

I had to copy the entire layer to a personal geodatabase where I could Add Field; then I had to do an edit on the attributes, select all 34,000 water pipe arcs, type a zero into the new STARTPT field, and wait -about an HOUR for it to fill in all 34,000, presumably by the slowest loop possible.

Then I was able to create a "route type" layer from which I could create network traces of various sorts as route-event layers, without having half of them be backwards.

It just blows me away that the ESRI tools default to the "lower left" strategy when the obvious default is just to create them in the same direction the source linework was drawn. I'm not sure what ESRI calls non-route linear layers: "dumb linework" layers? Perhaps it never crossed their minds that somebody might draw in a network with a non-route type layer. Indeed, why my corporate GIS team didn't make a water network a route layer is quite mystifying, now that I know what one is...

share|improve this answer
    
A file geodatabase stored on your local drive is MUCH faster than trying to work with a personal geodatabase. I finally made the switch not too long ago. –  Rayner Sep 27 '12 at 13:52

Either way, note that during my testing and debugging that the tool was not consistently flipping the direction for every dissolved set of segments, only certain ones (and not sure what drives that)

I got caught out by this too. It appears line direction is ignored when calculating the measure values, and it is the alignment of the feature in its bounding box that defines where the M value of 0 will start.

From the tool help:

The position from which measures will be accumulated for each output route. This parameter is ignored when the measure source is TWO_FIELDS.

UPPER_LEFT — Measures will be accumulated from the point closest to the minimum bounding rectangle's upper left corner. This is the default.

LOWER_LEFT — Measures will be accumulated from the point closest to the minimum bounding rectangle's lower left corner.

Etc.

Which can be seen in the image below. The green arrows are the network flow direction and original line direction, and the blue arrows the direction in a routes layer created from the network. The green arrow in the centre of the image goes against flow as the 0 measure starts from the top right point.

flow

Which means to create routes with an M-value of 0 upstream to an M-value equal to the length of the segment downstream you need to go through the steps you followed:

  1. Make sure the network flow and digitised direction match
  2. Add in two field with the FROM_M set to 0 and a TO_M set to the segment length.
  3. Use these two fields to define the measures and never use the default measure source of LENGTH - which will produce seemingly random measure directions.

These steps seem like a huge hack, for possibly one of the most common use cases.

share|improve this answer

You could just create a Oneway field and attribute them all as FT, this will ensure they flow in the direction created.

share|improve this answer
    
Hi Justin, welcome to our site :) Please expand an on your answer, perhaps with an example. We try to avoid 1 line answers as they usually don't stand the test of time. We want to build a knowledge base that will be relevant for as long as possible. –  matt wilkie 2 days ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.