Hi, If the outcome of this thread is that writing GeoAPI wrappers for JTS is the best way forward, then I'll help you write them if you want.
I understand what you're looking for: >For example a class implementing the GeoAPI LineString interface, >which contains a JTS LineString as its unique field, and delegates all method call from the GeoAPI >interface to the corresponding JTS method. I gather that Bryce needs geoapi compliant geometeries quite urgently: > If I end up specifying Geometry for use within the Coverage > module, it's > going to consist of > "points-and-as-little-else-as-I-can-get-away-with". :) > But it'll be a start. I was thinking that if he made this start then I could copy the coding style used and start making wrappers for the other classes? colin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Bryce L Nordgren > Sent: 06 March 2006 19:59 > To: Martin Desruisseaux > Cc: geotools-devel > Subject: Re: [Geotools-devel] Looking for 19107 implementation > > > > Martin Desruisseaux <[EMAIL PROTECTED]> wrote > on 03/05/2006 > 12:29:40 AM: > > > I already though about it (and missed time, like usual). I would be > > very glad if someone else could > > begin to create this geometry module! > > If I end up specifying Geometry for use within the Coverage > module, it's > going to consist of > "points-and-as-little-else-as-I-can-get-away-with". :) > But it'll be a start. > > > As Dave point out, the geooxygen project may worth a look. But I > > don't know much about them. > > > My proposal (what I would have liked to do if I had time to start > > coding this geometry module) is to > > adapt JTS. More specifically, create the following package: > > > > org.geotools.geometry.jts > > Agreed. > > > Wrapping degree code would not have much interest for Geotools, > > since we don't use Degree geometry > > objects (by the way, I believe that Degree's API on the geometry > > part come from the early GeoAPI > > days, before the packages settle down). Wrapping JTS code (instead > > of adapting it) would provides a > > transition path between JTS-dependent code and GeoAPI-dependent > > code. This transition path is likely > > to be needed. > > This would seem to apply to all non-JTS code. I've looked at > some of the > suggestions so far. None of them implement GeoAPI. One of > them bears only > a superficial resemblance to 19107 (e.g., the classes have > the right names, > but most of the method names are "custom") Worse, none of > the suggestions > so far seems like a very active project. That alone scares me off. ;) > > > A limitation of JTS wrappers is that they would work only for > > geometries in a 2D cartesian space. We > > should make that clear in the documentation. However, it would be a > > valuable start. It would give us > > more time for looking alternative implementation in the future > > (geooxygene?), if we wish. > > Out of curiousity, does JTS work in a lat/lon space? > Mentally, I can't > picture it working with axes that aren't length units. > > > BTW- This should make our lives easier. ISO 19107 / OGC Abstract Spec > Topic 1: > "There are 39 comformance classes for application schemas > that instantiate > geometric or topological objects. They are differentiated on > the basis of > three criteria. The first two criteria determine the types > defined in this > schema that shall be implemented by an application schema > that conforms to > a given conformance option. The third criterion determines > the elements of > those types that shall be implemented. > > The first criterion is level of data complexity. Four levels are > identified: Geometric primitives, GeometricComplexes, Topological > complexes, Topological complexes with geometric realization. > > The second criterion is dimensionality. There are four > levels for simple > geometry: (0), (0 & 1), (0, 1, & 2), and (0, 1, 2, & 3) dimensional > objects. However, [0 dimensional is useless, so is omitted]. > > The third criterion is level of functional complexity. There > are three > levels: data types only, simple operations, complete operations." > > JTS probably covers ("2D, Complete Operations, geometric > primitives" and at > least "2D, simple operations, geometric complexes.") I have > to look closer > to see exactly what each one entails. The point is that we > can express our > "conformance level" in the terms laid out by the standard. > With 39 levels > to pick from, one of them should probably do the trick. > > > So my vote would be: Adapters around "official" JTS objects (not a > > rewrite of JTS). > > I don't mean to sound flattering, but I'm not nearly smart > enough to do > that. I'm only smart enough to swipe the code. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language > that extends applications into web and mobile media. Attend > the live webcast > and join the prime developer group breaking into this new > coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&; > dat=121642 > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
