Christian Müller ha scritto: > Nice to get your mail, yesterday I paused my db2 spatial extender > implementation because of the SRID problem. > Some inputs from me and the DB2 front. > 1) The Native SRID used in DB2 does not directly determine a CRS. The > SRID determines the extent of a SRS and the accuracy of the > calculations.(DB2 stores coordinates internal as 4 byte integer). > Additionally the SRS refers to the used CRS. What I want to say is that > many SRIDs can refer to the same CRS. > 2) Postigs SRIDs are the epsg codes, DB2 and I think Oracle SRIDs do not > use the EPSG codes, we cannot rely on this. > 3) The native SRIDS are needed on the db (jdbc) interface. Each Geometry > Attribute in a Table has a SRID. The SRID for each > jdbc geometry column should be part of the Schema Metainformation. Before > creation of new schema (table), you have to know and to pass the native > SRID. > 4) A very secure approach would be to pass the native SRID as a > parameter to any method responsible for handling geometries. > (Dialect and Encoder classes ). In my opinion I would not use the JTS > srid and other framework possiblities because the use of the native SRID > is limited to the methods doing the jdbc stuff. It is not a good idea to > make native SRIDs accessible to other parts of geotools because they > have no meaning to other modules causing headaches to other developers.
I agree with most of the above, and yes, we've setup things so that all methods encoding geometries receive a separate srid (not sure about the non prepared statemetn paths, I have to check that, but sure for the ps one). This works fine for most operations, but gives me some troubles with filter encoding, because we have geometry literals that have to be passed around without a direct assoaction with a property. The approach I proposed had the nice feature of being usable for both non ps and ps code paths. In the non ps code path in particular the encoder would know where to find the srid information without having to figure it out. Yet, as you say the approach is ugly for a number of reasons: * having to resort to a custom bboximpl subclass is butt ugly * the approach won't work anymore when we switch to a more generic geometry model (GeoAPI Geometry does not know what a native srid is at all and has no place for user data) * http://jira.codehaus.org/browse/GEOT-1999 About GEOT-1999, I would like your opinion on it. Do you see any trouble in enforcing a pure prepared statements approach? So far I see significant benefits and no downsides, what about you? Going back to this issue, if I can assume only PS, the much nicer way it to build up a filter visitor that returns an array of srid, one for each bound parameters, and be done with it: for ps path the PreparedFilterToSql already builds an array of values and types for each parameter encoded with ?, I just need to expand it to build up a parallel array of srid and be done with it (of course there will be a native srid only for geometric values, not for the rest). Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
