I don't think switching to java 5 is worth it unless it fixes all the conflicts which it does not. So... I need to bring this email thread back into focus. Going to start a new thread for that.
-Justin Jody Garnett wrote: > I just went and checked what I said - and apparently it has been too long! > > getDefaultGeometry() returns a GeometryAttribute - with getValue being > a JTS Geometry, along with getCoordinateReferenceSystem() > > But that does lead to another idea; we should treat the methods > described above in a manner similar to how name is handled: > > CONFLICT: > AttributeType.getName(): TypeName > AttributeType.getType(): > > RESOLUTION: > AttributeType.name(): String > AttributeType.getBinding(): Class > > CONFLICT: > FeatureType.getDefaultGeometry(): AttributeDescriptor > RESOLTION: > FeatureType.getDefaultGeometry(): GeometryAttributeType (fixed with Java > 5 type narrowing) > > CONFLICT: > Feature.getDefaultGeometry(): GeometryAttribute > Feature.getBounds(): Extent > > RESOLUTION: > org.geotools.feature.Feature.defaultGeometry(): Geometry (with Java5 > type narrowing) > org.geotools.feature.Feature.getBounds(): ReferencedEnvelope (with Java > 5 type narrowing) > > Where ReferencedEnvelope is a JTS Envelope and also a GeoAPI extent. > > Some of the method names had already been defined here: > http://geoapi.sourceforge.net/pending/site/apidocs/org/opengis/feature/simple/SimpleFeature.html > > > When you are done with your naming Justin let me know and I will force > SimpleFeature to match. > Cheers, > Jody > >> I like getDefaultGeometry as well - there was no concept of a default >> geometry in the ISO specifications; the concept is kept around just to >> keep us in the GeoTools community happy. The difficult is that we need >> the thing to return an Object (so we can work with ISO Geometry or JTS >> Geometry). >> >> If we move 2.5.x to Java 5 as planned we can use type narrowing - and >> thus keep the getDefaultGeometry name. >> >> Thoughts, >> Jody >> >>> Justin Deoliveira ha scritto: >>> >>>> I am actually thinking... I could work on a branch.. but i need to do >>>> the major api work on trunk (there will be a few major refactors) >>>> However, it will involve changing method names, which means i should >>>> probably deprecate them before we branch 2.4. >>>> >>>> OK, i think i will update the proposal slightly and schedule part of >>>> this task: >>>> >>>> http://jira.codehaus.org/browse/GEOT-1365 >>>> >>>> Against 2.4.x. Basically add the new methods without removing the old >>>> ones, but still do the major refactoring to update the codebase to use >>>> the new methods. >>>> >>>> So... in the short term i need to get agreement on the method name >>>> changes proposed in the above task. >>>> >>> I don' have anything against, thought I find getGeometryDefault odd, >>> and like getDefaultGeometry better (but if it's the GeoAPI name, well, >>> what can I do?). >>> >>> Cheers >>> Andrea >>> >> >> >> ------------------------------------------------------------------------- >> 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 >> > > > !DSPAM:4007,46855001224351637810514! > -- 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
