Re: [JPP-Devel] FeatureInfo table on steroids
Hi Martin, I'm just working on a concept of a HtmlRenderer that will take an object and convert it to HTML for display in Swing HTML widgets. There will then be a HtmlRendererRegistry that will map from a Java Class to a renderer. When displayign features you would use the registry to get a renderer for an object and use this to generate the HTML. We could then extend this concept for things like geometry where the user can via the UI choose between a choice of renderers for that class (e.g. WKT, GML), those plug-ins would switch on the fly the renderer in the registry. The registry should also support the property change listener so that UI's can refresh themselves if the registry changes. Paul Martin Davis wrote: Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. As for the compound Feature idea, this seems to depend on having Readers which can actually create these things. It sounds like you have defined a custom reader for your need. I would be reluctant to build very much functionality for compound Features into the core until there is a clearer idea about the general use cases for them, and what would be required to make them usable throughout JUMP. For now hopefully adding some hooks to extend the FeatureInfoTable view will meet your need. BTW, the idea of having hum-readable names for FeatureSchemas is a nice one. I'd definitely support adding that functionality, even if it isn't exposed right now. More generally, this is all moving in the direction of supporting a full GML-like data model, where Features can contain FeatureCollections as attributes. I think deegree might have already extended JUMP to accomodate this - it would be nice to hear from them how well this worked and what they had to do to make it work. I think there might be some big UI challenges in accomodating a hierarchical Feature model, but it might be worth building the infrastructure (i.e. enhancing the feature package), and then gradually enhancing the UI to expose more and more of it. It should be possible to provide sensible default UI behaviour wherever necessary. Paul Austin wrote: All, I have attached a screen shot of my new Feature InfoTable implementation. As you can see I've added some CSS styling to the table and where there are "nested" feature types have the feature type name displayed and a nested table with their attributes. NOTE: The sub feature type name stuff won't work with regular JUMP features as the FeatureSchema does not include the feature type name. I'm using my own Feature implementation based on the model used in my reader framework. It would be simple to add this to FeatureSchema if required. After looking at the current implementation I would like to suggest a change to the way the who feature info table view works. 1. Under the view menu have sub menu to allow the user to select the style for viewing geometry (WKT, EWKT, CL, GML) in addition to the current approach and save that so the user always get their preference. 2. Implement a FeatureInfoTable renderer which defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format 3. Roll the FID and geometry attribute into the table FeatureInfoTable renderer so that the geometry render is just used when geometry values are detected to display the value portion. So for example there would be a position row in the table that would have the geometry formatted as WKT or GML 4. Where multiple records are displayed use a database style paging display where one feature is displayed at a time but you have back/forward, first/last and jump to record number. Think MSAccess or FME style paging through selected features. Any comments/suggestions? 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
Re: [JPP-Devel] FeatureInfo table on steroids
Martin, You wrote: Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. Are you and Paul just talking about a way to allow custom rendering of a selected feature's attributes in the FeatureInfo tool? (For example, if the attribute was the full path to an image, the image could be rendered instead of the actual text value contained in the attribute.) Or are you guys talking about something else entirely? The Sunburned Surveyor On 6/4/07, Paul Austin [EMAIL PROTECTED] wrote: Hi Martin, I'm just working on a concept of a HtmlRenderer that will take an object and convert it to HTML for display in Swing HTML widgets. There will then be a HtmlRendererRegistry that will map from a Java Class to a renderer. When displayign features you would use the registry to get a renderer for an object and use this to generate the HTML. We could then extend this concept for things like geometry where the user can via the UI choose between a choice of renderers for that class (e.g. WKT, GML), those plug-ins would switch on the fly the renderer in the registry. The registry should also support the property change listener so that UI's can refresh themselves if the registry changes. Paul Martin Davis wrote: Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. As for the compound Feature idea, this seems to depend on having Readers which can actually create these things. It sounds like you have defined a custom reader for your need. I would be reluctant to build very much functionality for compound Features into the core until there is a clearer idea about the general use cases for them, and what would be required to make them usable throughout JUMP. For now hopefully adding some hooks to extend the FeatureInfoTable view will meet your need. BTW, the idea of having hum-readable names for FeatureSchemas is a nice one. I'd definitely support adding that functionality, even if it isn't exposed right now. More generally, this is all moving in the direction of supporting a full GML-like data model, where Features can contain FeatureCollections as attributes. I think deegree might have already extended JUMP to accomodate this - it would be nice to hear from them how well this worked and what they had to do to make it work. I think there might be some big UI challenges in accomodating a hierarchical Feature model, but it might be worth building the infrastructure (i.e. enhancing the feature package), and then gradually enhancing the UI to expose more and more of it. It should be possible to provide sensible default UI behaviour wherever necessary. Paul Austin wrote: All, I have attached a screen shot of my new Feature InfoTable implementation. As you can see I've added some CSS styling to the table and where there are nested feature types have the feature type name displayed and a nested table with their attributes. NOTE: The sub feature type name stuff won't work with regular JUMP features as the FeatureSchema does not include the feature type name. I'm using my own Feature implementation based on the model used in my reader framework. It would be simple to add this to FeatureSchema if required. After looking at the current implementation I would like to suggest a change to the way the who feature info table view works. 1. Under the view menu have sub menu to allow the user to select the style for viewing geometry (WKT, EWKT, CL, GML) in addition to the current approach and save that so the user always get their preference. 2. Implement a FeatureInfoTable renderer which defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format 3. Roll the FID and geometry attribute into the table FeatureInfoTable renderer so that the geometry render is just used when geometry values are detected to display the value portion. So for example there would be a position row in the table that would have the geometry formatted as WKT or GML 4. Where multiple records are displayed use a database style paging display where one feature is displayed at a time but you have back/forward, first/last and jump to record number. Think MSAccess or FME style paging through selected features. Any comments/suggestions? Paul Martin Davis wrote: Is your use case only for a property which contains a single Feature? The general case would be
Re: [JPP-Devel] FeatureInfo table on steroids
Ok, sounds cool. One slight clarification/comment - I don't think you want to switch on the fly the renderers in the registry. The whole idea behind the Registry is that it is a pretty much static container of components (or Strategy objects). Registry items can be added (by plugins or on startup) but they should never be deleted or modified after that. If you are looking for a single overall JUMP-wide preference for which text renderer to use for a given class, then how about making a TextRendererPreferences class with a singleton instance, and keep the users current preferences in that. (This should probably be generalized to an overall UserPreferences class which keeps track of everything a user wants to configure). Whether the text rendering for every class (or even just Geometry) should be controlled by a single user preference I'm not sure sure. My usage pattern is more that I want to be able to switch between different text renderings in whatever window or tool I'm currently looking at. Some tools need to be able to parse the text representation back in (such as the Geometry Edit view), so they will impose constraints on what rendering can be used. Paul Austin wrote: Hi Martin, I'm just working on a concept of a HtmlRenderer that will take an object and convert it to HTML for display in Swing HTML widgets. There will then be a HtmlRendererRegistry that will map from a Java Class to a renderer. When displayign features you would use the registry to get a renderer for an object and use this to generate the HTML. We could then extend this concept for things like geometry where the user can via the UI choose between a choice of renderers for that class (e.g. WKT, GML), those plug-ins would switch on the fly the renderer in the registry. The registry should also support the property change listener so that UI's can refresh themselves if the registry changes. Paul Martin Davis wrote: Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. As for the compound Feature idea, this seems to depend on having Readers which can actually create these things. It sounds like you have defined a custom reader for your need. I would be reluctant to build very much functionality for compound Features into the core until there is a clearer idea about the general use cases for them, and what would be required to make them usable throughout JUMP. For now hopefully adding some hooks to extend the FeatureInfoTable view will meet your need. BTW, the idea of having hum-readable names for FeatureSchemas is a nice one. I'd definitely support adding that functionality, even if it isn't exposed right now. More generally, this is all moving in the direction of supporting a full GML-like data model, where Features can contain FeatureCollections as attributes. I think deegree might have already extended JUMP to accomodate this - it would be nice to hear from them how well this worked and what they had to do to make it work. I think there might be some big UI challenges in accomodating a hierarchical Feature model, but it might be worth building the infrastructure (i.e. enhancing the feature package), and then gradually enhancing the UI to expose more and more of it. It should be possible to provide sensible default UI behaviour wherever necessary. Paul Austin wrote: All, I have attached a screen shot of my new Feature InfoTable implementation. As you can see I've added some CSS styling to the table and where there are nested feature types have the feature type name displayed and a nested table with their attributes. NOTE: The sub feature type name stuff won't work with regular JUMP features as the FeatureSchema does not include the feature type name. I'm using my own Feature implementation based on the model used in my reader framework. It would be simple to add this to FeatureSchema if required. After looking at the current implementation I would like to suggest a change to the way the who feature info table view works. 1. Under the view menu have sub menu to allow the user to select the style for viewing geometry (WKT, EWKT, CL, GML) in addition to the current approach and save that so the user always get their preference. 2. Implement a FeatureInfoTable renderer which defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format 3. Roll the FID and geometry attribute into the table FeatureInfoTable renderer so that the geometry render is just used when geometry values are detected to display the value portion.
Re: [JPP-Devel] FeatureInfo table on steroids
Larry, One thing to note on the hierarchical feature model, I'm mainly using it for some file based formats thats support it. When using a database typically I'd design a flatter model and use the concepts of code tables. for shared nested attributes. For a hierarchical database model (where you implement it using relationships to other tables) you could have a related table data loader to get the information to display in a hierarchical fashion. Paul Larry Becker wrote: Hi Paul, Sounds like a pretty cool idea. I agree with Martin that a hierarchical feature model would be difficult. I'm not aware of anything already developed like you are referring to. Talking about databases, I'm thinking of loading all of the in-memory attribute stuff into an embedded Java database like Derby or H2. This would probably make a lot of things easier, like lookup tables. I'm not sure how R1's group plans to use H2, but I noticed that some uDig people were also interested in it. regards, Larry On 6/1/07, Martin Davis [EMAIL PROTECTED] 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 -- 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
Re: [JPP-Devel] FeatureInfo table on steroids
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
Re: [JPP-Devel] FeatureInfo table on steroids
Hi Martin, Which class currently implements the attribute view under the Feature Info frame? Cheers, 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
Re: [JPP-Devel] FeatureInfo table on steroids
Can't say offhand - but it should be pretty obvious by looking at the code. I seem to remember the design was pretty clean. I'm not sure if the Feature Info frame was designed to be very pluggable, so you may have to expose some internals via public methods. Paul Austin wrote: Hi Martin, Which class currently implements the attribute view under the Feature Info frame? Cheers, 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
Re: [JPP-Devel] FeatureInfo table on steroids
Martin, I think I should be able to do the view by creating a class that implements FeatureInfo.Writer and setting that on the appropriate class. Paul Martin Davis wrote: Can't say offhand - but it should be pretty obvious by looking at the code. I seem to remember the design was pretty clean. I'm not sure if the Feature Info frame was designed to be very pluggable, so you may have to expose some internals via public methods. Paul Austin wrote: Hi Martin, Which class currently implements the attribute view under the Feature Info frame? Cheers, 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
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
Re: [JPP-Devel] FeatureInfo table on steroids
Martin, I've found the code that deals with display of the attributes and geometry in the Info tab, unfortunately the current implementation only allows extension of the geometry rendering via getFeatureTextWriterRegistry on WorkbenchContext. What would be nice is to modify the FeatureTextWriterRegistry so that you could registerGeometryWriter and registerAttributeWriter and have the corresponding iterateGeometryWriters and iterateAttributeWriters. Then we would need to modify GeometryInfoTab so that it has buttons for geometry and attribute display types. I can make these changes and post a diff for people to review if they think this is useful. Paul Martin Davis wrote: Can't say offhand - but it should be pretty obvious by looking at the code. I seem to remember the design was pretty clean. I'm not sure if the Feature Info frame was designed to be very pluggable, so you may have to expose some internals via public methods. Paul Austin wrote: Hi Martin, Which class currently implements the attribute view under the Feature Info frame? Cheers, 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.
