Hi.
The easiest would be to post a few images on the problem. If it has happened to anyone before they would recognize the pattern immediately and possibly explain to me why this happens.
Problem in a nutshell: Person surveys a gravel road with a rover. They start on one side with a cross-section, say left to right, and then move on about 10-15m for the next section, which will be from right to left, and so on. A normal section would start with a spotshot on the boundary fence, shoulder, edge of gravel, centre line, edge of gravel, shoulder and finish with boundary fence.
Once the breaklines are connected in the office, some sections produce what I call a "wobble". This wobble-effect I've seen a lot but only very small, until I've seen these extreme examples and took greater notice of it. Now I need to try and understand it as to why it happens.
Notice the pattern in the wobble and the fact that the "arrow" it forms points in the opposite direction of the surveyor's route.
Does anybody recognize this?
Notice the GP1 shots..
Replies
Hi all,
Thank you for all the responses. A few more mentions from my side;
This gravel road survey comprised of about 20000 shots in total. Of those, about 1500 shots (2 sections) were affected by this "wobble". I decided to resurvey those 2 sections from the same base stations, same teams, same equipment, same settings, twice, to see if we could reproduce the results. You can see the results yourself on the image below;
Yellow: Wobble survey
Purple: Resurvey 1
Dark Blue: Resurvey 2
The resurvey results look perfect and the breaklines are all 100% correctly connected in all surveys. Our equipment settings are also such that you cannot record a shot if it isn't within a certain accuracy and all are Trimble.
18500 shots are 100% fine, and 1500 shots is between a slight wobble to a full-on zig-zag across the road, all the shots recorded with the accuracy setting on. Section 1 was about 1500m from its base but this doesn't explain it because it doesn't get gradually worse - at the furthest points the survey was perfect. And Section 2 had the base in its middle.
If you look at by image below with the red arrows, the 3 surveys are overlayed. The arrows point to how the person was walking, which compared to the Resurvey shots, shows that the Yellow wobble shots seems to record the actual position too early. Almost like it's trying to compensate for some kind of a lag, like Gary mentions. If this is true, it seems like it traces your steps backwards and records a shot?
And as for the precision setting and epochs, I don't work with the devices myself so my knowledge is limited as to all the settings. All I know is that all our teams do things the same way. And if it was settings, it would've affected the whole survey session at that setup that day, not just a part of it.
But this "wobble" fascinates me now because now that I've seen it at its worst, I recognize it from other surveys as well, albeit mostly much smaller wobbles which are in an accepted tollerance - I recognize the pattern. I know two teams aren't going to judge the edge of a gravel road at exactly the same spot but it doesn't explain the pattern that the wobble produces. I had a hard time explaining this to our own office but now that I've overlayed the two resurveyed sections on top of the wobble survey, especially the small wobbles, they see what I mean by the difference between a normal survey and this wobble.
Well, it looks to me like to have a classic example of a "Random Error" phenomenon, more commonly referred to in polite terms as "AAAAWWW WELL.... CRAP!!!!..."
Clearly your survey crew was just drunk the first time...pretty standard. Can you take a screen shot showing the points in an elevation viewpoint? it would be helpful to see if the elevations are bogus as well.
It's very hard to say anything about the heights other than "It roughly in the ball park"
Was this drawn in CAD or handheld? If handheld I would import points in CAD and draw up surface in it. Have you showed your surveyor? Have you questioned him/her if the project looks like what's drawn? Communication is key. Break lines don't look drawn right ether (operator error or line code commands or simply a surveyor trying to draw in handheld not knowing how). You should always show elevations too while creating a surface. This may help catch some elevation errors as well. Anyways I think your surveyor will be your answer.
First, I'd overlay the topo on some satellite imagery. Maybe that's how things are out in the field. If it looks bad, check the precision of all the topo data points. Your office software should be able to give you a report fairly easily. The default precision for rapid points (one epoch) is 0.16' Hz and 0.26' Vert. Assuming that all checks out, this could be a situation where the field crew measures using offsets and they are "offsetting" in the wrong direction. It would also help to generate some contours to see if you have a vertical bust as well.
Well, first is did you loose lock and record a point with a high RMS error.
Second, are you letting the shot settle for a few seconds at each point?
3rd, if your were doing cross sections - are you sure you didn't get your coding out of sequence? Some of those connected "EP"s or whatever are not "EP"s but "CL"s - Like Nitesh said, Did you connect the right dots?
Last, if you think these GPS shots are junk and want to test them, go GPS a couple hundred foot of wide open straight curb or sidewalk someplace, then re-shoot it with a Total Station and compare them.
I'll bet you find by paying a bit more attention with your GPS that you'll get rid of a lot of your "wobble"
Good Luck,
Kevin
I don't see the elevations of the points, or have photos of the site, or have been to the site, but this topo looks totally legitimate to me. I say that because I've shot, drafted, surfaced, etc. on hundreds of miles of borrow ditch and have seen very similar results when I'm trying to capture a drainage feature that has been eroded or accumulated over time. Sometimes ditch banks erode and lay out while sometimes they hold a sharper bank. Some of the intermediate breaklines in your dataset show me a flattish area with a separate toe of hard slope above the flow area, like where an original bank sluffed off a little and became deposition in the channel. These things happen over time to a uniformly graded installation.
Research yourself with available imagery, street view, personal visit, interview with surveyor, whatever. Contour it at way tighter than spec to look for busts.
I think this is a normal looking topo, and would not judge horizontal locations without at least looking at contours, talking to the surveyor that shot it, and photos/site visit.
I have seen a software that, in one version, if you set the stakeout settings for 5 epochs per stored shot, it would go to the confirm code screen, but still be adjusting position of the unstored point. The position of the point to store should have been locked in but it was not. We figured out the issue only because we recognized the pattern of how we staked the points, as far as where I moved the pole while storing and my #2 marked the set stake. It was storing position about 2.5' left of the direction of stakeout at each point. However, if you chose ANY other epoch #, it worked perfectly fine.
Luckily, we caught it and figured it out pretty quickly and before too many crews were affected (most defaulted at 4 epochs for general survey work...topo/rough stakeout.
The other time I see what your pics seem to show (on a phone at the moment), is Network RTK. Environment is always important in quality GPS surveys but even more so with using just a network rover. The vectors you are dealing with can be very large and the amount of obstructions between, along with environmental conditions, can really have a negative result on the final product.
Also, check if you have a choice in the GPS setting between Matched Epoch or Extrapolation. Matched Epoch is for Local RTK...the base is so close and typically the same make, the can synchronize pretty easily. Extrapolation applies a latency prediction to make up for any lag or slight timing issues between different systems. Matched Epoch will give you a slight "delay" before "accurate" results can be achieved. If you are storing single epoch shots, could bite you in some spots.
Then there is simply poor coding, which I am assuming is not the case here.
I think you have not connected the right dots, eg road left edge to road left edge, right edge to right edge etc. also look for if you recorded RTK float solutions.
-
1
-
2
of 2 Next