My answer is a confident "I think so" - as long as there's no JUMP function which relies on mutating Coordinates to work correctly. AFAIK this should be the case - but it's been a long time and many code changes since I've been really close to the code.
I think the right design to use here is to define a global GeometryFactory used by JUMP. This needs to be passed into or used in all places where Geometry is created. That factory will then control what CoordinateSequence representation will be used. Larry Becker wrote: > Hi Martin. Correct me if I'm wrong, but if we implemented use of > CoordinateSequences piecemeal driver-by-driver, starting with > ShapeFile, wouldn't everything continue to function normally in JUMP? > Wouldn't JTS hide the internal representation from us? > > thanks, > Larry > > On 6/25/07, Martin Davis <[EMAIL PROTECTED]> wrote: > >> Unfortunately JTS isn't completely ported to use CoordinateSequences >> only. But this should be mostly an internal issue. If you're using any >> method which doesn't explicitly take a Coordinate[] you're safe (for >> instance, all the methods on Geometry will work fine). If you're doing >> low-level stuff and using some of the utility classes which still take >> Coordinate arrays, then of course you need to provide a Coordinate array >> as input. >> >> The direct ordinate access and the various mutators (such as >> LineSegment.setCoordinates) are provided for the benefit of algorithm >> writers who want to maximise the internal performance of their code (for >> instance, LineSegments are useful as containers to pass data around in >> internal calls and datastructures). But plugin authors & algorithm >> designers should be careful that ultimately they don't modify input data >> (which implies they need to create new objects for whatever output they >> are creating). >> >> Larry Becker wrote: >> >>> Yes, and I was right about being guilty too. The ISA tools are full >>> of ".x =" assignments. >>> >>> Martin, does all of JTS support the JTS CoordinateSequence, or do you >>> need to convert to Coordinate arrays before calling JTS functions? I >>> see, for example, that there are LineString constructors for both >>> CoordinateSequence and Coordinate points[], so I would guess that when >>> Geometry functions are invoked later, they will detect and use the >>> correct access method? If so, it would make a 25% savings for each >>> Coordinate since there is an 8 byte overhead for the object. >>> >>> thanks, >>> Larry >>> >>> >>> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Oh, oh. If com.vividsolutions.jts.geom.LineSegment.setCoordinates() >>>> is any indication, JTS is probably going to prevent making this >>>> policy retroactive. There seem to be several places where Coordinate >>>> values are passed into methods and have their x,y values modified. >>>> >>>> regards, >>>> Larry >>>> >>>> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> I agree with Martin. Modifying Coordinate values in-place is probably >>>>> a bad idea, however I'm pretty sure I've been guilty. What I'm trying >>>>> to figure out now, is a good way to find out where and how many times. >>>>> >>>>> regards, >>>>> Larry Becker >>>>> >>>>> On 6/25/07, Martin Davis <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>> Michaël Michaud wrote: >>>>>> >>>>>> >>>>>>> @Martin : Please, can you explain what immutability means for >>>>>>> coordinates. I see that x,y,z are public fields (and I remember I often >>>>>>> changed them via small scripts, especially the z value). But may be I >>>>>>> have no clear idea about immutability and its advantages. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Well, it's pretty simple. If you have a tool that works by altering the >>>>>> ordinate values in a Coordinate, and you are using the "interned >>>>>> Coordinate" strategy, you are going to get bugs, since Geometrys will >>>>>> change unexpectedly when their shared Coordinate values are changed by >>>>>> someone else. >>>>>> >>>>>> The public x,y,z in Coordinate were originally there for efficiency >>>>>> reasons. Probably a bad idea. In fact, Coordinate should have simply >>>>>> been an interface. But too late to change now! However, an application >>>>>> like JUMP should make it a blanket policy that Coordinate values should >>>>>> never by changed. Any other policy leads to insanity, IMO. >>>>>> >>>>>> HTH - Martin >>>>>> >>>>>> -- >>>>>> Martin Davis >>>>>> Senior Technical Architect >>>>>> Refractions Research, Inc. >>>>>> (250) 383-3022 >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by DB2 Express >>>>>> Download DB2 Express C - the FREE version of DB2 express and take >>>>>> control of your XML. No limits. Just data. Click to get it now. >>>>>> http://sourceforge.net/powerbar/db2/ >>>>>> _______________________________________________ >>>>>> Jump-pilot-devel mailing list >>>>>> Jump-pilot-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> http://amusingprogrammer.blogspot.com/ >>>>> >>>>> >>>>> >>>> -- >>>> http://amusingprogrammer.blogspot.com/ >>>> >>>> >>>> >>> >>> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
