Yes, definitely that would be cool. This would be equivalent to a defining a view in an RDBMS.
Michaël Michaud wrote: > Sounds good, > > 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... > > my two cents > > Michaël > > P.Rizzi Ag.Mobilità Ambiente a écrit : > > >> 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 >> >> >> >> >> > > > ------------------------------------------------------------------------- > 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
