SRS name isn't encoded for complex types from property data store

Rini Angreani added a comment - 15/Sep/09 1:44 AM Encoding test in Geoserver app-schema covers this: http://jira.codehaus.org/browse/GEOS-3445

Rini Angreani added a comment - 15/Sep/09 1:54 AM Hi Jody, You seem to be the lead of gt-property module, so I'm assigning this to you to review. The changes are quite small and simple (to pass in the CRS from simple feature type to geometry user data, so they're encoded correctly). Thank's Rini

Rini Angreani added a comment - 20/Nov/09 3:02 AM Test case included in Geoserver/src/extension/app-schema/app-schema-test/src/test/java/org/geoserver/test/SRSWfsTest.java. The related commented out bits should work when this is committed.

Rini Angreani added a comment - 08/Jul/10 5:27 AM Hi Jody, Please find my updated patch. What it does, when it reads the property file header, it detects a geometry column and pass on the CRS as Hints to the converter if applicable. The GeometryConverterFactory then extracts the CRS from the Hints, when converting String to Geometry object. The CRS is then set in the userData, to allow srsName to be encoded. Thanks Rini

Jody Garnett added a comment - 11/Jul/10 9:10 PM You will need a test case or two before I can accept the patch; however I agree the direction looks good - and getting the geometry converter to respect the hint is a nice touch. Is there any chance we can have the encoder check the geometry attribute type? As this using of the geometry userData is kind of a workaround?

Rini Angreani added a comment - 11/Jul/10 9:20 PM Hi Jody, Thanks for looking at this. The test that I have is SRSWfsTest in Geoserver/app-schema-test. At the moment it has a lot of things commented out because some things don't work yet, such as this issue. With the patch, I can uncomment them and the test passes. - In testGetFeatureContent: // TODO: Uncomment when GEOT-2708 is fixed // assertXpathEvaluatesTo(EPSG_4283, "(//ex:geomContainer)[1]/ex:geom/gml:Polygon/@srsName", doc); // TODO: Uncomment when GEOT-2708 is fixed // assertXpathEvaluatesTo(EPSG_4283, // "(//ex:geomContainer)[1]/ex:nestedFeature/ex:nestedGeom/ex:geom/gml:Point/@srsName", // doc); // TODO: Uncomment when GEOT-2708 is fixed // assertXpathEvaluatesTo(EPSG_4283, "(//ex:geomContainer)[2]/ex:geom/gml:Point/@srsName", doc); // TODO: Uncomment when GEOT-2708 is fixed // assertXpathEvaluatesTo( // EPSG_4283, // "(//ex:geomContainer)[2]/ex:nestedFeature/ex:nestedGeom/ex:geom/gml:Polygon/@srsName", // doc); I hope that's enough? Or do you want me to write a non-app-schema test case in gt-property? The test uses property file (/gt-app-schema/src/test/resources/test-data/SRSTestPropertyfile.properties). The encoder gets the CRS from the user data, and I can't see how we can change that at the moment (and it's in XSD module). In GML2EncodingUtils: public static CoordinateReferenceSystem getCRS(Geometry g) {         if (g.getUserData() == null) {             return null;         }         if (g.getUserData() instanceof CoordinateReferenceSystem) {             return (CoordinateReferenceSystem) g.getUserData();         }         if (g.getUserData() instanceof Map) {             Map userData = (Map) g.getUserData();             return (CoordinateReferenceSystem) userData.get(CoordinateReferenceSystem.class);         }         return null;     }

Jody Garnett added a comment - 12/Jul/10 12:26 AM It was more meaning that the actual main module where the change is occurring should have a test case (so we don't break this again in the future). In general when asking supplying a patch you need to set things up so the module maintainer can verify your patch does what it says it does; and a test case is a nice way to do this. If you have to supply; or modify one of the property files used that is fine as well. I am not too worried for the property file; more in the use of the CRS Hint (since hints are very easy to break accidentally over time).

Jody Garnett added a comment - 13/Jul/10 6:10 AM Looks fine - thanks for including the test case. Commit when ready.

Rini Angreani added a comment - 14/Jul/10 1:49 AM Thank you Jody. GT-trunk: Committed revision 35908. GT-2.6.x: Committed revision 35909.

Andrea Aime added a comment - 28/Nov/10 2:57 AM Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update