Point Creation - Why default to Global CS?

While the latest upgrades to RV3 are appreciated, I am confused by the decision to make Global CS the default coordinate input when creating points in a project when you have chosen an alternative coordinate system?

Why does it not defer to the project’s coordinate system? We have made the decision to survey a project in a particular coordinate system, any points we create will be in that system, don’t default to WGS84 Lat/Long, it seems like an odd oversight from the dev crew

Where is it “defaulting”? You setup the job, pick your CRS and select the Geoid if you want. We did have an instance with one of our RS2’s in Survey where the pilot was sure he entered the SPCS correctly and when he opened the job back up it said Global CS. As a result when he exported the CSV all the SPCS values were blank. There are a couple of other thread with similar discussions.


In the create point screen like I mentioned in the first post, the project is in MGA, as soon as you go to create a point it thinks it should default to global rather than the project’s CS

I haven’t created points with RV3, but are you sure that the reference to “global” is to a global reference system rather than global with respect to the project, In other words, the CRS you specified for the project is now considered “global”. Or are the point coordinates actually not written in your specified CRS?
Just spit balling it here.

I havent tested that theory but when I drop down the box it shows my project coordinate system. If the project CS was now considered global it wouldnt be in lat/long because the CS is easting/northing in metres.


I don’t know. But all the documentation shows that points are collected in the CRS specified for the project. Are you doing this looking around with the RS2 receiving satellite data?

This isn’t about collecting points, thats fine and works in the project CS, this is about creating points and Global CS is lat/long not defaulting to the project CS.

Connected to sats or not is not the issue, I am in a project that has its CS already defined as something other than WGS84


.

Got it.

Hi Cameron,

To enter the projected coordinates, you’ll indeed need to change the Coordinate system to Local first. So, your request sounds pretty fair to me. Taken a note down to discuss it with the team :relieved:

Thanks Kseniia, I do select local but having to change it every time is a bit annoying, will be fantastic if this can default to the CS of the project :slight_smile:

3 Likes

Hi Cameron,

We’re looking into it, but I just thought it could be easier to import the points as a separate file. Does it work for you? How many points do you usually add manually?

While I do normally input files before I get to site, sometimes I need an additional control point, or I get handed coords for a couple of blocks to setout and I dont have internet access in the field so I can’t import files so I need to manually import them

From an outsider with no knowledge of apps it does seem like a very simple fix to just have local grids as the default, after all, surveyors do not work in wgs84 lat long, so why not have the app setup to suit your target audience?

RV3 doesn’t require internet to use the Survey module. Regardless find yourself a USB drive that works in your mobile devices. I can pull files straight from someone’s data collector or from one of our machines totally offline.

Probably because their target audience is changing rapidly. This type of equipment has been around for a long time on the GIS side which is nearly all geographic data and what I have noticed with the introduction of the RS2 and M2, is that they are quickly getting the attention of the grid community of surveyors and construction. If you 've been using their products for any amount of time, you would see how big of an evolution they’ve had in a relatively short amount of time.

1 Like

I know it doesn’t require it for the survey module, I also generally don’t get handed a computer to plug in and access files, therefore manual entry is required.

If it’s quickly gaining the attention of surveyors and construction then tell me how wgs84 lat/long is handy? :joy:

It’s not a difficult or unusual request, project in custom grid should default to custom grid for data input, simple, its literally just changing the order in the drop down menu

Who said it was handy? We all hate it but the truth of the matter is that this is where all of our GNSS data comes from. It’s the native language of the satellites. What we are doing is transforming and deforming.

For someone who doesn’t know anything about apps and systems integration you sure got it down. It does SEEM simple doesn’t it. Oh, and it’s essentially free.

Yes, so the growing market that wants to buy the units deals in anything other than wgs84, heaven forbid we request changes like base coordinate entry in local CS too. the method is there in the sense I can see local coordinates that I’ve picked up, natural progression is base entry in local CS. You might enjoy living with wgs84 but there’s no need to hold us back, our entire cadastral boundary system is coordinated, and I’ll give you a hint, wgs84 isn’t the CS they’re using lol GIS is becoming incorporated with everything these days, these are merely suggestions for them to be at the same level as their competitors

Of course it seems easy, we had 1 programming unit in uni, dropdown list order was part of it and you literally changed the order, if it’s as difficult a process as creating the local ntrip that they introduced I will be very surprised but then again they are good to their word and create a good free product, I would have paid for local ntrip :man_shrugging:

I agree with the default part but the other option you called out about local base coordinates is much more important. I actually said the absolute opposite, that I hate WGS84. They already said they were looking at it. I feel for you if you are having to hand key so much. I can’t even think of the last time I hand entered anything. Even 20 years ago we were doing HP IR transfer and there are way too many cheap devices out there nowadays to not have the ability to import.

Hi guys,

All feature requests require serious consideration before we can start implementing them. Sometimes it helps us find a better alternative. In other cases, it allows detecting potential difficulties that are invisible at first sight. So, each request is only the tip of the iceberg. We need to dive to see the whole picture.

We understand our users most often work with projected coordinates. That’s why I find this request valid. However, like with any other suggestion, we need to think it through with devs first.

2 Likes

I’d have to disagree with that. Most GIS tasks where we have to calculate area ratios, lengths, etc. mostly requires that we work in projected systems where units aren’t angular. In fact, it’s still one of the major issues for neophytes. The equivalent of “Have you tried turning it off then on?” for GIS tools issues is “Have you checked what projection your data uses?”

Maybe where you are but I have been in two completely different GIS departments as well as support another city’s GIS department with drone data and in all 3 situations all of the transformations happened after the data was collected. I was told specifically that they wanted to maintain the native data.

Land Surveying, Architecture, Engineering and Construction on the other hand are all grid or local.

1 Like