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
