[Geoserver-users] WPS Process SRS Output blocked to EPSG:4326

GeoServer GeoServer User
1

Hi,
I just updated GeoServer from version 2.18.2 to 2.21.1 and I noticed that, in the latest version of GeoServer, using the WPS gs:Query and gs:IntersectionFeatureCollection processes the SRS of the output geometries is EPSG: 4326.

In version 2.18.2 that I used before, the coordinate system of the output geometry was instead that of the starting layer on which the process was performed, for example EPSG: 3003. Also, in the JSON of the output, in addition to the “features” property there was the “crs” property which contained the coordinate system information.

I would need to output the same coordinate system as the starting layer (as was the case in the previous version of GeoServer), is this possible? If not, is there any workaround? I specify that the starting layer can have different coordinate systems and therefore I cannot force it but it must be taken dynamically.

Thank you,

Daniele

2

GeoJSON is required to be in 4326 by the specification, we have just come into conformance with that standard. I don’t think there is any way to force it back to the old way.

A solution if you need to use a better projection is to ask for your output in GML instead

Ian

···

Ian Turton

3

Ok, but if I use WFS service in GeoServer i can use srsName property for having coordinate with native system in JSON format. So why not give the possibility to use different systems also on wps processes?
Is not easy to use gs:IntersectionFeatureCollection because is rare that the first or the second features are in 4326. The result of the process will be empty if the feature was not reprojected before.

However, which option should I use to generate the GML format?

Thank you,
Daniele

Daniele Maggiolo | Abitat SIT

daniele.maggiolo@…9165…

0444 794127

image001.png

···

Da: Ian Turton <ijturton@…84…>
Inviato: venerdì 23 settembre 2022 17:37
A: Daniele Maggiolo <daniele.maggiolo@…9165…>
Cc: geoserver-users@lists.sourceforge.net
Oggetto: Re: [Geoserver-users] WPS Process SRS Output blocked to EPSG:4326

GeoJSON is required to be in 4326 by the specification, we have just come into conformance with that standard. I don’t think there is any way to force it back to the old way.

A solution if you need to use a better projection is to ask for your output in GML instead

Ian

On Fri, 23 Sept 2022 at 16:29, Daniele Maggiolo via Geoserver-users <geoserver-users@lists.sourceforge.net> wrote:

Hi,
I just updated GeoServer from version 2.18.2 to 2.21.1 and I noticed that, in the latest version of GeoServer, using the WPS gs:Query and gs:IntersectionFeatureCollection processes the SRS of the output geometries is EPSG: 4326.

In version 2.18.2 that I used before, the coordinate system of the output geometry was instead that of the starting layer on which the process was performed, for example EPSG: 3003. Also, in the JSON of the output, in addition to the “features” property there was the “crs” property which contained the coordinate system information.

I would need to output the same coordinate system as the starting layer (as was the case in the previous version of GeoServer), is this possible? If not, is there any workaround? I specify that the starting layer can have different coordinate systems and therefore I cannot force it but it must be taken dynamically.

Thank you,

Daniele

Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

Ian Turton

4

I have also seen that the areaB parameter that returns from the gs: IntersectionFeatureCollection process is not correct.

Making an intersection between layers with the same coordinates system and the same geometries, in the property areaB there are wrong values.

image001.png

···

Daniele Maggiolo | Abitat SIT

daniele.maggiolo@…9165…

0444 794127

Da: Daniele Maggiolo
Inviato: venerdì 23 settembre 2022 17:55
A: Ian Turton <ijturton@…84…>
Cc: geoserver-users@lists.sourceforge.net
Oggetto: R: [Geoserver-users] WPS Process SRS Output blocked to EPSG:4326

Ok, but if I use WFS service in GeoServer i can use srsName property for having coordinate with native system in JSON format. So why not give the possibility to use different systems also on wps processes?
Is not easy to use gs:IntersectionFeatureCollection because is rare that the first or the second features are in 4326. The result of the process will be empty if the feature was not reprojected before.

However, which option should I use to generate the GML format?

Thank you,
Daniele

Daniele Maggiolo | Abitat SIT

daniele.maggiolo@…9165…

0444 794127

Da: Ian Turton <ijturton@…84…>
Inviato: venerdì 23 settembre 2022 17:37
A: Daniele Maggiolo <daniele.maggiolo@…9165…>
Cc: geoserver-users@lists.sourceforge.net
Oggetto: Re: [Geoserver-users] WPS Process SRS Output blocked to EPSG:4326

GeoJSON is required to be in 4326 by the specification, we have just come into conformance with that standard. I don’t think there is any way to force it back to the old way.

A solution if you need to use a better projection is to ask for your output in GML instead

Ian

On Fri, 23 Sept 2022 at 16:29, Daniele Maggiolo via Geoserver-users <geoserver-users@lists.sourceforge.net> wrote:

Hi,
I just updated GeoServer from version 2.18.2 to 2.21.1 and I noticed that, in the latest version of GeoServer, using the WPS gs:Query and gs:IntersectionFeatureCollection processes the SRS of the output geometries is EPSG: 4326.

In version 2.18.2 that I used before, the coordinate system of the output geometry was instead that of the starting layer on which the process was performed, for example EPSG: 3003. Also, in the JSON of the output, in addition to the “features” property there was the “crs” property which contained the coordinate system information.

I would need to output the same coordinate system as the starting layer (as was the case in the previous version of GeoServer), is this possible? If not, is there any workaround? I specify that the starting layer can have different coordinate systems and therefore I cannot force it but it must be taken dynamically.

Thank you,

Daniele

Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

Ian Turton

5

Hmm… that aspect of the specification is broken for several applications (the ones in need of centimetric+ accuracy, due to the uncertainty of WGS84 epoch).
OGC API Features opted for the prior arrangement clause and have set up a working group for GeoJSON extensions that will break it free of such limitations.

On a practical note, I believe GeoServer should allow for choice, maybe driven by the mime type:

  • if the “application/geo+json” official mime type is used, maybe be strict and generate RFC compliant GeoJSON
  • if “application/json” is used instead, generate pre-RFC GeoJSON with native CRS and the CRS attribute

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 339 8844549

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

6

Hi,

Support for other CRSs than WGS84 is definitely needed and by now the best option for my mind is to use pre-RFC GeoJSON. Even it is deprecated it has quite wide support for example through GDAL. The OGC work on the new Features and Geometries JSON happens in https://github.com/opengeospatial/ogc-feat-geo-json but it will still take about a year before the standard is ready.

-Jukka Rahkonen-

···

Lähettäjä: Andrea Aime andrea.aime@anonymised.com
Lähetetty: torstai 29. syyskuuta 2022 11.33
Vastaanottaja: Ian Turton ijturton@anonymised.com
Kopio: geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] WPS Process SRS Output blocked to EPSG:4326

On Fri, Sep 23, 2022 at 6:00 PM Ian Turton <ijturton@anonymised.com> wrote:

GeoJSON is required to be in 4326 by the specification, we have just come into conformance with that standard. I don’t think there is any way to force it back to the old way.

Hmm… that aspect of the specification is broken for several applications (the ones in need of centimetric+ accuracy, due to the uncertainty of WGS84 epoch).

OGC API Features opted for the prior arrangement clause and have set up a working group for GeoJSON extensions that will break it free of such limitations.

On a practical note, I believe GeoServer should allow for choice, maybe driven by the mime type:

  • if the “application/geo+json” official mime type is used, maybe be strict and generate RFC compliant GeoJSON
  • if “application/json” is used instead, generate pre-RFC GeoJSON with native CRS and the CRS attribute

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 339 8844549

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