I thought I would start a new thread so we could split this apart from the discussion that Paul and Martin were having about the FeatureInfo tool.
When I suggested that support for non-spatial features could be included in a plug-in Martin wrote: "I had similar thoughts a while back. In fact, the Feature concept easily supports non-spatial features. About all that is required is to get the UI to recognize non-spatial Feature Schemas and do sensible things with them (such as display a little table icon rather than the symbology icon in the Layer List panel, and not display the button for View/Edit Geometry). There's quite a few of these kinds of changes required to support this cleanly, but I don't think any of them are very difficult. This is more than just a single plugin, tho - it's a more of a generalization of the existing Feature framework." 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. 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. 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. 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. 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
