the points you import with the name easting northing elevation format, does not show the movement orientation arrow, it is only a fixed line. But if I take a point with the application and stakeout, it gives me the direction arrow. I continue to insist that two distances are necessary and not an arrow and a distance.
3 Likes
Good Job!!! hope it works well , the day what Iāve been waiting arrived, finally!!! bye LL Hi coordinatesā¦ ha ha kiding
Hi all
Sorry, I think the coordinates varistions was my mistake selecting wgs72 instead wgs84.
will try it.
Greetings
3 Likes
Wow! Great congratulations! 
You did a great job (again) - from now on there will be much more fun at working with the units 
9 Likes
I tested with RS+ and RS2 and it seems to work perfectly for point survey and stakeout point in WGS 1984 UTM Zone 48N. Great job, Emlid team and cannot wait to see more features and final release for both firmware and ReachView 3 app.
9 Likes
Pls allow entering Base coordinates in UTM WGS84 coordinate system too.
One feature request which I didnāt find in ReachView2:
Enable to set the NTRIP reference coordinate system.
RV2 assumed it was always WGS84/ITRF but some local NTRIP servers here push NAD83 positions for their reference coords.
Would be great to be able to set that in the NTRIP configuration in RV3
Thanks for all the work DevTeam! This makes owning the RS2ās twice as valuable!
2 Likes
Hi @geohawk! Thanks for you question.
The idea is that instead of selecting NTRIP coordinate systems, you choose a NAD83 / UTM XX Zone system for your project. The transformation should be correct then.
One example of such system can be found here.
@agrimgalina Base mode settings in different CS is definitely on the roadmap. Thanks for the suggestion.
The stakeout issue is being investigated now, awaiting more details from you in the private messages.
1 Like
Definitely in our plans, thanks.
@egor.fedorov Thanks for replying.
Iām not 100% certain this does solve the problem, so Iāll walk it through to make sure.
- NTRIP coords = NAD83
- RV2 thinks coords = WGS84
Is RV3 programmed such that it no longer assumes reference coords are in WGS84 (like RV2)?
Thanks
Yes, this is the idea. In RTK mode Reach will provide coordinates relative to your base. That means that RV2 and RV3 will output coordinates in NAD83 in your case. Same idea works for other local datums, like ETRS89 and GDA2020.
Using a NAD83 / UTM system will correctly assume the incoming coordinates are NAD83 and apply the UTM projection without additional transformations.
3 Likes
Remember me to remember you to write something about the connection between relative/absolute coordinates fed into base and what you are getting out of the rover. And the difference between a coordinate format and coordinate system.
This section is lacking something about that 
This will also help understand PPP and why WGS84 is not always WGS84
2 Likes
The docs will definitely need to be expanded to account for coordinate systems support, which, as weāve come to understand, is a rather complex topic 
5 Likes
OK thanks.
So if the reference system csys (NTRIP) = WGS84 then do I need to do a 2-step transformation to arrive a a local projection from NAD83 in the software?
For example, this is what is typically done:
- EPSG:1188 WGS84 -> NAD83 [or similar]
- EPSG:26958 NAD83 -> Local [Florida East]
EDIT
By the way, Iām a geospatial consultant and thoroughly understand geodesy, so Iām not asking how csysā work, Iām just trying to be clear on how RV3 will work so I donāt make assumptions (like I did w/ RV2). I acquired data that I had to retranslate later (when I realized RV2 labels all coordinates WGS84 - even though they were geographic, they werenāt WGS84ā¦)
I vote for understatement of the year 
Edit: Make that all time!
5 Likes
I think you should use a WGS84 / UTM system in this case, avoiding an unnecessary transformation from WGS84 to NAD83.
Would love to do that!
and it is no problem if I do.
In this case, the project itself is in a legally defined projection (Florida East) so I have to use what Iām given, but i can easily reproject the data with external software (I use GeoSysManager from Riegl, itās free and works great)
I see. In case of Florida East systems, thereās no way around that. The easiest way would to use a NAD83 referenced correction service 
If itās impossible to do that, Iām afraid this is a more advanced use case weāll need to evaluate a little later.