It feels hacky, but many people are just using JTS as a holding area for geometry, not necessarily for the operations. So an implementation could be phased in slowly.
1 - Curves exist, but all the operations get stubbed out to the existing algorithms by stroking the curve 2 - Slowly over time, replace the operations with correct ones "We support Curves poorly" is actually a better story than "we don't support Curves". P. On Thu, May 8, 2008 at 9:56 AM, Martin Davis <[EMAIL PROTECTED]> wrote: > 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 >>>> >>>> >>> >>> -- >>> Martin Davis >>> Senior Technical Architect >>> Refractions Research, Inc. >>> (250) 383-3022 >>> >>> _______________________________________________ >>> jts-devel mailing list >>> [email protected] >>> http://lists.refractions.net/mailman/listinfo/jts-devel >>> >>> >> >> _______________________________________________ >> jts-devel mailing list >> [email protected] >> http://lists.refractions.net/mailman/listinfo/jts-devel >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > _______________________________________________ > jts-devel mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jts-devel > _______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
