Support for non-spatial DB tables would be a _great_ thing!!! You can do lots of thing with them (use attributes to theming other layers), or you can even create geometries on the fly using some of their attributes plus some BeanShell code, for example. Or they can be used to edit geometric layers (maybe they're ENUMs tables needed to decode things, ZIP for example).
Bye Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Martin Davis > Inviato: sabato 2 giugno 2007 0.36 > A: List for discussion of JPP development and use. > Oggetto: Re: [JPP-Devel] FeatureInfo table on steroids > > > 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. We'd also > need a few non-spatial I/O drivers - CSV, text, maybe DBF. > And also a > way to set up joins between tables (this one is harder, I > think). This > is more than just a single plugin, tho - it's a more of a > generalization > of the existing Feature framework. > > As for the listener idea, if I understood what Paul was > wanting it would > be more like supporting adding an item to the existing popup > menu on the > Feature Info attribute table. > > Sunburned Surveyor wrote: > > I'm not sure I totally understand what Paul is talking about, but I > > had a comment or two and I wanted to throw an idea out there. > > > > Paul wrote: " A right click on the feature row to view the whole > > feature and have a view/edit feature frame that would > display the list > > of property names and values with nested panels for each nested > > feature." > > > > I like this idea. > > > > I have also thought about the issue that Paul highlighted in his > > example of the building address. For example, I might want to store > > information about the most recently recorded deed for a parcel. The > > problem with this is that there might be multiple items I'd like to > > know about the deed. (Date of Purchase, Date Recorded, Recording > > Number...) > > > > I had thought about solving this problem with a plug-in that would > > allows us to store "non-spatial" features. We could use something > > similar to the exixting Feature interface. The main difference would > > be that a non-spatial feature would not have a geometry associated > > with it. I think we could even display the non-spatial > features using > > the same attribute table that we currently use for spatial features, > > with some changes. (You could think of a non-spatial feature > > collection as a table in a typical RDBMS.) > > > > This might be a simple alternative to embedding a database. I've > > always thought using an embedded database added an > additional layer of > > complexity to OpenJUMP. I suppose as we consider more and > more advance > > functionality for attribute information an embedded database option > > becomes more attractive. Still, it is something to consider > carefully. > > One of the things that makes OpenJUMP so beautiful is its > simplicity. > > :] > > > > I also wonder if we could accomodate some custom attribute table > > behavior by creating a "listener" system similar to what > was done with > > the CursorTools. Plug-In developers would be able to add > listeners to > > each attribute table. When a mouse interaction was detected we could > > forward an event to the registered listeners that contained a > > reference to the feature and attribute over which the mouse pointer > > was located when the event occured. > > > > In this type of system Paul could create a listener and attach it to > > the attribute table with the address field. In this address field he > > would store a primary key. When the user held the mouse pointer over > > this address field an event would be sent to the listener with a > > reference to the feature and the primary key stored in the address > > field. He could then display a GUI with all of the information from > > the address that he retrieves using the primary key stored in the > > event. > > > > Perhaps this is what Paul was talking about and I didn't > understand completely. > > > > The Sunburned Surveyor > > > > > > > > > > On 6/1/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > > >> Hi Martin, > >> > >> This case is where you have nested complex properties of > an attribute > >> nature. For example building may have an address property > that has the > >> attributes unit, number, street, city etc. > >> > >> I don't want to go down the whole nested feature > collection route as that > >> can get pretty messy. In fact I would typically model > these in the database > >> using either one-to-may or many-to-many foreign key > relationships that they > >> really are. > >> > >> For the code table plug-in, this could be done from > database layers by > >> following foreign key relationships that when you add the > layer you could > >> select which ones are code tables and the columns to use > from the referenced > >> tables. Initially I think I'd test out the concept by > manually creating the > >> UI and config and see how it goes from there. More of a prototyping > >> approach. > >> > >> Paul > >> > >> > >> Martin Davis wrote: > >> Is your use case only for a property which contains a > single Feature? > >> > > The > > > >> general case would be to have a property which contains a > >> > > FeatureCollection > > > >> (this is the full GML model, for instance). In this > >> > > case the UI gets a bit > > > >> more complicated. > >> > > > > How are you creating the Feature property? Do you need to > > > >> spatially > >> > > visualize it? > > > > I'm asking these questions because while your use > > > >> case may simply be to > >> > > view a single Feature property, it's nice to look a > > > >> bit further down the > >> > > road at a more general design, in order to avoid > > > >> making the > >> > > implementation overly specific and hard to extend. > > > > In general > > > >> supporting a hierarchical feature model introduces tons of > >> > > issues all > > > >> through JUMP... which is why we didn't go there at first. > >> > > The closest we > > > >> got was to support a custom object hierarchy and expose > >> > > different classes > > > >> of it as separate FeatureCollections. This allowed > >> > > treating the various > > > >> classes as map layers, which worked pretty well. > >> > > But this was all custom > > > >> code and hard to make general-purpose. > >> > > > > As for the code-value entry plugin, > > > >> the general concept would clearly be > >> > > nice to have. Would your entry screen > > > >> only support that single > >> > > attribute, or would you make a general entry panel > > > >> which showed all > >> > > attributes? This was talked about a week or two ago - it > > > >> would be nice > >> > > to have this as another view in the Attribute View window. > > > >> How would > >> > > you supply the code-value mapping? > > > > Paul Austin wrote: > > > > > >> I have a data set where a property of a feature is another feature > >> > > object. > > > >> In the schema it has the type Object but it's actually a > >> > > Feature > > > >> instance.What I would like to do is have the following. > >> > > > > 1. A right click > > > >> on the feature row to view the whole feature and > >> > > have a view/edit feature > > > >> frame that would display the list of > >> > > property names and values with nested > > > >> panels for each nested > >> > > feature. > > 2. Use the feature display panel to > > > >> display the feature on say roll > >> > > over of a complex property value > > > > Has > > > >> anyone worked on such a feature? If not I'll start writing one. > >> > > > > Also I was > > > >> thinking that in databases you have the concept of code > >> > > lookup tables, I > > > >> was thinking of a plugi-in that you can configure to > >> > > display the code value > > > >> instead of the code ID and have a drop down for > >> > > changing the values instead > > > >> of entering the > >> codes. > >> > > > > Paul > > > -------------------------------------------------------------- > ---------- > > > > > -------------------------------------------------------------- > ----------- > > 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 > >> > > Jump-pilot-devel@lists.sourceforge.net > > 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 > >> Jump-pilot-devel@lists.sourceforge.net > >> 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 > > Jump-pilot-devel@lists.sourceforge.net > > 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 > Jump-pilot-devel@lists.sourceforge.net > 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 Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
