I think the thread has not reached any conclusions yet. There are issues with both approaches to saving memory. More study is needed.
Regarding modifying Coordinate objects, we may be closing the barn door after the horses escaped. Larry On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > This seems like a really important post, and I regret coming into it so late. > > Sascha's idea about eliminating duplicate coordinate objects in large > polygon layers and linesting layers is interesting. I have some > questions for him on that, but I will put them in another thread so > things don't get so confusing. > > The other important topic I seemed to pick up in this thread deals > with the direct manipulation of Coordinate objects. It seems that > everyone agrees this is a bad idea. I just want to clarify this so > that I understand it correctly. > > When writing modifications and/or plug-ins for OpenJUMP we should > avoid the use of Coordinate objects directly. Instead we should try to > work with the actual Geometry instances. This is important because JTS > now allows the use of the CoordinateSequence class to represent > geometries as an alternative to Coordinate objects. > > I think we should put this information out for plug-in developers. > Maybe in "Plug-In Developer's Guide"? (Looks like I may have found my > documentation alternative.) > > What do you guys think? > > The Sunburned Surveyor > > On 6/25/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > 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 > > > > ------------------------------------------------------------------------- > 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
