Yup, I've used this approach to "fake" non-spatial layers, and it works pretty well.
Or you can always just put an empty GeometryCollection in the GEOMETRY attribute. You can even use a single GC object for all Feature instances, since they are never modified in JUMP. Really the issues around handling non-spatial layers lie more with creating a nice UI for them, which will present a nice intuitive model to the user. Part of this involves making the current tools sensitive to whether a layer is non-spatial, so they are visually disabled when a non-spatial layer in in focus. This however does require some indication that a layer is non-spatial. One way to do this would be to extend Feature and FeatureSchema with a method "hasGeometry". It might also be nice to support Features with more than one Geometry. In this case, the schema needs to indicate which Geometry attribute is the "primary" one, which will be returned by the getGeometry method. This reminds me of another feature we added to RoadMatcher, which might be nice to have in JUMP. We supported the idea of "Styling Layers". These are virtual layers backed by a real Layer, which allowed different kinds of styling to be applied to a single layer. These might be useful for the multi-Geometry concept, because a StylingLayer could also depict a different Geometry attribute (i.e. not just the default) from a Layer's FeatureSchema. Sunburned Surveyor wrote: > Paolo, > > I had considered this option, but thought the external plug-in might > provide a cleaner road. But you are correct, I think this would work. > > The Sunburned Surveyor > > On 6/5/07, P.Rizzi Ag.Mobilità Ambiente <[EMAIL PROTECTED]> wrote: > >> There's a dirty path you may follow to support non spatial layers, >> you can make them spatial. >> >> If a layer is loaded without a Geometry field, one is added on the fly. >> The geometries will be empty, so the Core would have to be modified >> to cope with them, but it has anyway because right now you get >> NullPointer exceptions if you load a Layer from a DataStore query >> that results in one or more records with empty geometries. >> >> After that the layer is treated like any other one, although it's not >> rendered. >> >> You can even think of some kind of "calculator" class you can attach >> to the Layer (maybe through BeanShell) that can "calculate" the >> geometry field on the fly, making a non spatial layer spatial. >> >> >> Bye >> Paolo Rizzi >> >> >> >> >>> -----Messaggio originale----- >>> Da: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] conto di >>> Sunburned Surveyor >>> Inviato: martedì 5 giugno 2007 0.33 >>> A: List for discussion of JPP development and use. >>> Oggetto: [JPP-Devel] Support for non-spatial features... >>> >>> >>> I thought I would start a new thread so we could split this apart from >>> the discussion that Paul and Martin were having about the FeatureInfo >>> tool. >>> >>> When I suggested that support for non-spatial features could be >>> included in a plug-in Martin wrote: "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. This >>> is more than just a single plugin, tho - it's a more of a >>> generalization >>> of the existing Feature framework." >>> >>> I still think you could encapsulate this functionality in a plug-in or >>> set of plug-ins. This might not be the best way to go long term, but >>> it could let us test out how things would work without messing with >>> the core. >>> >>> For example, I wouldn't even mess with the Layer List. I'd create a >>> separate UI component that could be used to manage non-spatial feature >>> collections or tables. We could make it look similar to the Layer List >>> for purposes of consistency. I think it would be a little confusing to >>> include symbols for non-spatial feature collections in the Layer List. >>> They wouldn't affect the display order for one thing, and we currently >>> use the visual arrangement of layers in the Layer List to do this. >>> >>> I imagined a plug-in that created a "Non-Spatial Feature" menu entry >>> somewhere. This menu entry would pull up a UI that would allow the >>> user to create, delete, modify, and import/export non-spatial feature >>> collections. >>> >>> Another related plug-in could be used to create associations between >>> non-spatial feature collections and spatial feature collections. I >>> think most of this functionality could be managed internally by the >>> plug-in. >>> >>> These are just some ideas. :] >>> >>> I think one danger of walking down the "non-spatial" feature path is >>> that we will begin to implement more and more traditional RDBMS >>> features. (For example: "Let's ass support for transactions to our >>> non-spatial feature collections."..."Let's add support for custom >>> datatypes to our non-spatial feature collections."..."Let's add >>> support for datatype constraints to our non-spatial feature >>> collections.") Perhaps the smart thing to do is to design a system for >>> non-spatial features that uses an embedded Java database that already >>> contains all of this functionality. I wouldn't have a problem with >>> this if we could access the database components directly without >>> having to mess with a JDBC layer. (Note: I'm not talking about storing >>> the attribute information for spatial features in an embedded >>> database. I think the Sigle team is already working on something like >>> this. I'm talking about storing the attributes of non-spatial >>> features.) >>> >>> Then again, maybe it wouldn't be a big deal to implement some RDBMS >>> features if we have support for non-spatial features in OpenJUMP. It >>> just seems like a waste of effort with all the work that must be going >>> on in open source Java databases. >>> >>> Michael wrote: "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..." >>> >>> Good idea... >>> >>> Martin wrote: "Yes, definitely that would be cool. This would be >>> equivalent to a >>> defining a view in an RDBMS." >>> >>> See! That is what I was talking about. :] >>> >>> SS >>> >>> -------------------------------------------------------------- >>> ----------- >>> 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
