That’s what I’m trying to determine. It’s still not clear what the real source of the incoming data is. You have to know that before you can collect anything. I’m not even sure if UTM is even relevant to the OP.
I’m really realizing I am in way over my head on this
the data from dronedeploy is coming in the format of longitude and latitude I know I can take that directly into reach View
and it works out good for me so I think I’m going to stick with that I think trying to go to filedgenius for Android is over my head
The reason I want to use filedgenius is to stake out lines I have some lines over 1000 ft long but I can do workarounds without filedgenius
If I accuracy is within two to three feet that’s fine for what I’m doing I do appreciate all the help you guys are trying to give me I’m sorry I’m not able to understand
If your export is showing lat/lon then you need to change the CRS setting and re-export to the code you want to use in FieldGenius which is probably NAD83. If you are using lat/lon in FGA then you’re missing the purpose of using it. I kind of doubt whether anything you are doing even requires FieldGenius given that Reachview 3 now has SPCS and GEOID support.
I just want to point something out that may help people understand coordinate systems better or confuse them even more.
For the most part surveying uses a flavor of the the NAD83 system for high accuracy. They usually use a specific flavor of NAD83 depending on their geographical location or what their customer requests.
GIS systems and online maps use a default of WGS_1984 Web Mercator (Auxiliary Sphere), EPSG:3857 . This coordinate system is best used for online viewing or online map publishing. I use this heavily in ArcGIS.
GNSS receivers and most drones use plain old WGS_1984 EPSG:4326. **** This is the coordinate system that the drone uses when it writes the GPS Location into the EXIF data of the image****
So, in short the final product will dictate the coordinate system.
Personally, when collecting data for drone ground control points I use WGS1984 with an ideal reference frame of ITRF2014 or ITRF2008. For surveying I try to use the correct flavor of NAD83. If the NAD83 data needs to go online I try to find the best transformation method with the least introduced error.
As a side note. The US National Geodetic Survey is coming out with a new standard that will replace NAD83 that people in the USA should look into. New Datums - National Geodetic Survey
I hope this helps. If I confused anyone, please don’t hesitate to ask questions.
1 Like
Curious but what are you doing that causes you to use different coordinate systems for GCP’s than you would Surveying? This is one of the cruxes in drone mapping with people that have little to no geomatics experience. When you cross geodetic with grid Surveying and start adding things like scale factors, orthometric verticals and localizations it’s easy for people to get lost.
1 Like
When I am building a model for a client that has provided GCPs, I use the CRS they used for the points and convert the drone images to that CRS to process (Metashape). I am now starting to set my own GCPs when appropriate. Since my NTRIP service is using IGS08 (the IGS realization of ITRF2008), I am using that for the GCPs.
It seems there is a greater possibility to add error if I convert from geographic (broadcast corrections) to a projected system while I’m collecting points. But I too am a novice at this aspect and maybe it is not a problem with the RS2 ?
What is an " ideal reference frame of ITRF2008" for WGS84 ? I am still a bit behind understanding incorporating reference frames, unfortunately.
As I understand it, for my stated use, I select “global CS” in ReachView.
2 Likes
Most of the time our clients want to see the orthos in online maps and we use ArcGIS heavily for this. ArcGIS Online has a tendency to not play nice with NAD83. So we default to WGS1984 for that reason. However, ArcGIS does have the ability to create custom base maps in differing coordinate systems and it still can ingest and use NAD83 natively. It boils down to the level of work the customer is willing to pay for when it comes to the deliverable.
For LIDAR and the ortho mapping that accompanies it, we do collect in NAD83 since this data usually goes directly to the clients engineers.
In all the deliverable dictates how we collect data. Also, since transformations between coordinate systems can introduce error (Depending on the method), the less the better.
2 Likes
Very cool, thanks for the detail. What is going on with NAD83 in ArcGIS? Did you also mention you are having trouble transforming the map?
Hi Dave,
It seems there is a greater possibility to add error if I convert from geographic (broadcast corrections) to a projected system while I’m collecting points.
It’s just what ReachView 3 does when you work with a projected CS, right? 
Basically, applying a projection means converting the coordinates with a particular formula to show the point’s position on a flat map. So don’t worry: the projected coordinates are still centimeter-level accurate.
Hi kseniia,
Since the NTRIP base is using IGS08 (the IGS realization of ITRF2008), shouldn’t the RS2, acting as a rover, be set to the same system (Global CS)?
Or, are you saying that the RS2 can be set to a projected system and the RS2 will provide a transformation in real time when recording points?
1 Like
Yes, you can rove in real-time projected coordinates.
1 Like
Great. Thanks!
1 Like
Hi Dave,
As Michael said, ReachView 3 can project coordinates in real-time. But the projection is usually applied to the base’s datum, as there are no in-between datum transformations. That’s why ReachView 3 shows the base/NTRIP datum required for each CS. You can check it while creating a new project.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.