Martin wrote: "...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 like this idea of managing non-spatial features in a catalog as well. Martin wrote: "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)" This is a good idea as well. Why have a separate UI component to load data sources? (But if we tried to modify the existing datasources dialog we might not be able to use a plug-in. I'll have to think about this one.) Martin wrote: "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 we used an embedded Java database to store non-spatial features in an OpenJUMP plug-in I only see the need for JUMP to include one of the elements you mentioned in your list: The UI components. I think I am taking a different approach. I wouldn't modify the Feature model at all. Instead I would create a separate model, with NonSpatialFeature at the top of the model's class diamgram. I think this would allow us to avoid making a lot of other changes to OpenJUMP. The plug-in would be built to independently manage non-spatial features and to track the relationships, if any, between spatial features and non-spatial features. I also think a smart plug-in developer (not me) would be able to "hide" the embedded Java database from the end user while gaining a lot of the features offered by the embedded database. But then again, if you want simplicity forget the embedded database all together and just create the code to work with the non-spatial features directly. I have no time to work on this concept in the near future, but it is enlightening to have the discussions. :] Martin wrote: "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." I know we have a few GeoTools developers lurking on the list. Perhaps they will comment on this topic for me. (Then again, they may not be reading much of our list with all of the traffic lately.) The Sunburned Surveyor On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > > 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 > ------------------------------------------------------------------------- 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
