XY Table/Multiple UTM Zones to Single Feature Class

[DarrenWiens2]

This is a problem I come across regularly and feel there's room to save a step or two.

1.) Field data comes back from GPS or field notes in a table containing UTM Zone, Easting, and Northing fields. There may be multiple UTM Zones (e.g. Zone A and B).

2.) Display XY data, using Zone A as CRS.

3.) Export all data to a single feature class, using the chosen UTM Zone (A).

4.) Set Data Frame CRS to Zone B.

5.) Select and export records in Zone B to new feature class, using Data Frame CRS.

6.) Start editing and delete records in Zone B from the feature class in Zone A.

7.) Merge Zone A and Zone B feature classes into a single feature class with common CRS.

As you can see, this is somewhat convoluted. How do you handle tabular data in multiple CRSes?

[DanPatterson_Retired]

Our rule? Data in the field are always recorded in decimal degrees, geographic coordinates with a WGS84 datum regardless where in the world they are working (particularly north of 60).  The conversion to other projected coordinate systems is done in-house to suit the geographic area and extent.  As for UTM, you can devise your own TM projection by changing the central meridian if that makes for better coverage.  Otherwise a more friendly east-west projection is used (such as lambert...).

[DarrenWiens2]

We are somewhat stuck using UTM in the field. It's the industry standard (really, the only option ever used), for better or worse. It's easy for field workers to estimate distances using the coordinates, and vice versa. As a GPS can only use a single CRS at a time, they are set to UTM.

[RebeccaStrauch__GISP]

Not that this will resolve your issue or make a better workflow, but I don't export in UTM zones from GPS....either decimal degree or another projection that doesn't require a different CRS.  But if the data is coming in as you mentioned, that isn't a bad workflow.  However, you may be able to write a tool to make the process a bit faster.

edit...looks like Dan beat me to it.

[DarrenWiens2]

As I replied to Dan, I'm somewhat stuck in a machine bigger than myself with this. UTMs are the only option. I can't expect field workers to remember that just because the data might make its way to me at some point, they need to record a different type of coordinates.

More just looking for a few less clicks between multi-CRS table and single feature class. Unfortunately, as these tables come to me in so many different formats, I don't think I could ever write a script that covers all cases.

[ChadKopplin]

In the past we have looked at where the majority of points are and where the least error is located.  So, if the majority of the points are along a UTM boundary, and the majority are in the left zone, we would set the points to the left UTM zone for this data (lower error on the right side of the UTM zone versus the left).  This would be for specific areas, but for state wide data we would generally choose one of the systems previously mentioned.

[DanPatterson_Retired]

And if memory serves... or Melita Kennedy​ could confirm, you have a couple of degrees of longitude...to play with on either side before things go "south" to use an expression.  An on our gps units, we can flip between wgs84 and utm with a button press.  We find students are quite clever when it comes to remembering that prior to download, I am sure your field workers are as well.

[DarrenWiens2]

That would be device-specific. The units/CRS are set fairly deep within the GPS main settings.

[DanPatterson_Retired]

Then I would look to see if there is an "auto-switch" toggle to prevent border switching.  And there must be a quick switch to toggle between geographic and projected coordinates (at least on the garmin (many), leica  (?) and trimble (?) units we have)

[DarrenWiens2]

This isn't to do with error. As you cross a UTM zone boundary, the GPS chooses which zone it's in and reports/records those coordinates. The resulting table or data sheets then contain those coordinates.