[Geoserver-users] Problems with app-schema and srsName

GeoServer GeoServer User
1

Dear all,

I have a problem with the app-schema plugin and the emission of srsName-attributes for geometries.

In some cases the srsName is emitted in the URL form: http://www.opengis.net/gml/srs/epsg.xml#4326

In other cases the URN-Notation is used: “urn:ogc:def:crs:EPSG::4326”

After some debugging I nailed this down to the superficial reason that in one case the CRS has EAST-NORTH orientation (àURL) while in the other case the orientation is NORTH-EAST (à URN).

But why? They all come from the same database and are declared equally.

After a lot more debugging I found that in the URN case a reprojections takes place while the URL case does no reprojection at all.

Even more digging into the dirt showed me the following:

When a URN is emitted, the schema declares the geometry field as a direct child (ef:geometry) of the target element (aqd:AQD_SamplingPoint).

When a URL is emitted, the schema declares the geometry as a second level child (sams:shape/gml:Point) of the target (aqd:AQD_Sample).

The even deeper reason seems to be that the routine org.geotools.feature.type.FeatureTypeImpl.getCoordinateReferenceSystem does not recursively searches into complex types to find a geometry.

Any ideas how to force URN notation?

BTW, I use geoserver 2.7.0 with all “officially” bundled libraries.

Best regards

Gerhard Dünnebeil

GERHARD DÜNNEBEIL
Secure Information Management
Safety & Security Department

AIT Austrian Institute of Technology GmbH
Donau-City-Straße 1 | 1220 Vienna | Austria
T +43(0) 50550-3173 | M +43(0) 664 2351747 | F +43(0) 50550-4150
gerhard.duennebeil@anonymised.com | http://www.ait.ac.at

FN: 115980 i HG Wien | UID: ATU14703506
http://www.ait.ac.at/Email-Disclaimer

2

Gerhard,

I think that you might be affected by a known problem in GeoTools in which a feature type that does not have a top-level geometry is not recognised as having a CRS. See this discussion from 2011 (note references to 2015 are from our Jira migration):

[GEOT-3651] Handling of CRS when reprojecting "complex" FeatureCollection
https://osgeo-org.atlassian.net/browse/GEOT-3651

Although this issue is marked as Fixed, the discussion indicates that it is not. I do not know the alternate solution mentioned by Victor.

I think what is happening is that, when the Encoder receives the nested feature, it falls back to a best-effort attempt to encode the srsName and geometry, but lacks the required information and uses the old URL format and its default axis order settings. I suspect that the geometry is not reprojected in this case.

Kind regards,
Ben.

On 30/06/16 19:25, Dünnebeil Gerhard wrote:

Dear all,

I have a problem with the app-schema plugin and the emission of srsName-attributes for geometries.

In some cases the srsName is emitted in the URL form: http://www.opengis.net/gml/srs/epsg.xml#4326
In other cases the URN-Notation is used: "urn:ogc:def:crs:EPSG::4326"

After some debugging I nailed this down to the superficial reason that in one case the CRS has EAST-NORTH orientation (-->URL) while in the other case the orientation is NORTH-EAST (--> URN).

But why? They all come from the same database and are declared equally.

After a lot more debugging I found that in the URN case a reprojections takes place while the URL case does no reprojection at all.
Even more digging into the dirt showed me the following:

When a URN is emitted, the schema declares the geometry field as a direct child (<targetAttribute>ef:geometry</targetAttribute>) of the target element (<targetElement>aqd:AQD_SamplingPoint</targetElement>).
When a URL is emitted, the schema declares the geometry as a second level child (<targetAttribute>sams:shape/gml:Point</targetAttribute>) of the target (<targetElement>aqd:AQD_Sample</targetElement>).

The even deeper reason seems to be that the routine org.geotools.feature.type.FeatureTypeImpl.getCoordinateReferenceSystem does not recursively searches into complex types to find a geometry.

Any ideas how to force URN notation?

BTW, I use geoserver 2.7.0 with all "officially" bundled libraries.

