Hi All, Thanks for all the replies guys, (sorry for not replying sooner, since I get the mails in digest form)
What I was considering implementing was quite similar to what was discussed. Subclassing LineString and creating a Curve class represented by just three points. The create a "linearize" method which would take the curve and split it up into a 120 part LineString. Then for each of the buffer, intersects, distance, etc... operations, just call this linearize method first and then proceed as normal. I don't really agree that this is a "hack" as I believe this is how Oracle itself uses this methodology in some cases. A Circle implementation would be almost identical too, I would expect to have most difficulty with the CompoundPolygon (Polygon made up of LinesStrings and Arc's) Ronan 2008/5/8 <[EMAIL PROTECTED]>: > From: Martin Davis <[EMAIL PROTECTED]> > To: JTS Topology Suite Development <[email protected]> > Date: Thu, 08 May 2008 09:56:08 -0700 > Subject: Re: [jts-devel] Extending JTS for Arc Support > Um, maybe... the issue isn't so much adding a new Geometry subtype, as > getting all the existing code in JTS to support it. Unfortunately there's > an awful lot of "instanceof" sprinkled throughout the codebase. > > Maybe one way to do this really transparently would be to subclass > LineString (and maybe LinearRing) with something which allowed curved > sections of the geometry, but would report them as approximated linestrings > for all existing Geometry operations. This feels like a bit of hack, > however - not sure I want to spend any time on a solution which is going to > be very ugly. However, if there's some simple stuff that needs doing to > allow Geometry subclasses to be supported, this would be of interest. > > Sunburned Surveyor wrote: > >> Martin, >> >> Could we make a subclass of Geometry that represented Curves, but that >> provided a linear approximation for most JTS operations? >> >> I think this would be a more elegant solution than the one I currently >> fiddling around with. It would take some work to make my Curve >> interface a subclass of Geometry, but I think it can be done. >> >> If I have time I'll look at the Geometry class today to see if there >> are any methods that would cause real problems in this scenario. >> >> Landon >> >> On Thu, May 8, 2008 at 8:55 AM, Martin Davis <[EMAIL PROTECTED]> >> wrote: >> >> >>> Jody and SS have given pretty good answers to your questions. Basically, >>> curves are hard, and I don't think I can give them the time it would take >>> to >>> make an implementation I'd be happy with. That's the reason I haven't >>> moved >>> to add them to JTS. >>> >>> I guess the ideal direction would be to develop curve support as a >>> separate >>> library, that was integrated with JTS at some level. The ideal level >>> would >>> be for curves to be subclasses of Geometry, and thus be first-class >>> citizens. I'm not sure how feasible this is. I'd be interested in >>> talking >>> about how JTS could be refactored/enhanced to support this kind of >>> approach. >>> >>> Otherwise, pitch in with an existing project (Sunburned's or GeoTools) >>> and >>> have at 'er. >>> Ronan Crowley wrote: >>> >>> >>>> Hi, >>>> >>>> I'm currently using Oracle Spatial for storage of spatial data and >>>> therefore using Oracle's JGeometry class (sdoapi library) to represent >>>> Geometry's in Java. >>>> I use the JTS library for some extra calculations, and so have written >>>> conversion methods to convert between the API's. >>>> >>>> However, there is no support in JTS for the special extra geometry types >>>> that Oracle spatial supports, such as Arc, Circle and Compound Polygon. >>>> >>>> So, if I wanted to decouple my application from the JGeometry library >>>> I'd >>>> have to extend the JTS library (& JTSIO) to include these extra geometry >>>> types. >>>> >>>> My questions are: >>>> 1) Are there any existing plans to carry out this work? >>>> 2) Has anyone else attempted if before? >>>> 3) Are there many potential pitfalls for these extra geometry types >>>> support (i.e. intersection, buffer and other operations) ? >>>> 4) Were I to do it would it be something that would be desirable the >>>> library? >>>> >>>> Cheers, >>>> Ronan >>> >>>
_______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
