Create custom spatial reference systems for PostGIS

[max-zilla]

@yanliu-chn talked today about creating 3 custom SRS's for this project that I didn't capture very well in my notes:

• Arizona MAC coordinate system
• USDA coordinate system
• (0,0) inversion

Could you say a tiny bit about these? I wanted to create an issue to capture that. For my own understanding, I found this: http://geeohspatial.blogspot.com/2013/03/custom-srss-in-postgis-and-qgis.html http://daniel-azuma.com/articles/georails/part-9

...where ultimately we might simply need to define our custom SRID in PostGIS with something like:

INSERT into spatial_ref_sys (srid, auth_name, auth_srid, proj4text, srtext) values ( 96703, 'sr-org', 6703, '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs', 'PROJCS["USA_Contiguous_Albers_Equal_Area_Conic_USGS_version",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Albers"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-96.0],PARAMETER["Standard_Parallel_1",29.5],PARAMETER["Standard_Parallel_2",45.5],PARAMETER["Latitude_Of_Origin",23.0],UNIT["Meter",1.0]]');

(note that the authority name and ID are not required if the system is not specified by an outside authority like EPSG)

@robkooper We could then define columns in Clowder PostGIS for each of the custom SRIDs - a setup script could check for some custom definitions file in Clowder, insert those into PostGIS if found, and change how the datapoints/etc. tables are defined accordingly. The geog column (which is currently the only one) could still be SRID 4326 and that can always be present, but then we could also have geog_96703 or other SRIDs for project-specific SRS's.

So for Terra we might end up with geog, geog_999001, geog_999002, geog_999003 where the 99900x are our 3 SRIDs. Then we require data to be submitted in one of the 4 reference systems. If a new sensor emerges with a new one, we add a column for it.

This is mostly thinking out loud... maybe I'm way off.

[dlebauer]

I think the 3 reference coordinate reference systems should be

• Arizona MAC coordinate system
• Raw gantry with x positive west
• inversion of gantry coordinate with 0,0 in SW corner

The USDA points can be treated as truth because unlike the UA MAC System it was accurately calibrated.

RTK GPS data corresponding to these are on Clowder along with a long email thread uploaded as PDF (hint, start from the end!)

[JeffWhiteAZ]

I agree with the list of three as reference systems for public consumption. However, may want to conserve the MAC coordinate system as well because as long as MAC is using their field equipment for planting and tractor scans, we will receive data with the biased MAC coordinates. Alternately, we need to clarify with Pedro about coordinate adjustments for any data from MAC.

• Jeff

[dlebauer]

@jeffwhiteaz the UA MAC system is first on the list for that reason

[JeffWhiteAZ]

I'm sorry. I misread the previous messages. My understanding:

• "USDA" is based on a correctly located base station and hence is the most accurate and useful for long-term use. What we are really saying is that we're using standard geocoordinates (UTM referenced to a specific datum?). USDA ALARC's base station + rover is simply the best available source of RTK-corrected data so that is what was used to establish locations of the scanner coordinates.
• Arizona MAC coordinate system is valuable for interfacing with data from MAC field equipment
• Raw gantry with x positive west is standard output from Lemnatec, so is needed
• Inversion of gantry coordinate with 0,0 in SW corner is much easier for people to interpret if they are not familiar with UTM Is that correct?

[dlebauer]

Inversion of gantry coordinate with 0,0 in SW corner is standard for people and computers. UTM magnitudes are too large, reversed x axes cause errors but don't fail, and the gantry + its data are not square with UTM. Some of this discussion goes in #32 ; lets keep this issue is about implementation.

(max fixed issue #, it pointed to unrelated #29 on accident)

[yanliu-chn]

usdagps_TerraRef_Lemnatec_Field_AZ_UTM.txt

This is the specialized UTM projection definition developed by @tingli3 for the Lemnatec field based on USGS RTK GPS data.

Need to verify the accuracy by comparing with ground truth points.

[dlebauer]

@yanliu-chn and @tingli3

Could you please elaborate on how this was developed, and how it can be used?

Also, I have summarized the GPS and Lemnatec coordinates in this spreadsheet: https://docs.google.com/spreadsheets/d/1pTgmpf9kltYW1SHo_K51cynVTYs6-JdS6rt4usfwV10/edit#gid=0

Is this the data that you used? Otherwise, can these be used as ground truth points?

[yanliu-chn]

@dlebauer Thanks a lot for the new google sheet! This is what we wanted. The original excel file was hard to understand the diff b/w USDA and MAC gps.

The projection file I uploaded is in WKT format and is recognized by most of GIS software for reprojection. It was developed by tuning the central meridian line of AZ's UTM projection so that the line denoted by S-W and S-E matches the X axis in the projection.

[dlebauer]

This issue was moved to terraref/computing-pipeline#179