topic Projection on the fly in the map vs. in the database in Coordinate Reference Systems Questions

Projection on the fly in the map vs. in the database

janel_day — Thu, 26 May 2022 14:39:18 GMT

Question to the community and @MelitaKennedy regarding "projection on the fly". Projection on the fly is magic. However, I've had many colleagues over the years apply this projection on the fly magic concept to copying features from a feature class in a projected coordinate system (PCS) and pasting them directly into a feature class in a geographic coordinate system (GCS). Both feature classes have the same underlying datum. In my mind, copying features from a feature class in a PCS and pasting them directly into a feature class in a GCS seems wrong, yet I'm having trouble proving or disproving why it's wrong. I am hoping someone can provide some insight. So now I will ask my question. Is copying features from a feature class in a PCS and pasting them directly into a feature class in a GCS wrong, even if the datum is the same between the two? Why or why not?

Re: Projection on the fly in the map vs. in the database

curtvprice — Thu, 26 May 2022 15:35:14 GMT

You didn't say ArcMap or Pro.

I haven't tried it, but if the datums are the same and it is supported (that is if it works at all) than there is no reason that would be a problem. If the datums are different I'm not sure the geotransformation would be fully supported, though it may be if the map you are editing is in in the coordinate system of the destination (paste-to) feature class.

This is the kind of thing that I would test before I started doing it in a production environment, even if the excellent @MelitaKennedy told me it was supported I'd test make sure it was working with my particular environment (software, version). (Trust, but verify!)

The way I would test it would be (you can try this with two coordinate systems in the same datum too).

1) create a point feature class in GCS NAD27 at an arbitrary location, say, -100, 40, and use the Add XY Coordinates tool so I could see the XY of the point.

2) Use the Project tool to create a new feature class in GCS NAD83. Be sure and use an appropriate transformation (say, NADCON).

3) Set the map to GCS NAD83. Go into the Map (ArcMap Data Frame) properties and make sure the same geo transformation is set up.

4) Get editing, and copy and paste the GCS NAD27 point into the GCS NAD83 feature class. Save your edits.

5) Run ADD XY Coordinates again

6) Compare the two

Good luck! Report back to the thread what you find out!

Re: Projection on the fly in the map vs. in the database

Anonymous User — Thu, 26 May 2022 17:44:23 GMT

I think this could be a problem if feature geometry is retained during the copy and paste. Lat/lon coordinates in UTM for example will result in a Null Island type problem. If your coworkers experienced that, then it would be obvious.

In my opinion, coordinate handling (especially metadata) is the most pernicious way to introduce error in GIS. It's completely silent and difficult to detect. If you don't know how data was created and transformed or converted then your data loses a lot of integrity. You won't be able to quantify uncertainty in any meaningful way. This practice definitely merits a thorough test - or could just be avoided entirely.

Curious to see your test results!

Re: Projection on the fly in the map vs. in the database

Anonymous User — Thu, 26 May 2022 17:54:34 GMT

From ESRI Projection on the Fly article:

Projection on the fly performs the same process as the Project tool, only the data does not change. It is merely displayed in the new coordinate system temporarily.

OP states that all underlying coordinates are in the same datum. I could see this being a problem if a user was working under that assumption, but the coordinates were actually in different datums. If you are copy pasting in that case, and a transformation was actually applied, how would you know which transformation was used?

I agree with the common best practice here. The same article states:

Projection on the fly is great for exploring and assessing your data. But it applies coordinate system conversions constantly. Applying them only once with the Project tool is a more stable and predictable way to manage your data. Once you’ve decided which data to use, it’s best to use the Project tool to make sure all data layers and the map use the same coordinate system.

Seems like the safest way to avoid silent coordinate errors.

Re: Projection on the fly in the map vs. in the database

curtvprice — Thu, 26 May 2022 18:00:33 GMT

Wow, I totally agree with these thoughts. Pernicious is so true - the test I suggested may not give you a full picture of how well coordinate resolution is being preserved or modified, with a coordinate resolution on the from side being different from coordinate resolution (maybe different units!) on the to side. Data formats (shapefile, geodatabase, CADfile) of the feature classes also come into play. I agree with and_viceversa and the article that best practice would most likely be to project to the new coordinate system with the from data and then copy and paste.
Great discussion, thanks for this thread!

Re: Projection on the fly in the map vs. in the database

janel_day — Thu, 26 May 2022 21:18:06 GMT

Thanks, all, for the responses. I will test, but am squeamish at the thought! The "silent" errors are the scariest and most difficult to test. My preference is to work through proper channels/best practice of using the projection tool to project the PCS data to the target coordinate system and THEN copy over the features. However, with numerous people over the years saying that copying features between feature classes with the same datum but not same projection is okay, I thought casting a wider net was prudent!