Structuring A Traverse?
Azimuth shots to something visible from a good number of traverse points will indeed be useful for tightening.
But what point do you shoot on a cell tower? Do they all have a light or other distinct feature? You cannot average the azimuths of the three antennae to get a useful number, since the answer is not the center of the tower, and depends on where you are in relation to their orientation.
You're so clueless!
> You're so clueless!
Well, if you'd like to show an example that disproves what I've pointed out, feel free. You could, say, post a link to a metes and bounds description that is an example of one of your one-off custom projections in practice that does not in fact have the obvious downsides I mentioned.
Structuring A Traverse?
Pole towers easy, pole on high tension easy, multi leg towers not so easy. One of the leg tops is the better choice. My default for a reference has always been N/NE.
In my recent work having azimuth shots it was less for traverse control and more for a quick backsight had I needed to return to get an extra location shot. I shoot D&R. If I am close to a big pole, without a good shot to the top, I pick a horizontal joint, put the top of the scope ring at either end of the joint to center it.
I have one pole that has been observed from 3 different large surveys. When I get around to GPSing the first I will pick up a couple of azimuths from a 4th and see how the SPCs agree.
Paul in PA
> Doing some browsing on the subject here in the archives. Can anyone think of a particularly educational string of posts about it or perhaps on the old RPLS.com? I've been in a rut with the non-survey work I was doing at the oil company and I need to dust off the cobwebs.
andy, i found two somewhat related subjects:
[msg]20180[/msg]
[msg]45032[/msg]
Anybody with modern software and the education to understand projections, which should include all land surveyors, can handle this stuff with ease. It's practically so easy a cave man could do it. Hell, an SPC is a projection that uses the same parameters, metadata, etc. Anybody that truly understands SPC's should be able to use an LDP.
You never give up preaching your religion do you? This whole conversation is more than ten years old. LDP's, which didn't even have that name back then, have been universally adopted. What you're advocating is something similar to saying airplanes are not useful and should have never been invented. I mean, why would anyone fly from California to New York when they could walk.
> Anybody with modern software and the education to understand projections, which should include all land surveyors, can handle this stuff with ease.
Clearly, you don't understand the real problems that creating a jillion custom projections needlessly creates. If custom projections are really a much better idea than using standard projections, it only makes sense that every tract will have its own and that a surveyor who also examines twenty adjoining tracts in the course of resurveying that one will eventually have to deal with twenty different custom projections. What could possibly go wrong aside from all the obvious things?
What each tract or survey has in common, regardless of the way you wish to look at it, are ECEF 3D coordinates. That's the common glue that binds it all together. The biggest draw back to SPC's is the elevation or third dimension is missing. The greatest mapping tool available at this point is GIS. To make it fully functional it needs 3D coordinates, the base ones in a world ECEF system. Once those are in there you can breeze through any projection you wish.
One real big cluster to input into a real projection system is plane SPC's where you don't have an accurate third dimension. Even worse is a system where you have the Grid for direction, ground distances, a few SPC's here and there and then the combined scale factor. Yeah you can back it in approximately, but it takes a lot of work and the opportunity for errors is huge.
Yeah I'm sure you can do it. I can do it also, but it's a real pain and inefficient and even then the end result is not the real ECEF coordinate of the points on the earth. There is a better way, it's invented, tested and included in all modern software worth using. All one needs to do is use it. It's the same software used to work in SPC's, updated to handle all three dimensions. You probably already own a software plenty capable.
The bottom line and result of this over ten year long debate is baked in the cake. You lost!
Earth Centered Earth Fixed Simply Does Not Exist
Even NAD83 floating with the North American Tectonic Plate no longer exists.
As to elevations in GIS, there is no Datum, just garbage in, garbage out.
You survey a parcel in 2008 and again in 2013, what can you say about the GIS on those two dates.
Paul in PA
> I bet even StarNet supports the voodoo art of custom projections. Or did they provide you with a special version that grays out those features?
When Oregon introduced its set of Low Distortion Projections I used the custom projection feature of StarNet to add them. The latest Microsurvey version of the program has them preloaded.
[sarcasm]Say it ain't so. Not starnet![/sarcasm] lol
> I am evaluating software and trying to make some decisions about our data collecting and processing policies here at the company.
If you are using Lieca equipment LGO can be used to for simultaneous adjustments, but is limited to only Lieca format data. Any editing of the raw field data post data collector is difficult to impossible. But fully moduled LGO also does static vector resolution, so it makes a nice package.
I have experimented with SurvNet and say that any experience you gain using it will transfer to StarNEt rather easily.
My favorite is still StarNet.
One thing to consider is the size and complexity of your networks. StarNet can handle pretty big networks, but if you have hundreds of points and thousands of measurements the LGO might be the way to go. I'm not sure about how SurvNet performs as network sizes increase. I know that TGO would choke on a quite small network and perhaps that is why it was rarely used by anyone.
I haven't had an opportunity with TBC, but one of the other fellows in our office who has expressed frustration.
What's your beef?
Grid coordinates are reduced to the plane of the grid therefore they can be directly translated to coordinates on the ellipsoid.
Earth Centered Earth Fixed Simply Does Not Exist
So what does your GPS use to calculate vectors? When it calculates the length of a vector what's the math?
The LGO LSA software is an OEM and somewhat watered down module from MOVE3, which looks to be a geodeticly robust adjustment software as is Columbus. StarNet and maybe others may not be as robust over networks over large areas.
That said, StarNet "may" be easier to use for novice users, although I suppose everything is easy once you understand it.
For the price, I would be inclined to seriously evaluate the Columbus software for a 3rd party LSA software. MOVE3 is considerably more expensive than most if not all other competitors.
I am still using the LGO version of MOVE3, but have looked at a few of the others over the years.
"Road Trip"" And Buy Kent Some Beer
The thing that worries my the most when people combine conventional and GNSS data is scaling. If you do not scale your local site down to surface (1:1) you are scaling you conventional data to your GNSS or GPS data and creating a bastardized data set. Hence the "keep it around 500ft" recommendation. It is close to 1 but is it 1? After all, isn't property supposed to be measured on a 1:1 scale?
I think the best way to do this is to set a local control with OPUS and then use RTK to measure AT LEAST 3 points that you occupied during a traverse. Any less will scale (stretch) your data. I wouldn't get too carried away with it. Five points are ideal so that you can leave one unconstrained for a check - no pencil whipping. After you collect all of your data you can adjust 1 of your OPUS points to surface based on the CSF. The LSA software should then scale all of your RTK data to 1.000000000 (you will probably have to tell it to). Doing this minimizes scaling and local ellipsoidal errors.
I know TGO & TBC will do this but TBC has a better LSA adjustment. I am not proficient with Star*Net and MOVE3 at this point but they are on my to-learn list...
My 2¢ :-/
This thread and associated links contains a lot of valuable information - and some misleading information as well. Being gone all weekend, I did not get a chance to read/follow thread as I would have otherwise - we were visiting grandkids in Tucson.
Several issues for consideration:
1. The global spatail data model (GSDM) accommodates both GPS and terrestrial data - in fact, all spatial data. The concepts are not that difficult but, for the impatient, they have been described as tedious - See the Global COGO web link. Given the opportunitity I'll suggest otherwise.
2. One observation is that we attempt to purchase software that does what we want it to. No problem with that if we want to do is what should be done.
3. What about software that does the right thing efficiently? Maybe it exists and maybe it doesn't. Why not write your own? Well, that is time-consuming and might not be realistic. The GSDM documents the algorithms and all the equations are public domain. It might surprising to learn how many routinely use 3-D ECEF.
4. There is lots of software that does many things - remember, the vendors conduct market studies and ultimately bring to market what the customer will buy. If we collectively ask for and demonstrate a willingness to buy software based upon ECEF, we could do a lot more work more efficiently. I guess the question becomes which comes first, the cart or the horse?
Any suggestions? Yes, I have a few I'd be happy to share.
> One thing to consider is the size and complexity of your networks. StarNet can handle pretty big networks, but if you have hundreds of points and thousands of measurements the LGO might be the way to go.
I have one project with almost 700 stations and over 2200 observations. Star*Net v6 runs the 20-iteration adjustment in a little under 2 seconds.