Christopher, This was a good thread topic, and you did a nice job in outlining our options. My personal vote is also for Option 3. This option would fit the best into my personal use of OpenJUMP, and I agree it would be the simplest to implement.
In order to be truly useful, it might make sense to have a tool that allows one to create a H2 database with the required tables from something like a Shapefile. If we go very far fown this path it might be worth coordinating with the folks at GeoTools. We could end up with a shared database storage format for layers and features built on H2. I can help with this coordination if it becomes important as we move forward. The Sunburned Surveyor On Wed, May 27, 2009 at 1:31 AM, Paolo Rizzi <g...@oicom.com> wrote: > Option 1 is intriguing, because it would be a very good mean of > exchanging geo data, a single file with everything inside, very good!!! > Maybe an ibrid solution were the project is itself store inside the H2 > database, while each Layer can be internal or external would be even > better. Also you could store inside the H2 project both a Layer data and > a reference to its original provenience, to support some form of > disconnected editing, but this is maybe too sophysticated... > > Option number 2 would be just a shortcut upon number 3, a different UI > to select a database table, so it doesn't seems interesting. > > Option number 3 is good enough, but remember that DataStores are > read-only, so this would be a very good time to extend them to support > writing. > There were a couple of threads a few weeks ago about this and about > tracking modifications inside features. > The main goal was to be able to incrementally commit changes to a DataStore. > A simpler solution, but good enough for a start, would be to only > support complete Layer write inside a DataStore. > That is, always re-write the entire Layer each time, just like you would > do with a shape file. > Problem is with DataStores you don't have the entire Layer in memory. > So, to support this complete re-write, you should read the entire Layer > in memory, truncate the database table and recreate it. But this is > quite a dangerous solution, because if OJ crashes for any reason, you > loose your database data, unless you made good use of RDBMS transactions. > Another solution would be to create a new table inside the database > where you can merge the old table with the modified features you have in > memory, but this would not be very different from doing incremental writes. > Summing it up, it seems that supporting incremental writes for DataStore > is indeed needed anyway. > > Bye > Paolo > > >> What direction(s) does the community want me to go toward with regards to >> integrating the H2 database into OpenJUMP? >> >> Here's some initial options I've come up with: >> >> 1) Project as a database: >> When creating or saving a new project, you could select to make it a >> database project. Then all layers that are created are automatically saved >> into the database and when external layers are opened, the option for >> copying them into the database or leaving them external is given. To open a >> database project, simply open the associated H2 database. >> With this option, all project data can be stored in one file that can easily >> be moved around. >> >> 2) Database as a file folder: >> This is in the ArcMap style where the open file menu and save layer menus >> treats the database as simply another folder that you can navigate into and >> select individual files. >> >> 3 Database as a Data Store Layer: >> Use that Open Data Store and Connection Manager dialogues to manage opening >> and saving of layers. This would probably be the simplest to code with the >> least amount of core modification (if any), but I'm not sure that it would >> be as intuitive and invisible as it could be. >> >> Any comments or other suggestions? >> >> --Christopher >> >> >> >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
