I bet I understand what the dependencies are ... probably on DirectPosition and a bunch of really primitive geometry code. All this code has been duplicated (and improved on) as part of the unsupported/geometry module :-(
We should ask martin (who earlier requested that utility code be kicked out of metadata) if we can gather up all the utility code into the gt2-api module. I am asking this for two reasons: - I think martin would like it - he is correct that GeoTools configuration, logging and JNDI support have nothing to do with "metadata" - It would clean up the library some to have gt2-api as a base dependency at the same level as JTS and GeoAPI. Cheers, Jody > Hmmm, initially I thought that this would be doable since there are a > bunch of other depenendencies but they all appear to be in referencing > and metadata. Looking at things I think that the referencing module is > probably a better place for it... Would anyone have any objections to > throwing it in there? > > Jody Garnett wrote: > > > >> 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 >>> >>> >>> >> !DSPAM:4007,468d28c3261607180515871! >> >> > > > ------------------------------------------------------------------------- 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
