Paul, If this is a question of modelling a single complex attribute which is in 1-1 relation with the parent feature, why don't you just present the attributes as a set of attributes on the parent feature? Granted this increases the column namespace a bit, but it doesn't require any additional functionality in the UI and seems like it should provide you with effectively the same capability to display the attributes.
If you want to support complex attributes which are in many-to-one relationship with a parent Feature set, that's a whole different story, and I think would require a lot more than just a change to the Attribute View presentation. By the way, how are you loading these compound Features? Paul Austin 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 > -- 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
