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. so far, so good christian Andrea Aime writes: > Hi, > I'm having some issues with BBOX and BBOXImpl I would like to > share. > > The problem I'm trying to solve at the moment is to properly > encode spatial filters against spatial dbms. These dbms pretend > the geometry part of the filter to be encoded with the proper > CRS, usually encoded as a integer known as SRID. > Failure to use the right SRID results in exceptions. > > There are issues with this: > * the native SRID might have no match at all in the EPSG databse, > and people will often force the CRS to some other equivalent > but official EPSG code > * geometry literals in filters come from the user side, I've > never seen a geometry with the proper srid set, usually > they have no SRS information at all > * JTS geometries have a place to store the srid as an int, > and some code stores the CRS as a user property in the > geometry, but none of them can really be trusted > * filters like BBOX do not even even that > > So the idea is to preprocess the filter and fix the srid > in the JTS geometries before they are encoded, by looking > at the native srid of the attribute that is being compared > with the geometry. This works fine with JTS geometries, > blows up with BBOX: the only non deprecated way to grab > the bbox srs is to use ((BoundingBox) > bbox.getExpressionX()).getCoordinateReferenceSystem(). > This is wrong in many ways: > - the filter factory does not set the CRS at all > - most probably because the srs passed in is not > guaranteed to be decodable at all > - because, remember, the native srid might not mean > anything to the official EPSG authority > - or because it could be just plain wrong > > So the current idea I have is to create a custom subclass > of BBoxImpl that can store the srid and use it only in the > above visitor: a solution local to the JDBC datastores, for > a problem that's specific of the JDBC datastores. > And that would solve the JDBC specific issue. > > Still makes me wonder thought... BBOX does not have any > non deprecated way to get the SRS... why build the bbox > with an "String SRS" at all then, isn't it more logical > to pass a full blown CRS and avoid the headaches of > whether the SRS can be decoded or not? > If we think the SRS should be preserved instead, then > the BBOX.getSRS() method should be un-deprecated. > > 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 ------------------------------------------------------------------------- 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
