[email protected] wrote: > Hi Justin, > > I like your second idea, and it is actually similar to the patch Jody whipped > up (http://jira.codehaus.org/secure/attachment/50280/GML2EncodingUtils.patch). > Since AbstractFeatureTypeBinding.getProperties() eventually calls > GML2EncodingUtils.getProperties() anyway, we can make the changes there > again. > So, instead of checking for GeometryAttribute only, it also checks if value > is a Geometry, and get the SRS from the type. > What's wrong with using userData though?
For starters, it is a convention that was made up without discussing it. It's not part of the GeoTools API, as a result only the bits that were hand hacked to support it make the srs be encoded in GML. To actually support it properly we'd have to modify all data stores and all collection wrappers, and document that it needs to be supported too. As a second problem, it creates information redundance, which is generally considered bad in IT circles because of extra storage (not a problem in this case) and because of potential inconsistencies between the various copy (the userdata could state a CRS other than the attribute) There is one case in which it cannot be avoided, which is, if an attribute has no defined srs and all geometries can have their own. Which seems pretty silly to me, won't be supported by most storage formats, but unfortunately I fear it's also a case tested by the WFS cite tests... Btw, having a single default SRS can be limiting, a feature type can legitimately have multiple columns in different srs. That is something supported by spatial databases for example. It's also a bit of a narrow use case though. Cheers Andrea ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
