OSGeo.org › OSGeo Software Projects › GeoNetwork opensource › GeoNetwork developer

Re: Some thoughts on transformations and extents

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Paul van Genuchten

Re: Some thoughts on transformations and extents

Hi Sander, I’m not fully aware of the limitations of the current approach, so my answers may be a bit off topic.

(I’m cc-ing developer list, so all are aware of the discussion)

Le ven. 6 nov. 2020 à 11:08, Sander Schaminee <[hidden email]> a écrit :
Hi Olivier et al.,

Following up on my recent PR and some discussion I had with Paul, I had a couple of thoughts that I'd like to discuss with you.

1. Shall I port the polar fix to the 4.0 branch?
Maybe I should have created the fix in 4.0 in the first place and then backport it, but it is what it is. However, it would make sense that this fix is available in all future releases, I guess.

A valid question, larger developments should, since the release of 4.0 preferably be developed against 4.0 and then backported to 3.x. To avoid the risk of those branches diverging too much.

2. I noticed that we transform extents to WGS 1984 in some places. This might lead to faulty or distorted reprojections, if the extent includes a pole or is far up north or south (e.g. Canada, Argentina).
Places where we reproject bbox-extents into EPSG:4326 are HeatMapService.js, and potentially ProjectionSwitcher.js and WfsDirective.js (2x), where the target projections are dynamically set and could be EPSG:4326 (or some other projection that causes distortions).
The question is: shall I improve these reprojections, e.g. by converting the extent into a polygon feature, reprojecting that using the featureToLonLat() function I added in my PR, and converting it back into an extent again? Note that the transformExtent() function in OpenLayers actually includes a stop parameter that we currently do not use. This will already improve the accuracy, but will still lead to a faulty reprojection when it covers the polar area, I noticed.

I guess we need careful evaluation of which type of bbox-reprojections lead to most bad results. I guess in upcoming developments we should cover those cases first.

Bbox improvements seem most important when accessing directly elastic/lucene with a client side reprojected box.

3. Should we make the maximum extents of a user-defined projection mandatory in the UI Settings?
Related to this issue, some functionality will now never work (even if we fix the errors), because the projection extent might be undefined whenever a user sets its own map projection. To properly solve this, we should (a) make the extent fields mandatory in the UI settings or (b) try to resolve the bounding box for the projection ourselves, e.g. by querying the public EPSG.io API, for example for the Dutch EPSG:28992 it returns this JSON, which contains a bbox property in WGS 1984 coordinates.
Any thoughts on this?

I’m very much in favor of querying some api to retrieve projection information, current implementation requiring specific copy-past from some webpage is not optimal.

And, if needed (no sensible defaults), please make the fields required.

_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Sander Schaminee

Re: Some thoughts on transformations and extents

Please note: I have just created a PR related to issue #3 in this thread.

Sander

On Mon, Nov 9, 2020 at 2:55 PM Paul van Genuchten <[hidden email]> wrote:

Hi Sander, I’m not fully aware of the limitations of the current approach, so my answers may be a bit off topic.
(I’m cc-ing developer list, so all are aware of the discussion)

Le ven. 6 nov. 2020 à 11:08, Sander Schaminee <[hidden email]> a écrit :
Hi Olivier et al.,

Following up on my recent PR and some discussion I had with Paul, I had a couple of thoughts that I'd like to discuss with you.

1. Shall I port the polar fix to the 4.0 branch?
Maybe I should have created the fix in 4.0 in the first place and then backport it, but it is what it is. However, it would make sense that this fix is available in all future releases, I guess.

A valid question, larger developments should, since the release of 4.0 preferably be developed against 4.0 and then backported to 3.x. To avoid the risk of those branches diverging too much.

2. I noticed that we transform extents to WGS 1984 in some places. This might lead to faulty or distorted reprojections, if the extent includes a pole or is far up north or south (e.g. Canada, Argentina).
Places where we reproject bbox-extents into EPSG:4326 are HeatMapService.js, and potentially ProjectionSwitcher.js and WfsDirective.js (2x), where the target projections are dynamically set and could be EPSG:4326 (or some other projection that causes distortions).
The question is: shall I improve these reprojections, e.g. by converting the extent into a polygon feature, reprojecting that using the featureToLonLat() function I added in my PR, and converting it back into an extent again? Note that the transformExtent() function in OpenLayers actually includes a stop parameter that we currently do not use. This will already improve the accuracy, but will still lead to a faulty reprojection when it covers the polar area, I noticed.

I guess we need careful evaluation of which type of bbox-reprojections lead to most bad results. I guess in upcoming developments we should cover those cases first.
Bbox improvements seem most important when accessing directly elastic/lucene with a client side reprojected box.

3. Should we make the maximum extents of a user-defined projection mandatory in the UI Settings?
Related to this issue, some functionality will now never work (even if we fix the errors), because the projection extent might be undefined whenever a user sets its own map projection. To properly solve this, we should (a) make the extent fields mandatory in the UI settings or (b) try to resolve the bounding box for the projection ourselves, e.g. by querying the public EPSG.io API, for example for the Dutch EPSG:28992 it returns this JSON, which contains a bbox property in WGS 1984 coordinates.
Any thoughts on this?

I’m very much in favor of querying some api to retrieve projection information, current implementation requiring specific copy-past from some webpage is not optimal.
And, if needed (no sensible defaults), please make the fields required.