well core information behave test development

[jacob-a-brown]

Thoughts? Am I returning longitude/latitude and easting/northing in a correct fashion? Should I call them point_gcs and point_pcs and then include metadata for the geographic and projected coordinate systems?

[ksmuczynski]

Looks good! I really appreciate the TODO comments you left about the items that need to be added to the models/schemas/tests.

Am I returning longitude/latitude and easting/northing in a correct fashion? Should I call them point_gcs and point_pcs and then include metadata for the geographic and projected coordinate systems?

Regarding naming conventions, maybe point_wgs84 and point_utm? I think we decided that the coordinate transformations would occur in the schema.

[jacob-a-brown]

The feature file says the the response should include latitude and longitude, which leads me to think that there should be fields with those names. I can check with folks at standup today to see if that's their intent

[chasetmartin]

The feature file says the the response should include latitude and longitude, which leads me to think that there should be fields with those names. I can check with folks at standup today to see if that's their intent

I'm updating the feature file to specify the use of geojson for consistency in the app.

[jirhiker]

there should be an assertion that the x and y are actually latitude and longitude. -90, 90, -180,180.

there should also be an assertion that the horizontal datum is WGS84

[jacob-a-brown]

I saw this after merging into our shared pre-staging branch. Here are asserts I can use:

assert context.water_well_data["current_location"]["crs"] == {
        "type": "name",
        "properties": {
            "name": "EPSG:4326",
        },
    }

assert longitude >= -180 and longitude <= 180
assert latitude >= -90 and latitude <= 90

From what I've read crs has been deprecated and is no longer used. GeoJSONs must be in WGS84. Because of this, is it worth having the crs field? Or should it just be assumed and the frontend will just know and display that as the horizontal datum? @chasetmartin do you want the string WGS84 in the response somehow?

[chasetmartin]

If the proper way to define it in geojson properties is EPSG:4326 that seems fine.

[jacob-a-brown]

I can put crs in there, but according to the specs all GeoJSONs have to be in WGS84

The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.

Given that must be the case, should I still include crs? It has been used in the past, but is now deprecated.

[chasetmartin]

Ah I see what you're saying. If crs is deprecated in GeoJSON spec I don't think we should include it. But since we have horizontal_datum for UTM coords in their properties, I think we should have horizontal_datum within these properties that identifies WGS84, just to be explicit with the client.

[jacob-a-brown]

@jirhiker because all GeoJSONs use WGS84 and the coordinates are decimal degrees the feature file was updated to

# Location Information
# GeoJSON spec format RFC 7946 (Aug 2016) requires coordinates to be decimal degrees in WGS84
And the response should include location information in GeoJSON spec format RFC 7946
And the response should include a geometry object with type "Point" and coordinates array [longitude, latitude, elevation]

The note was included for documentation purposes