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 (<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.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&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 <b...@transient.nz> > Director > Transient Software Limited <http://transient.nz/> > New Zealand > -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ 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
