Re: JTS/CursorTool side effects with shared vertices from shapefile?

Larry,

You wrote: "I think the thread has not reached any conclusions yet.
There are issues with both approaches to saving memory.  More study is
needed."


I'm sorry if I confused things. I didn't say we should implement
Sascha's idea, just that I thought it was interesting. :]

Larry wrote: "Regarding modifying Coordinate objects, we may be closing the barn
door after the horses escaped."

This is true. I'm just saying we could close the barn before the cows
get out to. It never hurts to get a handle on something from the
current point in time on into the future. I wasn't suggesting we fix
legacy code, just try to avoid the problem in new code.

The Sunburned Surveyor


On 6/26/07, Larry Becker <becker.larry@xxxxxxxxx> wrote:
> 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 <sunburned.surveyor@xxxxxxxxx> 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 <mbdavis@xxxxxxxxxxxxxxx> 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 <mbdavis@xxxxxxxxxxxxxxx> 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 <becker.larry@xxxxxxxxx> 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 <becker.larry@xxxxxxxxx> 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 <mbdavis@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> > > >>>>>> 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@xxxxxxxxxxxxxxxxxxxxx
> > > >> 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@xxxxxxxxxxxxxxxxxxxxx
> > > 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@xxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxx
> 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/