Move the ReferencedEnvelope class into api module - it will not be so bad if some utility classes live there. It may also be a home for much of Martin's util work (that is currently living in the metadata module?).
Cheers, Jody > 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 > > ------------------------------------------------------------------------- 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
