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