Best regards
Gerhard Dünnebeil

GERHARD DÜNNEBEIL
Secure Information Management
Safety & Security Department

AIT Austrian Institute of Technology GmbH
Donau-City-Straße 1 | 1220 Vienna | Austria
T +43(0) 50550-3173 | M +43(0) 664 2351747 | F +43(0) 50550-4150
gerhard.duennebeil@anonymised.com<mailto:gerhard.duennebeil@anonymised.com> | http://www.ait.ac.at/&gt;

FN: 115980 i HG Wien | UID: ATU14703506
http://www.ait.ac.at/Email-Disclaimer

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

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

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

3

Dear Ben,

yes, this is the same problem. Even the code snippets mentioned there look familiar.
And yes, what you describe as the fallback scenario is exactly what happens.

Do you think a possible solution would be to provide a CRS for a feature type within the app-schema mapping file?
If it exists, it will override any setting retrieved from the database.

Of course this would require some changes to the app-schema plugin.

best regards
Gerhard

________________________________________
From: Ben Caradoc-Davies [ben@anonymised.com]
Sent: Friday, July 01, 2016 1:37 AM
To: Dünnebeil Gerhard; geoserver-users@lists.sourceforge.net
Cc: katharina.schleidt@anonymised.com
Subject: Re: [Geoserver-users] Problems with app-schema and srsName

Gerhard,

I think that you might be affected by a known problem in GeoTools in
which a feature type that does not have a top-level geometry is not
recognised as having a CRS. See this discussion from 2011 (note
references to 2015 are from our Jira migration):

[GEOT-3651] Handling of CRS when reprojecting "complex" FeatureCollection
https://osgeo-org.atlassian.net/browse/GEOT-3651

Although this issue is marked as Fixed, the discussion indicates that it
is not. I do not know the alternate solution mentioned by Victor.

I think what is happening is that, when the Encoder receives the nested
feature, it falls back to a best-effort attempt to encode the srsName
and geometry, but lacks the required information and uses the old URL
format and its default axis order settings. I suspect that the geometry
is not reprojected in this case.

Kind regards,
Ben.

On 30/06/16 19:25, Dünnebeil Gerhard wrote:

Dear all,

I have a problem with the app-schema plugin and the emission of srsName-attributes for geometries.

In some cases the srsName is emitted in the URL form: http://www.opengis.net/gml/srs/epsg.xml#4326
In other cases the URN-Notation is used: "urn:ogc:def:crs:EPSG::4326"

After some debugging I nailed this down to the superficial reason that in one case the CRS has EAST-NORTH orientation (-->URL) while in the other case the orientation is NORTH-EAST (--> URN).

But why? They all come from the same database and are declared equally.

After a lot more debugging I found that in the URN case a reprojections takes place while the URL case does no reprojection at all.
Even more digging into the dirt showed me the following:

When a URN is emitted, the schema declares the geometry field as a direct child (<targetAttribute>ef:geometry</targetAttribute>) of the target element (<targetElement>aqd:AQD_SamplingPoint</targetElement>).
When a URL is emitted, the schema declares the geometry as a second level child (<targetAttribute>sams:shape/gml:Point</targetAttribute>) of the target (<targetElement>aqd:AQD_Sample</targetElement>).

The even deeper reason seems to be that the routine org.geotools.feature.type.FeatureTypeImpl.getCoordinateReferenceSystem does not recursively searches into complex types to find a geometry.

Any ideas how to force URN notation?

BTW, I use geoserver 2.7.0 with all "officially" bundled libraries.

Best regards
Gerhard Dünnebeil

GERHARD DÜNNEBEIL
Secure Information Management
Safety & Security Department

AIT Austrian Institute of Technology GmbH
Donau-City-Straße 1 | 1220 Vienna | Austria
T +43(0) 50550-3173 | M +43(0) 664 2351747 | F +43(0) 50550-4150
gerhard.duennebeil@anonymised.com<mailto:gerhard.duennebeil@anonymised.com> | http://www.ait.ac.at/&gt;

