2

I'm relatively new to service area analysis. I use ArcMap 10.2

I made the following travel time contour maps by performing service area analysis.I made the first one first. It looks good. Then I add more roadways to make the second map. As you see, for unknown reason, the lower half of the contour shrinks (picture 3). I can't figure out why.

The dataset I used for the second map is built based on the dataset used to make the first map. I just added a little more local roads. So both maps basically use the same data. They calculate the travel time towards the "star".

I rebuilt the network when adding more roadways. Actually, the network I built to do service area analysis is rough. There is no turning, direction (so no loop back problem?), elevation restrictions. The only attribute I used from the dataset is travel time calculated based on links.I used network analyst to identify disconnected links and corrected them. And I tried topology check, it seems there is no self-overlap lines. Not sure what else I can check with, there are only a few options for topology check of lines.

I'm seeking for suggestions for potential reasons caused the failure of the second map. Thanks! enter image description here enter image description here

enter image description here Something wrong with the edge

  • We'd need some more information about how you added roads and edited the data. Did you rebuild the network after doing so (I'm guessing yes since there was a change)? Did you run a topology check on your edited data before building the new network? It looks to me like either new features weren't correctly attributed, or in the process of editing parts of the network became disconnected or improperly connected (ie roads loop back on themselves or other topological errors). – Chris W Sep 6 '14 at 21:35
  • I did rebuilt the network. Actually, the network I used to do service area analysis is rough. There is no turning, direction, elevation restrictions. The only attribute I used from the dataset is travel time calculated by links. – 12B01 Sep 8 '14 at 22:16
  • Travel time by links? Does that mean travel time is an attribute, or that there is a formula in the evaluator that divides length attribute by a speed limit attribute? Unfortunately with something like this it's very hard to determine a cause without having the data to examine/test. Something that was done as part of adding those new lines has broken even the original network. The only other thing that comes to mind is the network's connectivity policy, but that would be global and not just half the map. – Chris W Sep 8 '14 at 22:34
  • Thanks, Chris! Yes, I used the average speed and link length to calculate travel time for each road segment. And I used network analyst to identify disconnected links and corrected them. – 12B01 Sep 9 '14 at 14:58
  • 1
    It might be helpful to either check or post an image that has the network edge and junction layers turned on and without the service area background. In that enlarged image I see a lot of dangles/overshoots and even some disconnected lines. It's important to note that a junction can only occur where there is a vertex on both lines snapped to the same point - just because lines cross doesn't mean they intersect from a network standpoint and even one line's vertex snapped using Edge to another line won't work. I assume you've verified the travel time attributes are consistent? – Chris W Sep 9 '14 at 21:48
2

Somewhere in your source roads layer there is an attribute that indicates direction of travel. This field is usually called ONEWAY or some such variant, and if found when the network is created it's read in by default. It would appear that when you added roads, you did not populate this attribute to match the pre-existing data. The proper fix would be to go correct those attributes - likely they're just null now, or possibly an invalid value (which would override any default of allowing both directions). Because there are various ways to represent one-way restrictions, I can't really tell you exactly what to look for in terms of values. However, below will tell you how to find out.

The quick and simple way to bypass the problem is to open the properties of your Service Area analysis layer, go to the Analysis Settings tab, and uncheck the box on the right next to Oneway under Restrictions. That should run the solver and ignore any one-way restrictions at all.

Those restrictions are set up in the first place as part of the network configuration. In Catalog (window or program) you double-click the network to bring up the properties and go to the Attributes tab. There should be a Length and your Drive Time restriction, as well as a Oneway. You could simply delete or remove the Oneway restriction and that will no longer be modeled in the network (at all, not just turned off). If you double-click the restriction you get the Evaluator dialog, where it should list the values for what restricts to to-from or from-to and the type. It may say Field and then Value is an expression. Double-click that and you'll see the details of which field it's looking at and how it's evaluating that attribute (ie, what the possible values are and which case means what). You can then go find the right field and correct your new roads to have appropriate attributes.


As an aside, in your fourth image I see a lot of apparent pseudo-nodes. In your question you asked about topology checks, and while they can vary depending on what you need to look for the ones I have set up for a recent network project are:

  • must not overlap
  • must not self-overlap
  • must be single-part
  • must not self-intersect
  • must not intersect or touch interior
  • must not have dangles (Optional, will result in lots of false positives you have to check one at a time if you have true dead-end streets; otherwise used to check for overshoots/undershoots.)
  • must not have pseudo-nodes (Optional, depends on your choices to model network edges and simplifying data.)

You can find more info on each of those checks in the help files, other questions here, or this handy chart.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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