I'm almost 100% sure that JUMP treats Coordinate objects as immutable (at least in the core code. I do know that at least one plugin I wrote changes the Coordinates in Geometries - my bad!). I think this should be a firm design principle of JUMP - it's simply not worth the risk to mutate Coordinates in-place. The same goes for Geometrys, I think. There's lots of benefits to having immutability, and lots of risks to not having it.
So your Coordinate-sharing idea should work. Whether this really makes much of an impact in the general use case I can't say - it's very dependent on the nature of the data being loaded. 50% savings doesn't seem like that much to me - but I guess that depends on whether you are trying to load a 2 GB shapefile! Perhaps this should be called Coordinate-externing, referring to the similar strategy that Java uses for String constants. Another possible option for providing memory savings is to take advantage of the JTS CoordinateSequence facility, and use PackedCoordinateSequences for raw Geometry storage. This might give an even bigger memory savings. But it would *definitely* require changes to the core, since JUMP was mostly written before the JTS CS was introduced, so the code assumes it can get down-and-dirty with the Coordinate arrays in JTS. Sascha L. Teichmann wrote: > Just for curiosity: > > When I load a larger polygon shapefile (burlulc) > I recognized that the geometries share a lot of > common vertices. In case of the burlulc layer > over 1,500,000. > They are represented by com.vividsolutions.jts.geom.Coordinate > objects. If a shapefile gets loaded a new Coordinate object > for each vertex is created. > > Now I added a simple TreeMap to the PolygonHandler of > OpenJUMP's shapefile reader to reuse already created > Coordinate objects and share them with other geometries. > > After loading the data (+ triggering GC) the normal OJ > uses approx. 124MB memory. After the the shared vertices > modification OJ uses only approx. 89MB. > > My question: May this mod lead to any side effects? > With JTS? With the CursorTools? > > Coordinate objects are not immutable, so I expect > side effects with e.g. neighboring polygons when > I edit one of them. > > I had a brief look at the code and played with > the CursorTools but I haven't found any side effects > yet. > > This idea comes from playing with OJ on a boring > friday evening. It only costs me a few seconds to > implement and if you say "This idea is plain stupid!" > I'll drop it immediately .. ;-) > > Kind regards, > Sascha > > ------------------------------------------------------------------------- > 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