FN: 115980 i HG Wien | UID: ATU14703506
http://www.ait.ac.at/Email-Disclaimer

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

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

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

4

Gerhard,

I think that a better solution is to make the changes originally proposed by Victor:
https://osgeo-org.atlassian.net/browse/GEOT-3651

Victor and Jody, do you remember this one from 2011?

Jody, did you have some reservations about Victor's patch?

Kind regards,
Ben.

On 01/07/16 16:53, Dünnebeil Gerhard wrote:

Dear Ben,

yes, this is the same problem. Even the code snippets mentioned there look familiar.
And yes, what you describe as the fallback scenario is exactly what happens.

Do you think a possible solution would be to provide a CRS for a feature type within the app-schema mapping file?
If it exists, it will override any setting retrieved from the database.

Of course this would require some changes to the app-schema plugin.

best regards
Gerhard

________________________________________
From: Ben Caradoc-Davies [ben@anonymised.com]
Sent: Friday, July 01, 2016 1:37 AM
To: Dünnebeil Gerhard; geoserver-users@lists.sourceforge.net
Cc: katharina.schleidt@anonymised.com
Subject: Re: [Geoserver-users] Problems with app-schema and srsName

Gerhard,

I think that you might be affected by a known problem in GeoTools in
which a feature type that does not have a top-level geometry is not
recognised as having a CRS. See this discussion from 2011 (note
references to 2015 are from our Jira migration):

[GEOT-3651] Handling of CRS when reprojecting "complex" FeatureCollection
https://osgeo-org.atlassian.net/browse/GEOT-3651

Although this issue is marked as Fixed, the discussion indicates that it
is not. I do not know the alternate solution mentioned by Victor.

I think what is happening is that, when the Encoder receives the nested
feature, it falls back to a best-effort attempt to encode the srsName
and geometry, but lacks the required information and uses the old URL
format and its default axis order settings. I suspect that the geometry
is not reprojected in this case.

Kind regards,
Ben.

On 30/06/16 19:25, Dünnebeil Gerhard wrote:

Dear all,

I have a problem with the app-schema plugin and the emission of srsName-attributes for geometries.

In some cases the srsName is emitted in the URL form: http://www.opengis.net/gml/srs/epsg.xml#4326
In other cases the URN-Notation is used: "urn:ogc:def:crs:EPSG::4326"

After some debugging I nailed this down to the superficial reason that in one case the CRS has EAST-NORTH orientation (-->URL) while in the other case the orientation is NORTH-EAST (--> URN).

But why? They all come from the same database and are declared equally.

After a lot more debugging I found that in the URN case a reprojections takes place while the URL case does no reprojection at all.
Even more digging into the dirt showed me the following:

When a URN is emitted, the schema declares the geometry field as a direct child (<targetAttribute>ef:geometry</targetAttribute>) of the target element (<targetElement>aqd:AQD_SamplingPoint</targetElement>).
When a URL is emitted, the schema declares the geometry as a second level child (<targetAttribute>sams:shape/gml:Point</targetAttribute>) of the target (<targetElement>aqd:AQD_Sample</targetElement>).

The even deeper reason seems to be that the routine org.geotools.feature.type.FeatureTypeImpl.getCoordinateReferenceSystem does not recursively searches into complex types to find a geometry.

Any ideas how to force URN notation?

BTW, I use geoserver 2.7.0 with all "officially" bundled libraries.

Best regards
Gerhard Dünnebeil

GERHARD DÜNNEBEIL
Secure Information Management
Safety & Security Department

AIT Austrian Institute of Technology GmbH
Donau-City-Straße 1 | 1220 Vienna | Austria
T +43(0) 50550-3173 | M +43(0) 664 2351747 | F +43(0) 50550-4150
gerhard.duennebeil@anonymised.com<mailto:gerhard.duennebeil@anonymised.com> | http://www.ait.ac.at/&gt;

FN: 115980 i HG Wien | UID: ATU14703506
http://www.ait.ac.at/Email-Disclaimer

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

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

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand