I had already planned some sort of in-OJ, simplified, seamless, database management. That is what integration means to me. At the very beginning, it will probably just be a collection of menu items, then be expanded to include the context menus of layers, and, if I get to project-as-database, most everything will be done automagically in the background. A user shouldn't have to know anything about databases in order to use a local spatial database within OJ.
--Christopher --- On Wed, 5/27/09, Sunburned Surveyor <sunburned.surve...@gmail.com> wrote: > From: Sunburned Surveyor <sunburned.surve...@gmail.com> > Subject: Re: [JPP-Devel] UI direction for native database integration > To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net> > Date: Wednesday, May 27, 2009, 7:38 AM > 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 > ------------------------------------------------------------------------------ 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
