4

I have recently concluded a city-wide water utitlity GPS survey.
within a geometric network, I've moved the source (pre-GPS) point features to their GPS positions.
where the old data was satisfactorily connected to the network on water lines, the vertex in the water line moved with the gps point as desired to maintain schematic connectivity.

The problem I have is that since only the coincident vertex of the water line moves, we sometimes end up with sharp angles where the water lines tee together at network junctions (ideally they should be at 90 deg) since those endpoints are not affected by the move. See screen shot below.

enter image description here

Part of the current work flow is to clean these up manually to make it look like the next screen shot.

enter image description here

This is a large and dense city, so rather than panning around every street to visually identify these targets for editing, is there a tool that can be used to identify intersecting angles so I can go right to trouble spots like these rather than looking over the whole project area?

  • I've been there before. Do you have your GPS points as a layer? What worked for me previously is looking for vertices in your utility layer that are not (reasonably) matching a GPS point now. Use feature vertices to points then select from these vertex points within a distance of GPS points, switch selection, buffer by a bit (maybe 5 metres) with dissolve and then explode multi part to achieve a 'check zone' for manual discernment. That way I only needed to check ~2500 intersections rather than ~150000. – Michael Stimson Nov 13 '17 at 21:40
  • @MichaelStimson I think you should copy/paste your comment into an answer. – PolyGeo Nov 20 '17 at 21:57
  • I can do that @PolyGeo but I was waiting for the OP to indicate that they have the GPS points as a feature class, if not then that method is of no use. So I will assume that the GPS survey is available as a point feature class, as was the case for me. – Michael Stimson Nov 20 '17 at 22:00
  • @MichaelStimson I'd just start the answer with "Assuming that the GPS survey is available as a point feature class, ..." The asker has not responded to your request for clarification in 8 days already so dropping an answer gets this of our unanswered lists (once it has an upvote) and should let us use our volunteered efforts to answer other questions rather than checking in on this one. – PolyGeo Nov 20 '17 at 22:10
  • Perhaps I'm just not understanding, but we may be talking about different problems. I'm satisfied with the snapping of my point features (GPS data). Moving my original points full of attributes to their gps'd location worked great and my system still traces perfectly. My concern is mostly asthetic but still rather important in the industry. I do not have gps data for the tee junctions of thewater mains. I do have them as a points layer though. Those are the points I'm having to move by hand to visually square up the watermain intersections. – Zipper1365 Nov 21 '17 at 3:25
2

I was unable to find a tool to do this for me, but with Michael Stimpson's buffering suggestion, I came to the following process in ArcGIS that was actually pretty quick:

  1. Buffer the Geometric Network Junction points by a really small amount (I used 0.05')
  2. clip my water mains to the buffer.
  3. Convert the buffer polys to lines
  4. Merge the buffer lines with the clipped mains.
  5. Convert the merged lines to polygons.
  6. Add a field in which to calulate the arc_length: perimiter - 2*(buff_dist)
  7. Add a field in which to calulate the angle: ( [arc_length]*360)/(2*3.14*.75)

There are some rounding and cluster tolerance issues (I think a larger buffer would help minimize this), but for my purposes this gets me close enough to identify gross issues.

enter image description here

1

I will assume that you have the GPS utility points as a feature class and access to an advanced ArcGIS license.

When faced with a similar challenge the data was in SDE so I was loathe to add new fields, I extracted the pipelines as a feature class in a geodatabase so that I could junk the intermediate.

What worked for me previously is looking for vertices in your utility layer that are not (reasonably) matching a GPS point now. I used feature vertices to points (advanced license required) then selected, using Select by Location, from these vertex points within a distance of GPS points (10mm tolerance was fine for me), switch selection so that only those that were more than the tolerance were selected, buffer by a bit (maybe 5 metres, it depends on your data) with dissolve and then explode multi part to achieve a 'check zone' for manual discernment. That way I only needed to check ~2500 intersections rather than ~150000

If you don't have an advanced license the are tools available like this to generate points from polygons or polylines, as this is the only step that requires an advanced license.

Another useful post is a Visit tool to zoom to each buffer polygon in turn, as this is bound to take a little while to complete, this is like the tool that I used to iterate the buffers to ensure none were missed and I didn't forget where I was up to.

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.