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

Reply via email to