[Geoserver-devel] reprojections and multiple geometries

Jukka_Rahkonen · October 9, 2021, 1:00pm

Hi,

If I understand right your message and the standard, WFS 2.0 does not have any support for reprojecting both 2D and 3D geometries with a single request because srsName can appear only once in GetFeature. So if srsName is some 2D crs then 3D geometry is not projected and if srsName is some 3D crs then the 2D geometry is not projected. That feels suboptimal.

I agree that transforming 3D CRS into 2D when there is no srsName in GetFeature request is clearly unwanted behaviour. Otherwise I think that WFS 2.0 does not feel ready for handling reprojection of multiple geometries in different native CRS. The solution could to make it possible in WFS to give a separate srsName for each geometry. It seems that the problem will be the same with OGC API Features. The core says that features may have several geometries but the crs extension supports only one crs in the items request.

It may be impossible to do this with so that it is both right according to the standards and reasonable for the users but I wish you a good luck.

-Jukka Rahkonen-

-----Alkuperäinen viesti-----
Lähettäjä: Niels Charlier via Geoserver-devel <geoserver-devel@anonymised.comsourceforge.net>
Lähetetty: lauantai 9. lokakuuta 2021 15.05
Vastaanottaja: Geotools-Devel list <geotools-devel@lists.sourceforge.net>; Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Aihe: [Geoserver-devel] reprojections and multiple geometries

Hello Everyone,

I am sending this email to both geotools and geoserver lists because the matter concerns both.

I recently made a PR to improve geotools/geoserver behaviour with respect to multiple geometries that have different CRS.
(https://github.com/geotools/geotools/pull/3642) One of the matters that is being discussed between Andrea and me is the expected behaviour on reprojection.

I attempted to follow the instructions and examples given for the "srsName" parameter specified by the OCR WFS2.0 specs
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95
<https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95>\) These seem to suggest that geometries that have a 'incompatible' CRS are simply not reprojected, without failure. The only example given for 'incompatibility' is having a different dimension. Andrea noted that transformation only fails in the direction 2D->3D while it works the other way around, so that it should still be reprojected in that case.
However, the example given in the specs suggests explicitely that a 3D geometry would not be converted to a 2D srsName. This seems to be what is expected in my use case as well.

The problem is complicated further by the fact that in geoserver, the implementation of GetFeature sometimes explicitly specifies a reprojection CRS in the query, even if there was no srsName in the http request (the reason has something to do with how different wfs versions handle crs encoding and axis order. ) What would happen then is that even when no srsName is specified, the 3D CRS is always being transformed to 2D, which is clearly unwanted behaviour.

Inspire schemas often require feature types with a (primary) 2D geometry and a (secondary) 3D geometry.

Kind Regards

Niels

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Niels_Charlier · October 11, 2021, 1:20pm

Hello Jukka,

Thanks for your answer. I guess I wanted to ask the opinion of the community on how to proceed. I see at this point two options:

1) stick with the suggestion of the standard, and do not project 3D->2D. (The easiest solution, what I already have).

