Presence/occurrences viewer in the debug UI seem to require lat/lon coordinates

[frousseu]

When occurrences are in a projected coordinate system, they are not well displayed in the occurrence viewer. They seem to be at the edges of the 180/-180 coordinates, suggesting the map requires coordinates in a geographic system.

[tpoisot]

I know @gottacatchenall and I had this conversation / mental breakdown the other day, but since RFC7946 says WGS84 for point and polygon data, maybe we should be compliant to the standard and enforce points in WGS84. I think it would clear up a lot of potential issues, and then it's a front-end / user responsibility to project when required?

[frousseu]

So, just want to add that the problem is specific to the debug UI, not the results viewer (which I had forgotten).

I think enforcing WGS84 would be a bit of a pain, since a lot of methods require projected coordinates.

[jmlord]

So, just want to add that the problem is specific to the debug UI, not the results viewer (which I had forgotten).

Yes, @glaroc added a logic in the viewer, where it uses the first thing that looks like a projection in the outputs to project everything, except those that look like WGS84 with a range check. While this is true most of the time, it could be false if a pipeline uses more than one projection system.

We could add similar logic to the Debug UI, but I was hoping for a real way to fix this, such as embedding it in the yml that an output can refer to a projection system in a neighboring output in order to project correctly. Too complicated UI?

[tpoisot]

I think enforcing WGS84 would be a bit of a pain, since a lot of methods require projected coordinates.

It would, but it comes with the benefit of no surprises - we're returning points / polygons as GeoJSON. If a method requires projection, it should be handled internally by the script that requires it. I think no surprises for users >> ease of development.

[glaroc]

The current GEOJSON spec implies that all coordinates are in WGS84. However, many of the lists of presences or pseudoabsence we have are in CSV. It would be simpler to always force this to be in WGS84, but there will likely be pipelines at some point that will require more precision that what is possible with WGS84. My feeling is that we should eventually promote the use of GeoPackage instead for all spatial data, while finding a way to add metadata for the layers present in the GPKG. But we currently don't support viewer GPKG in the UI (on the top of my to-do list for the viewer).