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

2016-07-01 Thread Ben Caradoc-Davies 
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 [b...@transient.nz]
> Sent: Friday, July 01, 2016 1:37 AM
> To: Dünnebeil Gerhard; geoserver-users@lists.sourceforge.net
> Cc: katharina.schle...@umweltbundesamt.at
> 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 (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.duenneb...@ait.ac.at<mailto:gerhard.duenneb...@ait.ac.at>  |  
>> http://www.ait.ac.at<http://www.ait.ac.at/>
>>
>> FN: 115980 i HG Wien  |  UID: ATU14703506
>> http://www.ait.ac.at/Email-Disclaimer
>>
>>
>>
>>
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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
>&

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

2016-06-30 Thread Dünnebeil Gerhard 
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 [b...@transient.nz]
Sent: Friday, July 01, 2016 1:37 AM
To: Dünnebeil Gerhard; geoserver-users@lists.sourceforge.net
Cc: katharina.schle...@umweltbundesamt.at
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 (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.duenneb...@ait.ac.at<mailto:gerhard.duenneb...@ait.ac.at>  |  
> http://www.ait.ac.at<http://www.ait.ac.at/>
>
> FN: 115980 i HG Wien  |  UID: ATU14703506
> http://www.ait.ac.at/Email-Disclaimer
>
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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 <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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

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

2016-06-30 Thread Ben Caradoc-Davies 
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 (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.duenneb...@ait.ac.at  |  
> http://www.ait.ac.at
>
> FN: 115980 i HG Wien  |  UID: ATU14703506
> http://www.ait.ac.at/Email-Disclaimer
>
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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 
Director
Transient Software Limited 
New Zealand

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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

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

2016-06-30 Thread Dünnebeil Gerhard 
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.duenneb...@ait.ac.at  |  
http://www.ait.ac.at

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

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT 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