This is my first time using ReachView and I’m having difficulties importing my .csv into the app. I was sent data in decimal degrees and am wondering how to get this into formatting that will work with ReachView. These should end up being somewhere around the Lakeland, FL area.
Name Lat Long
|Comp-1.1| 27.976784°|-82.102912°|
|Comp-1.2| 27.976749°|-82.102961°|
|Comp-1.3| 27.976677°|-82.102968°|
|Comp-1.4| 27.976745°|-82.102865°|
|Comp-1.5| 27.976632°|-82.102870°|
|Comp-1.6| 27.976616°|-82.102970°|
I’ve tried using an online converter to convert decimal degrees to easting/northing, but while that converted csv did import, the points were far away from their correct location. I’m not sure if this is due to my conversions being incorrect or another issue. Can someone please help me format these in such a way that they will correctly display in the app (and if you could please explain how you did it so I can replicate in the future)? My boss wants this done tomorrow and I’m just getting acquainted with ReachView, so any help would be appreciated! The units he wants used are NAD83 (NRS2007)/Florida East (ftUS) +NAVD88 height (ft US) and there is no associated elevation with these (0). Thank you!
Thank you or your reply! You can import lat/long directly in as a .csv? I thought they had to be converted to easting/northing first and believe my issue laid in converting lat/long to easting/northing. I’ll try to upload a .csv that uses their raw lat/long data formatted in such a way that Emlid will accept it. Thanks!
It won’t be the DDMMSS format but like you have it in DD.DDDD, just without the degrees symbol. It looks like Pedro’s example shows NE but I think that depends on which coordinate system you are using in your survey. If you are wanting a cartesian coordinate system the it will be NE or your file may say YX.
However, it told me that some points are not compatible with the project’s coordinate system (NAD83 (NSRS2007)/Florida East (ftUS) + NAVD88 height (ft US)). Does this mean that I need to convert my lat/longs? I wasn’t told how these points were originally taken or what coordinate system they use. It’s good to know that we can import lat/longs directly in though!
In the USA, we’re used to saying LAT LON (Y X directions) in that order. Same with Northing (Y) & Easting (X).
But you notice in Google Earth if you set it up to use UTM vs LAT LON, they swap the N & E as E & N. Same for Reachview and other international apps etc.
Make sure your getting your LAT LON or Northing & Easting in the correct order following the CSV template. You probably have them swapped backwards. And make sure to use decimal degrees. Use commas for separation.
NCAT is nice for coordinate conversions:
“NGS Coordinate Conversion and Transformation Tool (NCAT)” https://geodesy.noaa.gov/NCAT/
If your just now learning ReachView, especially with coordinate systems etc, your boss needs to cut you some slack. It’s take some time to get all this under your belt properly and so things are not incorrect. It took Emlid quite some time to finally implement it and for users to appreciate it.
Indeed, If you want to work with NAD83 (NSRS2007)/Florida East (ft US) projection, you need to convert the geographic coordinates you have to the projection coordinates.
However, you need to know your coordinates’ original coordinate system to convert them to easting/northing or upload to ReachView 3.
Also, I see that you want to work with NAVD88 height (ft US). However, in the CSV you shared, all elevations are zeroes. So, you won’t get the correct NAVD88 heights. For this, you need to have ellipsoidal heights in the CSV.
What do you guys think is the main reason people use old CRS’s and not the updated ones? We had this happen twice on one project.
The mass ex contractor setup there localization then we found out that they were using the unlabeled NAD83-TX Central 2277 and we all use NAD83(2011) 6578. They were just a little off so it was lucky we caught it. Since it didn’t match the CAD we transformed their file for them and sent it back. Then when the main GC setup their QA/QC points they used HARN. Again luckily they transformed their file. The goal of all this was to allow geodetic data to drop right into the CAD.
Mainly because they already have a substantial amount of data already referenced to the old system, possibly topographic data is the main reason. It’s too complicated to translate to a newer system if a lot of data is involved, especially redrawing a topographic survey. Too much room for mistakes and errors.
We’ve done this many times. If you start translating a lot of data, it also causes mistakes. We always make note of the horizontal/vertical datum on any of our maps. Case in point, we surveyed a large number of land parcels for the local railway (boundaries/topography) for a period of about 10 years. All their data and track locations are on SC NAD83 EPOCH 2002.0000 NAVD88 GEOID 09. Using NGS translation tools, it’s a simple matter of translating from the current datum to the past datum. In certain areas of the USA, this shift may be at least 0.5 meters or more horizontal and vertical.
There’s enough physical stations from our surveys to retrace our steps. However, not all surveyors do this.
It’s good to monument as many passive stations as possible on any project. It’s also good to have the knowledge/experience in datum transformations.
Well said, makes sense. This also explains why we get vertical benchmarks on some of these sites that don’t level to each other. Nothing puts the brakes on the beginning of a project like having to request new elevations.
