Sunburned Surveyor wrote: > I still think you could encapsulate this functionality in a plug-in or > set of plug-ins. This might not be the best way to go long term, but > it could let us test out how things would work without messing with > the core. > > For example, I wouldn't even mess with the Layer List. I'd create a > separate UI component that could be used to manage non-spatial feature > collections or tables. We could make it look similar to the Layer List > for purposes of consistency. I think it would be a little confusing to > include symbols for non-spatial feature collections in the Layer List. > They wouldn't affect the display order for one thing, and we currently > use the visual arrangement of layers in the Layer List to do this. > Good idea - this is probably a better way to do this. (Actually, my original concept for JUMP was that there would be a Catalog concept, with a UI which showed all the spatial tables which were loaded and exposed as Layers in Task map views. Non-spatial tables would have just shown up in the Catalog window. Ideally you could drag'n'drop layers to Layer Lists... this will sound familiar to ArcGIS users 8^)
> I imagined a plug-in that created a "Non-Spatial Feature" menu entry > somewhere. This menu entry would pull up a UI that would allow the > user to create, delete, modify, and import/export non-spatial feature > collections. > Or, you could use the current Load/Save Dataset dialog, but some Readers would create non-spatial tables which would appear in the Table View (Catalog) > Another related plug-in could be used to create associations between > non-spatial feature collections and spatial feature collections. I > think most of this functionality could be managed internally by the > plug-in. > Sure, this could just be extra menu items somewhere, either on the main menu bar or in a Catalog-only menu. > These are just some ideas. :] > > I think one danger of walking down the "non-spatial" feature path is > that we will begin to implement more and more traditional RDBMS > features. (For example: "Let's ass support for transactions to our > non-spatial feature collections."..."Let's add support for custom > datatypes to our non-spatial feature collections."..."Let's add > support for datatype constraints to our non-spatial feature > collections.") Perhaps the smart thing to do is to design a system for > non-spatial features that uses an embedded Java database that already > contains all of this functionality. I wouldn't have a problem with > this if we could access the database components directly without > having to mess with a JDBC layer. (Note: I'm not talking about storing > the attribute information for spatial features in an embedded > database. I think the Sigle team is already working on something like > this. I'm talking about storing the attributes of non-spatial > features. > > Then again, maybe it wouldn't be a big deal to implement some RDBMS > features if we have support for non-spatial features in OpenJUMP. It > just seems like a waste of effort with all the work that must be going > on in open source Java databases. > We certainly don't want to re-invent the wheel, but there is a set of functionality which *has* to be in JUMP, since it isn't provided by any DB. This includes: - the UI components - single Feature model which is general enough to support both spatial and non-spatial tables/hierarchies - probably I/O drivers for some non-spatial formats AFAIK there's no way around building a model which replicates quite a bit of the model in an RDB. This is because JUMP cannot be tied to any one DB model - it needs to be more general if it is going to support more than one data source. I was going to say that transactions at least should be left to the DB, but even then JUMP has to have a certain awareness of transactions (e.g. marking modified Features as dirty). (The ACID properties are best left to an underlying DB, however) GeoTools has already trodden this path well... Check out their design if you want to see just how much a general-purpose framework has to include. > Michael wrote: "And what about having a way to join a spatial layer in OJ to a > non-spatial db table or view, and to see the whole result as one flat > layer in OJ..." > > Good idea... > > Martin wrote: "Yes, definitely that would be cool. This would be > equivalent to a > defining a view in an RDBMS." > > See! That is what I was talking about. :] > > SS > > ------------------------------------------------------------------------- > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
