Yes I have used SurvNet, it works great once you figure out how to use it. It helps if you have a Carlson or C&G data collector. The standard projections work fine but I haven't had any luck with custom projections.
I've also used Star*Net but we don't have the pro version.
I'll keep you posted, that is my new task this week, since I've finally got the whole office convinced that standardized code lists and field to finish is the only way to go. That monkey is finally off of my back, so SurvNet is my next beast.
Donny Stallings has a couple of good webinars you can download from Carlsonsw.com.
They were very helpful in learning how to use the program.
Kris
> You write your field notes after everything is done?
Field notes is Texas speak for metes and bounds description of the tract, so yes. 🙂
Kris
Kind of like GLO Field Notes aren't really the Field Notes. The Field Notes (AKA tablets) were burned after the "Field Notes" were written up.
There is a township in Santa Clara County resurveyed by the County Surveyor in the 19th Century (as US Deputy Surveyor) where the County Surveyor's office has the actual field notes. He definitely did not do the job like the Government notes would suggest. He set up on hilltops and used radial survey with stadia distances to tie in everything. It is rolling oak woodland so you could do it that way better than actually chaining the lines.
C.
If you have any questions in regards to getting going with SurvNet feel free to email me, donnels@bellsouth.net. I hope this does not violate board policy but there are two upcoming seminars that I will be giving on SurvNet and least squares in Atlanta and Baltimore sponsored by That Cad Girl. See her website for details.
Donnie
Sorry I mispelled your name, Donnie.
It would be great if SurvNet would accept the Star*Net DAT file format.
Dave:
SurvNet does accept GPS vectors in StarNet format. I like the StarNet GPS format as its simple and ASCII. If I collect vectors with my GPS equipment I convert to StarNet format before processing in SurvNet. But SurvNet does not process StarNet total station data files directly. The StarNet total station data would first have to be converted to either RW5 (Carlson native format) or .CGR (C&G native format). What is the situation where you need or want SurvNet to process StarNet total station data directly?
Donnie
I am thinking of conventional data. The GPS data is no problem; I can get that out of Topcon Tools or GNSS Solutions in a format SurvNet likes with no problem.
I use a TDS Ranger data collector (assigned to me) for conventional data collection only. The Star*Net TDS converter seems to be the cleanest way to convert the weird TDS RAW format (not the same as RW5). I need to try Xport again to see what the problem I had was (it's been a few years since I tried it). TDS RW5 has some differences from Carlson RW5.
Obviously my Carlson Explorer makes a file that goes right into SurvNet but I try not to use it at my job because there is no rental fee to me and I am putting my equipment at risk for no return. I should use their equipment which is a TDS Ranger.
I would suggest you you try Xport again to convert the RAW format to RW5 format. We can then look at the resulting RW5 file and see what needs to be done to improve the conversion or improve how SurvNet reads the converted file. I think it will be easier to get Carlson to address the issue this way than to get permission to create a new SurvNet function to read the StarNet files directly. You also can write up the request and email the request to Dave Carlson. You can send some of your RAW files to me and I can play with the conversion and if I can see the limitations I can coordinate with Carlson to see if we can get improvements implemented.
Donnie
At least with respect to GPS, what you really collect is ECEF coordinates. This locates your position in 3D in a reference frame to the earth (requires proper location of base etc.) So beyond that what the so called grid coordinates are is some sort of projection of these coordinates onto a surface (the grid) that can be rolled out flat to produce a simple 2D system that is easy to get around in (simple math). Nothing really new here we been using various ways to look at a round type world on a flat surface for centuries.
So there is some complicated math going on to do this and in a past attempt to get around that various grid systems were invented and standardized. SPC's come to mind and were implemented over quite large areas. So to keep elevations positive they set the grid surface quite low, usually about sea level or below (you can't keep a grid surface on a constant elevation).
Now pretty much everyone has computers doing the math so the computations are really not an issue anymore other than when using them you should have an understanding of what is going on in the background. There is no need to have the grid down around sea level, you may set up a projection with a grid near the average elevation where you are working and doing so on a small area is easy do. You just need to learn and understand what is going on and how to do it.
Once you do that your grid can essentially be equal your ground. The trick to keeping it all straight is to publish your projection with your work so the next guy can do the same if they need to follow. All this should be a fundamental thing to surveyors and I believe it is being taught in the schools. Those that didn’t get it in school can learn it on their own with the required effort.
As far as converting back and forth between various projections, as long as your basic data is properly recorded in true ECEF coordinates, it's just a few key strokes on a computer. I don't scale it in CAD anymore, that's way to much trouble fraught with the potential for screwup. Make the conversion in a program designed to do that and using the basic ECEF data to work with. I use TGO but there are many such flavors to work with.
I live and work at about 6000 feet. My projects are small (no where near a 3rd of a state). Using SPC's just makes it a nightmare (grid elevation to far away, grid/ground too far apart, I like my bearings to be closer to geodetic, like the GLO). If someone insists on SPC's, it's only a few computer clicks away.
Okay...at the risk of making a fool out of myself (again), I am going to say a couple of things about GPS and Total Station similarities from a practical standpoint (or what do the two technologies actually “measure”).
First, for our purposes, GPS means Post Processed Static, Rapid Static, Kinematic, and/or RTK.
Second, Total Station means Robot, “Total Station,” theodolite + EDMI, or even transit and chain I suppose (when measuring slope distance from axis of transit to remote point, or even breaking horizontal chain for that matter).
Now I DON'T want to get into the argument about whether GPS “returns” a position or a vector (chicken or the egg), MOST folks realize that the vector scenario is the best representation of just what emerges from behind the wizard's curtain (with few exceptions).
OKAY...The first (and most dangerous) ASSUMPTION to be made, is that the field operator actually KNOWS how to properly use the equipment, but I willing to make that assumption for now.
In the case of the Total Station, this means that he/she is using a properly adjusted (and checked) instrument (and/or instruments), AND is making the proper allowances for temperature, barometric pressure, prism offset (or in the case of a chain/tape, temperature, calibration, tension & sag etc.) AND the proper UNITS are selected (US Survey Foot, International Foot, Meter) because ALL EDMI(s) measure internally in METERS.
In the case of GPS, he/she is NOT warping the GPS data around via a “calibration/localization.” This would have no effect on the raw data, but it could pollute the final results IF you don't go back to the RAW DATA.
In both cases we will assume that he/she can measure a proper/accurate HI/rod (something that I seem to have a LOT more trouble doing than I should).
NOW, the only real difference between the two techniques as far as Land Surveyors are (or should be) concerned, is that the Total Station requires TWO points from which to start from (origin w/coordinate estimates [Pt-1], and a backsight (azimuth mark) to align to [Pt-1a]), whereas GPS only needs ONE (a point with a coordinate estimate [Pt-1]). There is of course the canopy, EM field, and multipath issue with GPS, but Total Stations can have problems with local physical (and electromagnetic) conditions as well.
When all the dust settles, BOTH technologies basically “return” a direction and distance between TWO POINTS (Pt-1 and Pt-2). Now in the “raw form” this “vector” is expressed very differently by the two technologies.
In the case of the Total Station, we would be talking about an azimuth (or angle relative to the backsight) and a [slope] distance from the axis of the instrument (Pt-1), to the prism (or end of the tape) at Pt-2, along with a vertical angle (normal to the geoid). This information is then used to COMPUTE a new coordinate at Pt-2 (along with the HI and Rod height of course, because we are talking about a 3d world).
In the case of GPS, this vector is returned as dX/dY/dZ in meters (converted to feet in some cases) between the L1 phase center of Pt-1 and the L1 phase center at Pt-2, expressed in the geocentric reference frame of the ephemeris used (WGS84[G1150], IGS05, IGS08, or maybe even NAD83). This information is then used to COMPUTE a new coordinate at Pt-2 (along with the HI and Rod height of course, because we are talking about a 3d world).
What seems to plumb evade some (maybe many) folks, is that this whole “grid-v-ground” BS is the result of what happens to the raw data (both technologies) between its collection, and when the “results” get burped out on the screen. GPS does NOT “work on the [SPC] grid” UNLESS you tell it to (and even then, only AFTER the raw data is collected and manipulated). In fact, in it's rawest form, it doesn't even “work” on any particular ellipsoid!
Remember, the GPS and the Total Station BOTH “measure” a vector (direction and distance) more or less along the SURFACE of the Earth. The only real difference, is in how that vector is derived, AND the format in which it is expressed (in raw form).
I will repeat...GPS DOES NOT inherently “work on the grid” any more than the Total Station does. BOTH can be configured to do so, BUT that involves SOFTWARE in BOTH cases (various transformations and computations).
Not only that, but there is no such thing as “THE grid.” A “grid” (THE grid) can be ANY defined surface or 3 dimensional construct. The SPC Grid is NOT coincident with the UTM Grid, any more than it is with the “spherical” Latitude/Longitude “grid” (or graticule). THE Grid, is whatever YOU tell the software to project/transform the raw data ON TO or IN TO.
One more thing... “GPS Coordinate”
Wazzat?
I would argue (and it's a point that can be argued for sure), that a “GPS Coordinate” would look something like:
REF FRAME: ITRF00 (EPOCH:2011.2491)
X: -1849361.379(m) 0.010(m)
Y: -4498433.644(m) 0.020(m)
Z: 4114802.071(m) 0.029(m)
Although you CAN generate that with a Total Station too!
Loyal
I'm with Sinc 100% on this- I've seen way too many problems down the road with flipping data back & forth between grid & ground in projects.
