Select to view content in your preferred language

Wrong projected CRS when importing GCPs

248
2
Jump to solution
08-11-2025 11:02 AM
JoshBerna
Frequent Contributor

Hi all,

Quick question regarding my current drone2map workflow. The NTRIP base station I use for RTK corrections for both my M3E and Trimble GPS reports in NAD 1983 (2011). Therefore, I collect my GCPs in NAD 1983 (2011) and my images CRS is thus NAD 1983 (2011) as well, since I'm using the same base for RTK. 

The issue arises when I import my GCPs (or check points, in this case) to drone2map. When I keep them in the same CRS they were collected in, drone2map defaults the project reference system to WGS 1984 UTM Zone 12N HRS with NAD 1983 (2011) VRS. I then cannot fix the systems in drone2map because the controls are in the project, barring me from changing the project reference system (or transformation for matter, of which none exists because WGS 1984 HRS and NAD 1983 VRS is incompatible of course). Thus I have to go into Pro and project the check points to WGS 1984, an extra step.

I recognize the products need be in a projected CRS, but why not then default to NAD 1983 UTM Zone 12N? It shouldn't default to a WGS reference system when all my project data is in NAD. If it defaulted to NAD 1983 UTM Zone 12N, no transformation would even be needed, and I wouldn't have to reproject my check points. 

This would save me the time spent reprojecting my check points for every ortho, of which I produce an absurd amount for my local uni.

My question then: is there a way to change the default projected reference system assumed by drone2map when importing GCPs that are in a geographic reference system? Reprojecting is arguably easy and fast, but its an extra, unnecessary step that only serves to prolong my workflow. It would make sense for the software to assume a default NAD projected system when all the project data is imported in NAD.

Thank you for any input or advice offered.

0 Kudos
1 Solution

Accepted Solutions
ManuelMora
Esri Contributor

Hello Josh,

Thank you for taking the time to share your workflow and the challenge you’re facing. We understand how important it is to minimize extra steps outside the software, and we recognize that the current behavior in Drone2Map when handling NAD 1983 (2011) data is a known limitation, as any geographic coordinate system will always be configured as WGS 1984 UTM. 

While there isn’t currently a way to change this default behavior within Drone2Map, our team is actively reviewing this workflow to explore improvements allowing users to select different coordinate systems for the GCPs and the project, to better align with user expectations and reduce extra processing steps.

Thank you!
Manuel

View solution in original post

0 Kudos
2 Replies
ManuelMora
Esri Contributor

Hello Josh,

Thank you for taking the time to share your workflow and the challenge you’re facing. We understand how important it is to minimize extra steps outside the software, and we recognize that the current behavior in Drone2Map when handling NAD 1983 (2011) data is a known limitation, as any geographic coordinate system will always be configured as WGS 1984 UTM. 

While there isn’t currently a way to change this default behavior within Drone2Map, our team is actively reviewing this workflow to explore improvements allowing users to select different coordinate systems for the GCPs and the project, to better align with user expectations and reduce extra processing steps.

Thank you!
Manuel

0 Kudos
JoshBerna
Frequent Contributor

Hey Manuel,

Thanks for the reply! It seems like the Drone2Map team is always on top of things and its quickly becoming my favorite Esri software. 

I also recognize that most NTRIP stations and thus GCPs/Check Points are going to be in WGS 1984 and it just makes sense to default to the WGS 1984 UTM projected system. Great to hear you're working on implementing better handling of the NAD data though! I look forward to it.

Thanks again.