2) allow reprojection 3D->2D and only prevent 2D->3D reprojection (Andrea's suggestion). This will require quite a lot of further core changes:
- modification of Query in geotools to allow reprojection per geometry (with backwards compatibility for the current existing fields).
- modification of GetFeature implementation in geoserver so that without srsName specified, the 'right' geometries are being reprojected to the right CRS.

Kind Regards

Niels

On 09/10/2021 15:00, Rahkonen Jukka (MML) wrote:

Hi,

If I understand right your message and the standard, WFS 2.0 does not have any support for reprojecting both 2D and 3D geometries with a single request because srsName can appear only once in GetFeature. So if srsName is some 2D crs then 3D geometry is not projected and if srsName is some 3D crs then the 2D geometry is not projected. That feels suboptimal.

I agree that transforming 3D CRS into 2D when there is no srsName in GetFeature request is clearly unwanted behaviour. Otherwise I think that WFS 2.0 does not feel ready for handling reprojection of multiple geometries in different native CRS. The solution could to make it possible in WFS to give a separate srsName for each geometry. It seems that the problem will be the same with OGC API Features. The core says that features may have several geometries but the crs extension supports only one crs in the items request.

It may be impossible to do this with so that it is both right according to the standards and reasonable for the users but I wish you a good luck.

-Jukka Rahkonen-

-----Alkuperäinen viesti-----
Lähettäjä: Niels Charlier via Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Lähetetty: lauantai 9. lokakuuta 2021 15.05
Vastaanottaja: Geotools-Devel list <geotools-devel@lists.sourceforge.net>; Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Aihe: [Geoserver-devel] reprojections and multiple geometries
D-
Hello Everyone,

I am sending this email to both geotools and geoserver lists because the matter concerns both.

I recently made a PR to improve geotools/geoserver behaviour with respect to multiple geometries that have different CRS.
(https://github.com/geotools/geotools/pull/3642) One of the matters that is being discussed between Andrea and me is the expected behaviour on reprojection.

I attempted to follow the instructions and examples given for the "srsName" parameter specified by the OCR WFS2.0 specs
(https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95
<https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95>\) These seem to suggest that geometries that have a 'incompatible' CRS are simply not reprojected, without failure. The only example given for 'incompatibility' is having a different dimension. Andrea noted that transformation only fails in the direction 2D->3D while it works the other way around, so that it should still be reprojected in that case.
However, the example given in the specs suggests explicitely that a 3D geometry would not be converted to a 2D srsName. This seems to be what is expected in my use case as well.

The problem is complicated further by the fact that in geoserver, the implementation of GetFeature sometimes explicitly specifies a reprojection CRS in the query, even if there was no srsName in the http request (the reason has something to do with how different wfs versions handle crs encoding and axis order. ) What would happen then is that even when no srsName is specified, the 3D CRS is always being transformed to 2D, which is clearly unwanted behaviour.

Inspire schemas often require feature types with a (primary) 2D geometry and a (secondary) 3D geometry.

Kind Regards

Niels

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

jive · October 11, 2021, 3:18pm

We had similar challenge when drawing WMS, if I remember we reproject to wgs84 3D, drop the Elevation, and then reproject from wgs84 to the final 2d projection.

That is our own assumption to draw 3D data, folks can use function calls as part of their WFS query to get a similar result can they not?

It may be sensible to ask users to apply a function for such an usual case….

Jody

···

–
Jody Garnett

Andrea_Aime4 · October 11, 2021, 3:41pm

Before this gets out of hand, my suggestion is limited to the CRS class.
The class is not WFS specific, and should be representing the abilities of GeoTools
coordinate reference subsystem truthfully, rather than being bent to the needs
of a specific WFS use case.

The WFS related issue starts appearing at upper levels… but far sooner than WFS itself,

because the GeoTools Query API is inspired by the WFS API (has only one target CRS)
and the basic reprojection utility classes are geared towards the same model, e.g.,
ReprojectFeatureReader.

That said, I don’t believe the standard has suggestions as to what to do regarding
reprojection of multiple geometry fields… but I’m asking the OGC experts about it.
Will report back here when I have an answer.

I might have missed some bits of the discussion, sorry, trying to do too many things today…
but I felt I was being mis-represented and had to put a stop to it sooner rather than later.

Cheers
Andrea

···

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail

Niels_Charlier · October 11, 2021, 5:04pm

Hello Andrea,

I did not mean to misrepresent you. I actually thought your suggestion made sense. The new method in the CRS class is (currently) only intended for reprojection.

As far as the standard goes, I was referring to the "“OGC® Web Feature Service 2.0 Interface Standard – With Corrigendum”

sections: 7.9.2.4.4 srsName parameter (https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95)
and 7.9.2.4.4.2 compatibly coordinate systems

And in particular this example:
“EXAMPLE: A feature with both 2D and 3D geometry properties is requested with srsName set to a 2D CRS; the 2D property is encoded in the requested CRS, and the 3D property is encoded with some 3D CRS identified in the srsName of the geometry.”

Kind Regards

Niels

···

On 11/10/2021 17:41, Andrea Aime wrote:

On Mon, Oct 11, 2021 at 3:21 PM Niels Charlier via GeoTools-Devel <geotools-devel@lists.sourceforge.net> wrote:

allow reprojection 3D->2D and only prevent 2D->3D reprojection
(Andrea’s suggestion).

Before this gets out of hand, my suggestion is limited to the CRS class.
The class is not WFS specific, and should be representing the abilities of GeoTools
coordinate reference subsystem truthfully, rather than being bent to the needs
of a specific WFS use case.

The WFS related issue starts appearing at upper levels… but far sooner than WFS itself,

because the GeoTools Query API is inspired by the WFS API (has only one target CRS)
and the basic reprojection utility classes are geared towards the same model, e.g.,
ReprojectFeatureReader.

That said, I don’t believe the standard has suggestions as to what to do regarding
reprojection of multiple geometry fields… but I’m asking the OGC experts about it.
Will report back here when I have an answer.

I might have missed some bits of the discussion, sorry, trying to do too many things today…
but I felt I was being mis-represented and had to put a stop to it sooner rather than later.

Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead

GeoSolutions Group phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail

Andrea_Aime4 · October 12, 2021, 7:43am

Hello Andrea,

I did not mean to misrepresent you. I actually thought your suggestion made sense. The new method in the CRS class is (currently) only intended for reprojection.

The CRS class is a generic facade to the capabilities of the referencing subsystem, exposing some of its functionality in a simpler way.
Its javadoc states “Simple utility class for making use of the {@linkplain CoordinateReferenceSystem coordinate
reference system} and associated {@linkplain org.opengis.referencing.Factory} implementations.”

While most of the methods deal with reprojection, some have nothing to do with it, like “lookupIdentifier”. The class is definitely
not meant to be restricted to reprojection alone, nor has a specific focus on WFS related activities.
As said before, it should represent the true capabilities of the referencing subsystem, modules that need specific restrictions
should have their

As far as the standard goes, I was referring to the "“OGC® Web Feature Service 2.0 Interface Standard – With Corrigendum”

sections: 7.9.2.4.4 srsName parameter (https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95)
and 7.9.2.4.4.2 compatibly coordinate systems

And in particular this example:
“EXAMPLE: A feature with both 2D and 3D geometry properties is requested with srsName set to a 2D CRS; the 2D property is encoded in the requested CRS, and the 3D property is encoded with some 3D CRS identified in the srsName of the geometry.”

Oh, quite interesting!
In the meantime, I’ve got this two bits of response:

Regarding OGC API - Features: “if the server implements Part 2 and a CRS is specified then all geometries in the response must be reprojected to the requested CRS in the response.”
Regarding WFS: " WFS is a little more flexible since you can have multiple queries in one request each in a different CRS"

I’ve added the quote above in my chat with the OGC people, let’s see if it stirs up more feedback.

If you want to participate directly, get on gitter and get in this chat: https://gitter.im/opengeospatial/WFS_FES

Cheers
Andrea

···

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail

Niels_Charlier · October 17, 2021, 8:54am

Hello everyone,

Thanks for your comments. I suggest then that I implement the behaviour as it was suggested in the example of WFS 2.0 specs, since this is also the least invasive for the geotools/geoserver code, and there don’t appear to be any particular objections against it. I suggest also however, that I add a boolean parameter to the method in the CRS utility class “allowDifferentDimension” so that the method is generic enough for other purposes and its behaviour with regards to dimensional differences is clear.

Is this a solution that makes sense ?

Kind Regards

Niels

···

On 1/10/2021 09:43, Andrea Aime wrote:

On Mon, Oct 11, 2021 at 7:05 PM Niels Charlier <niels@anonymised.com> wrote:

Hello Andrea,

I did not mean to misrepresent you. I actually thought your suggestion made sense. The new method in the CRS class is (currently) only intended for reprojection.

The CRS class is a generic facade to the capabilities of the referencing subsystem, exposing some of its functionality in a simpler way.
Its javadoc states “Simple utility class for making use of the {@linkplain CoordinateReferenceSystem coordinate
reference system} and associated {@linkplain org.opengis.referencing.Factory} implementations.”

While most of the methods deal with reprojection, some have nothing to do with it, like “lookupIdentifier”. The class is definitely
not meant to be restricted to reprojection alone, nor has a specific focus on WFS related activities.
As said before, it should represent the true capabilities of the referencing subsystem, modules that need specific restrictions
should have their

As far as the standard goes, I was referring to the "“OGC® Web Feature Service 2.0 Interface Standard – With Corrigendum”

sections: 7.9.2.4.4 srsName parameter (https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95)
and 7.9.2.4.4.2 compatibly coordinate systems

And in particular this example:
“EXAMPLE: A feature with both 2D and 3D geometry properties is requested with srsName set to a 2D CRS; the 2D property is encoded in the requested CRS, and the 3D property is encoded with some 3D CRS identified in the srsName of the geometry.”

Oh, quite interesting!
In the meantime, I’ve got this two bits of response:

Regarding OGC API - Features: “if the server implements Part 2 and a CRS is specified then all geometries in the response must be reprojected to the requested CRS in the response.”

Regarding WFS: " WFS is a little more flexible since you can have multiple queries in one request each in a different CRS"

I’ve added the quote above in my chat with the OGC people, let’s see if it stirs up more feedback.

If you want to participate directly, get on gitter and get in this chat: https://gitter.im/opengeospatial/WFS_FES

Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead

GeoSolutions Group phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 333 8128928

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail