Hi all, I am currently making the modifications we have discussed over the last few days to the feature model and have run into a hitch with regard to changing Feature.getBounds().
Now the plan was to simply change the return type of getBounds() from "Envelope" to "ReferencedEnvelope". Now since RE is a subclass of E this should not break any client code. And also when gt Feature extends from geoapi Feature RE also implements BoundingBox so type narrowing saves us there too. However... the issue is that ReferencedEnvelope lives in the main module and the Feature interface of course in the api module... gah!! So... one of two ways to proceed. 1. We either rename getBounds() to remove the conflict like we have been doing for the other conflicts. 2. Or we get evil... and create a class in the api module which satisfies two constraints: * It extends from JTS Enevleope * It implements geoapi BoundingBox, and geoapi Envelope ( like ReferencedEnvelope does now ) Then we change ReferencedEnvelope to extend our new Envelope and everything should work as before. What do people think? -Justin -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
