Data used to create a network from has special considerations when cleaning, as minor spatial errors can lead to major bugs in connectivity.

What techniques could be considered best practice for cleaning spatial network data before building a network model?

To set the ball rolling, here's what I can think of

  • Make sure your GIS doesn't hide topology errors (as ArcMap can), or that if it does, the network build process is designed to account for this (as Arc Network Analyst does). Understand how and why this happens.

  • Use the topology features of your GIS - e.g. Arc Topology, Autocad Drawing Cleanup. Detect all polylines that come within a tolerance of one another, or touch or intersect, without being noded (i.e. that are not broken at the intersection point). Overshoots and undershoots fall into this category. Check them for errors (depending on your representation they may represent bridges/tunnels, or they may not). Use automated repairs if they all look like errors and manual repair is infeasible.

  • Also check for link endpoints that fall within a certain tolerance without being coincident. Use automated repairs if they all look like errors and manual repair is infeasible.

  • Gradually increase the tolerance in the above two steps until you are certain that all features thus detected are intentional.

  • Build the network, compute connectivity for each junction (the number of links that join it). Check (ideally) all of them or (probably) a random sample to ensure they are what you expect.

  • Sort all the polylines in your model by length, and starting with the smallest length, check them manually (possibly with the aid of the computed connectivity data). Very short network links are usually errors, and may be messing up turn angles etc.

Anything I've missed there? Feel free to either describe or link to good offsite resources.

  • Also, not specific to network analysis, but if you check what your network analysis software think is the length of each link against what your GIS thinks is the length of the link, that can flag up spatial referencing issues. – Sideshow Bob Jul 25 '13 at 15:34

In Arc you can build a geometric network and then check at the error table to look for bugs (for this you have to first delete the topology, and also the remove the roundabout that also produce a geometric network error).

The errors flagged up are common problems regardless of which GIS you use:

  • Features that have empty geometry,
  • features that contain multiple parts,
  • features that form a closed loop or have the same from and to junction,
  • features that have zero length,
  • Junctions coincident with an edge-feature vertex having a different z-value,
  • Standalone junctions; which are junctions not connected to any edges
  • features prevented from collapsing on themselves because their length is near the snapping tolerance

From my experience. Use only Linestring type of lines, build long as possible lines, require that every line has least 1 point shared with others, do not allow 0 length lines, require lines to be OGC Valid (no self intersecting etc). If you have events on lines (linear referencing) store gps point too, because there will be someone who doesn't understand concept and they will break data.

And last but not least, Do not let people update or insert bad data to master database and with promise that they fix it later, that will never happen.

  • Good suggestions. I think self intersection is allowed in OGC valid, but not OGC Simple Features valid? Just found a nice summary here 1spatial.co.uk/wp-content/uploads/2012/10/… – Sideshow Bob Aug 27 '13 at 14:14
  • Out of interest though why should self intersection be bad? Non intersection usually implies no connectivity - plenty of network links would therefore validly self intersect (e.g. motorway junctions where the same link crosses above itself) – Sideshow Bob Aug 27 '13 at 14:15
  • It makes it harder to insert bad data. if self intersection are banned , you really have to try create rings and such. also those makes it hard to check that everything is correct . Also network topology doesn't actually care how its done, it only cares witch edge takes you to next node... – simplexio Aug 28 '13 at 8:25
  • Interesting - what is a ring and why is that bad? Also, then, is there a preferred way to represent a bridge? Break the lines and 'disconnect' them with elevation data, or just intersect two lines without breaking? – Sideshow Bob Aug 28 '13 at 11:39
  • 1
    i prefer intersecting lines when they dont share point. see line(0,0 1,1 2,2) and line (0,1 2,1) , when they dont share that 1.1 you can be pretty sure that there should not be intersection (in road, or piping network) if both lines do share 1,1 you cannot be sure if there was intention to make crossing there. Rings dont lead anywhere, they usually are useless in routing. And when i say rings are bad, i mean that they are bad in case when one geometry presents ring on road network. If two diffrent geoms create ring , thats ok. then you are sure that that was intention... – simplexio Aug 28 '13 at 16:10

As a very belated followup to this, I have recently been writing about these issues and here is what I wrote: Preparing models for use in spatial network analysis

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.