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]

That was one of the reasons we use GCS...even though on our gps units (most at least) you can manually chose to stick with one or the other.

[DarrenWiens2]

I suppose DD are useful for GIS users, but not so for the person on the ground. It's pretty handy to be able to get real info from projected coordinates, in metres.

What model GPS unit do you use? By far, the most common unit I encounter are Garmin GPSmap-style units, which do not simply flip back and forth between CRS, without going into the unit's main settings.

[DanPatterson_Retired]

Out students use a variety of garmin handhelds going quite a way back, that is one of the first exercises that they do within the first few minutes of their first lab...switching between wgs84 DD and UTM NAD83 18N... the variant isn't going to matter a bit if it is NAD83 plainold or NAD83blah blah since the differences are relative and the hand helds only have a certain accuracy which is far worse than the ground based differences ascribed to variants in the nad83 datums.  When you are trying to herd multiple classes of 40 through the funnel to generate a dataset, there is only one way to go.  They can keep the data in UTM in the field...but...at download time, it is WGS84.  We also use DNRGPS because of its multiple output formats and simplicity of use.  Are they handling the downloads?  If so, might I suggest that before they do it, get them to take a photo with their cell phone of the settings they used in the field and text them back (when in range) to base, just in case there is some weirdness in a certain set of data.  This has come in handy a couple of times when NAD27 was more of an issue during the early years of field gps

[DarrenWiens2]

Just out of curiosity, here is the sequence of buttons I would need to press to change from UTM to DD on a Garmin GPSmap 62s and return back to the map:

Menu-Menu-Setup-Down-Down-Down-Position Format-Position Format-Down-Down-Down-Decimal Degrees-Quit-Quit-Quit-Quit-Quit-Quit

That's 18 button presses. Record the coordinates to the datasheet. Now I need to get back to UTM because I need to know something in metres. That's another 18 presses. At this point, I would throw the unit into the nearest stream.

[MelitaKennedy]

Is the data labeled with the different zones? Or do you have to graphically figure it out after adding it to a map?

If the former,

1. Dump all data into Excel (or other spreadsheet program).
2. Sort by UTM zone
3. Copy/paste one of the UTM zones data to another worksheet
4. Delete that data from the first worksheet.
5. Now use Add X/Y data on each worksheet.

Possible alternative--use Convert Coordinate Notation to add geographic coordinates to the "table."

If the latter, one possibility is to check what X coordinates are at the zonal boundaries in data's area. You may be able to sort the data using that information.

Melita

[DarrenWiens2]

Thanks, Melita. The tables are often provided in Excel format already, so your workflow would work, although it still has the same problem of duplicating effort (copy/paste twice, import twice), plus having to work outside ArcGIS, plus the potential for me to mess up the entire dataset using Excel sort.

Really, I'm just looking for a less cumbersome way to split a single dataset into two CRS and merge back together, but I'm beginning to see that this may just be a necessarily cumbersome task.

Thanks all for the ideas and discussion.

[RebeccaStrauch__GISP]

If like Melita ask

Is the data labeled with the different zones?

and assuming these are all starting out in one file, can you

1) import the Excel

2) get a unique list of the zones

3) do a reselect for first zone

4) export to a new temp file,

5) repeat

simplified, but if the conditions are right, I would think this would be fairly doable in a python script.

[DarrenWiens2]

Thanks for the script ideas. Here's a start to such a tool. Surprising how many steps are involved.

>>> zones = []
... inTable = "my_Excel_spreadsheet"
... outFC = r'in_memory\out_merge'
... UTM_field = "UTM_ZONE"
... with arcpy.da.SearchCursor(inTable, UTM_field) as cursor:
...    for row in cursor:
...        if row[0] and row[0] not in zones:
...            zones.append(int(row[0]))
... lyrs = []
... for zone in zones:
...    sr = arcpy.SpatialReference(26900 + zone)
...    evt_lyr = 'evt_z' + str(zone)
...    arcpy.MakeXYEventLayer_management(inTable, "Easting", "Northing", evt_lyr, sr)
...    temp_lyr = 'temp_z' + str(zone)
...    temp_fc = r'in_memory\\' + temp_lyr
...    arcpy.CopyFeatures_management(evt_lyr, temp_fc)
...    whereclause = arcpy.AddFieldDelimiters(temp_fc, UTM_field) + ' <> ' + str(zone)
...    arcpy.SelectLayerByAttribute_management(temp_lyr, "NEW_SELECTION", whereclause)
...    arcpy.DeleteFeatures_management(temp_lyr)
...    lyrs.append(temp_fc)
... arcpy.Merge_management(lyrs, outFC)

[NeilAyres]

Darren,

you might save yourself a millisecond or 2 by dropping the

and row[0] not in zones:

bit and doing

zones = list(set(zones))

[RebeccaStrauch__GISP]

(ugh...lost my last reply)

re: GPS. Is there a way to standardize on the software used to download and provide the data to you, e.g. DNR Garmin Application: Minnesota DNR

I'm not a real GPS expert (although I play one field assignments sometimes), but from what I know is that behind the scenes of all the GPSs the data is collected in (if I remember correctly) WGS84.  What the user sees and/or enters is just options for convenience.  Since that is the case (to the best of my knowledge) you should be able to output the data in a standard, say lat/long, regardless of the settings on the GPS itself.  How easy that is to implement in the field for you.... ???