TERRA REF expect coordinates (geo-images, et. al.) to use EPSG 4326

[Chris-Schnaufer]

The problem with TERRA REF's expectation is that source images, shapes, and other data may not be in the expected coordinate system (EPSG 4326). This may be due to error introduced by reprojecting data.

• [ ] Investigate the level of effort involved in changing TERRA REF to use an image's/data's coordinate system
• [ ] document the changes needed for above step
• [ ] determine plan for changing TERRA REF
• [ ] document what's expected for source data's coordinate system

[Chris-Schnaufer]

• [ ] terrautils/betydb.py:
  • get_sites() assumes kwargs['containing'].split(",") coordinates are epsg:4326 [no explicit coordinate system specified]
  • get_sites_by_latlon() assumes epsg:4326 [calls above get_sites()]
• [ ] terrautils/extractors.py:
  • _get_bounding_box_with_formula(): hardcoded location information: duplicated in spatial.py [should this be removed?]
• [ ] terrautils/imagefile.py:
  • image_get_geobounds: assumes a known coordinate system (no transforms made on file coordinates) [recommend an SRID parameter?]
  • polygon_to_tuples: assumes a known coordinate system (no transforms made to polygon). Fixed: Use polygon_to_tuples_transform() if concerned about coordinate systems
• [ ] terrautils/formats.py:
  • create_geotiff: hard coded transform and epsg:4326. [use gdal to load transform and add optional SRID parameter?]
• [ ] terrautils/geostreams.py:
  • for all methods: check that an SRID is specified on GEO JSON strings
  • create_datapoint_with_dependencies(): latlon parameter should have specific coordinate system documented [WGS '84 for example], or accept an SRID
  • create_datapoints() and create_datapoint_with_dependencies(): not clear that SRID is part of lgeometry [need to look into more/ask Max]
  • get_sensors_by_circle(), get_streams_by_circle(): assumes a coordinate system [needs an SRID?]
  • get_sensors_by_polygon(), get_streams_by_polygon(): assumes coordinate systems [needs SRIDs?]
• [ ] terrautils/imagefile.py
  • image_get_geobounds() and polygon_to_tuples(): Add comments indicating coordinate system transformations are not performed [as designed]
• [ ] terrautils/lemnatec.py:
  • uses spatial.py which has coordinate system assumed and locations hardcoded [this may not be an issue]
  • it looks like lemnatec locations are in UTM [this is an FYI, not an issue]
  • assumes UA/Arizona timezone [may not be a problem]
• [ ] terrautils/spatial.py
  • calculate_gps_bounds() and geom_from_metadata(): assumes epsg:4326 - add comment about what assumed coordinate system is assumed with returned coordinate information
  • clip_las(): assumes epsg:4326 coordinates and an implicit match to .las file
  • clip_raster(): add comment about assumed coordinate system (needs to match image coordinate system)
  • find_plots_intersect_boundingbox() and geojson_to_tuples_betydb(): add comment about what coordinate system BETYdb expects
  • get_las_extents(): comment that returned coordinates are in file coordinate system
  • get_raster_extents(): Add comment that returned coordinates are in file coordinate system
  • utm_to_latlon(): Assumes Maricopa field site and has hard coded reference location. Used by scanalyzer_to_latlon()
  • scanalyzer_to_utm(): hard coded conversion information; not future proof
  • tuples_to_geojson(): add comment that no coordinate system is in returned geojson
  • tuples_to_utm(): Add comment about WGS84 assumption
  • _get_bounding_box_with_formula(): Hard coded lat-long shift. Add comment about WGS84 coordinate system assumption

[Chris-Schnaufer]

Look at documentation and tickets regarding this

[rickw-ward]

I am curious- are projections using epsg:4326 and epsg:32612 (UTM 12N) identical? Locally, I always use UTM 12N.

[Chris-Schnaufer]

@rickw-ward Sorry for the delay in my response. I am not an expert in coordinate systems so I can't answer knowledgeably on this, but I do know there must be a difference in representation since they have different epsg numbers. Also, all conversion introduce errors - how serious the errors are is dependent upon the type of coordinate systems involved (rectilinear, spherical, other) and the desired level of accuracy. Thus, it's better to always convert from the original coordinate system to the targeted system, without any intermediate conversions.

[Chris-Schnaufer]

The analysis is completed. Next step is to review with TERRA REF developers

[Chris-Schnaufer]

David and Chris to review Thursday meeting w/ IL Urbana

[max-zilla]

@robkooper fyi

[max-zilla]

Next steps: I'll take a close look at this list but overall I think these are good changes and we can start implementing on a branch whenever ready. David also recommends adding tests where possible.