riatelab / magrit

Thematic cartography entirely in the browser ♥
https://magrit.cnrs.fr
GNU General Public License v3.0
123 stars 18 forks source link

Projection and drawing issues on large rectangular boxes #90

Closed rysebaert closed 1 year ago

rysebaert commented 1 year ago

When uploading a rectangular frame in Magrit with EPSG:3035 (ETRS89-extended / LAEA Europe), it seems that there is a mistake with the reprojection (cf below screenshot with associated layer, attached). Any idea ?

This layer in R or QGIS should_be

Same in Magrit is

Associated geojson file frame.zip

rCarto commented 1 year ago

I suspect that the frame has only four points. I think that adding intermediate points would solve the problem.

neocarto commented 1 year ago

It comes from the way d3.js handles projections. As Tim says, I think this can be fixed outside Magrit by densifying the polygon.

mthh commented 1 year ago

I confirm the problem is not in the reprojection per se (I guess the 4 points that describe the rectangle are reprojected the same / with the same coordinates in Magrit and QGIS) but in the way the lines between the points in question are drawn.

In Magrit (due to the underlying use of d3), lines between two points are not straight line on the plane but segment of great circles (geodesics).

Look at the example below which illustrates this (and for which I think the line drawing is correct).

Line between Spain and California in various projections ![LAEA](https://user-images.githubusercontent.com/12172162/193201702-8a7f8ee1-e59e-4dce-9e4a-a02009f551fb.png) ![mercator](https://user-images.githubusercontent.com/12172162/193201713-d4ad0d35-dca7-48de-a574-d074be687454.png) ![LAE](https://user-images.githubusercontent.com/12172162/193201722-a307e66d-3a64-4e00-a7fb-2dea5d10c8ac.png)

However I am not sure that the curves we get on your screenshot are correct and there must be something to do in Magrit as well ? (don't you think @neocarto ?)

In the meantime, the workaround on your side is to densify the geometries as advised by @rcarto and @neocarto.

neocarto commented 1 year ago

Well, if @rysebaert share the geometry of the box, I can make some tests.

mthh commented 1 year ago

It's in the "frame.zip" file attached to the first post. Beware that it's not a rfc7946-compliant geojson (as it contains geometries in EPSG:3035).

neocarto commented 1 year ago

I can't reproduce Ronan's image. When I import the geojson into Magrit and choose the EPSG:3035 projection, I get this result (see pj). However, I think that maybe we should add "none" or "already projected" in the projection menu to avoid these distortions. This is what I do in bertin.js 3035

mthh commented 1 year ago

Yeah I saw that the frame.geojson was triggering some other issues in Magrit :-/

I'm not sure where these artifacts came from. It could be because there is no clipping when you ask for the epsg:3035 projection and because the coordinates of @rysebaert frame are outside the extent of the EPSG:3035 projection.

Frame GeoJSON :

minX = 2380000.0 maxX = 6550000.0 minY = 1350000.0 maxY = 5420000.0

EPSG:3035 extent :

minX_proj = 1896628.62 maxX_proj = 4629821.48 minY_proj = 1507846.05 maxY_proj = 6882401.15

>>> minX < minX_proj
False
>>> minY < minY_proj
True
>>> maxX > maxX_proj
True
>>> maxY > maxY_proj
False

Having a "none" or "already projected" option would be a major change in Magrit (which we have already discarded in the past - but I'm not that stubborn about it!) So, I wouldn't mind implementing this in a future version, but it would involve changes in many places (because until now all datasets had to be associated with a CRS, all datasets were converted to GeoJSON with WGS84 coordinates, etc. so many calculations like those needed for some representations are based on these assumptions).

rysebaert commented 1 year ago

Thks for the feedbacks and explanations guys ! Yes @neocarto , my Magrit's image was a zoom in. I have in fact the same than yours... And @mthh, agree with you, the geojson should be in WGS84 to be compliant...

Nevermind, my European template looks good without this frame...
magrit_template

mthh commented 1 year ago

Looks great !

mthh commented 1 year ago

Anyway, I'm a bit worried about the rendering of rectangular frames like the following :

{
"type": "FeatureCollection",
"name": "frame",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3035" } },
"features": [
{ "type": "Feature", "properties": { }, "geometry": { "type": "Polygon", "coordinates": [ [ [ 2380000.0, 1500000.05 ], [ 4600000.48, 1500000.05 ], [ 4600000.48, 5420000.0 ], [ 2380000.0, 5420000.0 ], [ 2380000.0, 1500000.05 ] ] ] } }
]
}

(derived from the original frame of @rysebaert in order to have all coordinates within EPSG:3035 bounds, still not rfc7946-compliant but Magrit still supports geojson-2008)

Using "EPSG:3035" string in "Projection from WKT/Proj4/EPSG string..." option of Magrit (so it uses proj.4 under the hood) I have this weird extra-line :

bad1

Using the "More option..." value in the projection menu and selecting any of the projection (so it uses d3-geo-projection under the hood) I obtain the inverse of the desired polygon :

bad2

I'm letting this issue open, tagging it as a bug and I will have a closer look on Magrit's projections in the next few weeks.

neocarto commented 1 year ago

This is not specific to Magrit. I don't know how to do an automatic rewind of the geometries to avoid this. https://www.npmjs.com/package/@turf/rewind

mthh commented 1 year ago

The coordinates of the geojson in my last post are already counterclockwise.

mthh commented 1 year ago

Fixed by 326e3c8.