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 > -- http://amusingprogrammer.blogspot.com/ ------------------------------------------------------------------------- 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
