Geometry coordinate system used in Clowder datapoints

[zhzyx]

Description

I noticed the coordinate systems used in sensors and datapoints are different.
In sensors, they are something like: (-111.974925070941, 33.0752463177059, 0). I think it should be lat/lngs. But in datapoints, they are something like: (33.0752456246289, -68.0249705271937). I'm pretty confused with coordinate system that were used in datapoints metadata.

Thanks

[dlebauer]

A thank you for pointing this out. The ordering may be a bug in our code (?) - postgis stores in lon,lat order. Just a suspicion but this may be confounded by the use of different data types (geometry vs geography) in the underlying postgis database.

Could you provide the specific use case along with calls you are using and responses that you get? Depending on the intended use you may want the polygons rather than the points.

[zhzyx]

I'm using the clowder API to get scanners/cameras data from same plot in a season. Those coordinates are from the polygons.
I got those coordinates by accessing the API: /api/geostreams/datapoints?stream_id=ID
For example I got the id from Season 4 Range 20 Column 9 is 21167
Then those coordinates was showed in geometry->coordinates
I think the ordering is not the major issue for me. 33.075245 for latitude is a reasonable number, but -68 seems too far away from the plots if it's the longitude.

[max-zilla]

I believe what we're seeing is the incorrect outputs of the old version of the 3d scanner’s sensorposition algorithm that wasn't properly being georeferenced (the coordinates are in the ocean east of Florida). The new extractor should fix this but we need to reprocess the metadata for the incorrect data. I see the coordinates as well - I will take a closer look to verify we have a corrected algorithm now.

[max-zilla]

Still tracking this down. The metadata on the objects themselves show correct coordinates, but the datapoints still have some incorrect coordinates and i havent figured out how these are being introduced or broken yet.