Sunburned Surveyor wrote: > Jody, > > I will have to read some of the documentation you highlighted and > revist this issue, as I still don't completely understand. This is a > struggle for me because I'm moving from a single monolithic > application (OpenJUMP) to a multi-part library (GeoTools). It doesn't > really make sense to have more than one envelope class in something > like OpenJUMP, but it appears it may make perfect sense in something > like GeoTools. > Ah; this is *exactly* the way to think about it; you are moving from a single application OpenJUMP where you can define how a Rectangle is represented. That is nice and consistent and easy to learn ;-)
For GeoTools we are a library that is going to be used: - by lots of different projects - integrated with lots of different libraries Our "mandate" is to help people make spatial applications; so: - if a person is building a Java application using Swing they are used to using the Java Rectangle; and can hardly imagine why we would not do the same? Well we have two reasons; we need to use doubles to represent our data, and we need to store a CoordinateReferenceSystem along with the bounds in order to know what the Rectangle "means". - if the user is integrating with a JTS application we have the RefernecedEnvelope class to help you out. This sounds like it is the only case you have considered? But even for OpenJUMP you break out Java2D Rectangles eventually when you draw on screen right? - And finally if you are making an ISO Geometry based application we have a GeneralEnvelope implementation that you can use. Hopefully thinking about the end users of the library explains why their are more than one "Rectangle" around? Different users have different needs... > I need to think about this some more. (Maybe tomorrow?) Then I may have more > questions. > Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
