Thank you, Landon!
An excellent summary of why adding curves to JTS is non-trivial.
The assumption of linearity pervades the entire JTS codebase, including
the API definition and semantics. Even extending the API to include
curves would be a major undertaking. It might just be better to pitch in
on the GeoAPI project, which at least has a well-modelled API to work from.
Another issue is: what sort of curves? This seems to me to be an
unrewarding treadmill to get onto - everyone's going to want a slightly
different definition of curve.
Sunburned Surveyor wrote:
Paul wrote: ""We support Curves poorly" is actually a better story
than "we don't
support Curves".
I think I may respectfully disagree with this statement. After
thinking about this problem for the last day or two I really think it
would be better to approach curve support in JTS on a case-by-case
basis. I really believe there are only two ways to properly add
support for curves to JTS:
[1] Do a complete overhaul of the library to properly add curve support.
[2] Implement specific solutions to curve support for specific problems.
Let me give you an example of the second item listed. I became
interested in adding some form of support for curves to JTS because I
wanted to model circular arcs and spiral curves used in route
alingments. I wanted to use JTS for my route stationing library, but I
needed to calculate the true length of curves in some circumstances.
The solution I design for this may not be the same as a solution
designed for the problem of displaying horizontal curves in OpenJUMP,
or for calculating the areas of parcel polygons with curves as part of
their boundaries. Each of these three "curve problems" may call for a
different type of solution.
Given the complexity that curves could add to the library, and the
different circumstances in which the needs for curves might arise, I
would say leave the support for curves up to individual programmers
that need them.
Having said that, I don't see why we couldn't come up with a set of
interfaces and classes to represent basic types of 2D curves and
classes that convert/control interaction between JTS and these
geometries, but I don't think they should be included without a major
overhaul.
One must also remember that the ESRI shapefile is still the major GIS
data file format in use today, and as far as I know it still doesn't
support true curves! So adding curve support to JTS may not have that
great of a benefit to a lot of the end users of GIS programs that tap
into JTS.
We could, of course, be having the same argument about adding 3D
solids to JTS. Sure, it could be done, but is it worth the complexity?
Why not have a separate library that allowed you to generate 2D JTS
geometries from 3D objects, or to extrude 3D objects from 2D JTS
geometries. This would be cool, but I don't think the functionality
would belong as a main part of the JTS library either. I think the
same principle applies to 2D curves.
Landon
On Fri, May 9, 2008 at 8:39 AM, Sunburned Surveyor
<[EMAIL PROTECTED]> wrote:
I took a quick look at the javadoc for the LineString class. I noted
the following methods that may present problems for a LineString
subclass used to represent a curve:
getCoordinate
getCoordinateN
getCoordinates
getCoordinateSequence
getNumPoints
getPointN
getStartPoint
isCoordinate
reverse
Although it may be possible to override these methods to provide
behavior that would be logical for a curve, I don't think this would
be the behavior expected by many of the methods in JTS. So in essence,
this technique would be a hack. :]
This doesn't mean it won't work for Ronan.
Ever since I bought and read the book "Effective Java" I've become a
lot more cautious about subclassing a class that isn't abstract. This
follows the principle described in Item 15 of the book: "Design and
document for inheritance or else prohibit it."
I don't think the LineString class was really designed to be
subclassed. You can subclass it of course, but you will inevitably
break something because the rest of the library wasn't designed for
the behavior of the subclasses.
Landon
On Fri, May 9, 2008 at 7:31 AM, Ronan Crowley <[EMAIL PROTECTED]> wrote:
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
_______________________________________________
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
