Features are the basic unit of “work” in OpenJUMP. They are the fundamental “thing” that users are interested in manipulating. There are several ways to organize or group features to make the tasks of the user easier to accomplish. OpenJUMP currently uses a single “container” to organize Features from the user’s perspective. This container is a Layer. Users interact with Layers mainly through the Layer List. (Programmers know this as the LayerManager object.)
Layers provide the user with some useful “restrictions” on Feature organization that simplify their work. For example, all of the Features in a Layer share a common set of attributes, or a FeatureSchema. They also follow a common set of styling rules that govern their graphical appearance. Aside from these two restrictions, Layers are pretty flexible. They can store Features with different geometry types. They can share a name with another Layer.
Internally Layers are really just a wrapper around a FeatureCollection. But again, for the sake of simplicity, OpenJUMP places some restrictions on this FeatureCollection. As we mentioned before, it can only contain Features that share a common set of attributes or a FeatureSchema. This FeatureCollection also is not treated as a Feature itself, as can be done, at least in theory, with something like GML.
As we can see, there is a balance that we try to maintain with the design of OpenJUMP’s Feature Model between flexibility and simplicity. In order to have simplicity you must have restrictions on flexibility.
I don’t think we’ve really examined where we would like to have this balance as OpenJUMP developers, but I think the time for this discussion is right now. I think there will be an inevitable push towards more flexibility, as we continually try to find ways to bolt more and more functionality on top of OpenJUMP. I think we need to be cautious about this. One of the greatest assets OpenJUMP has, both from a users perspective and from a developers perspective, is its simplicity.
I’d like to propose the establishment of some ground rules for our Feature Model. I think it is important to preserve our simplicity by putting into place some common sense restrictions. If a programmer would like to get around these restrictions, lets ask that he do it with a plug-in, and not by modifying OpenJUMP’s core.
Here are the restrictions that I would like to propose:
 Each Layer must be uniquely identified in some way from other Layers. This doesn’t mean that Layers can’t appear to have the same name to the user. We could use a numeric identifier or require that every Layer name in a Category be unique. What do we gain with this restriction? It allows us more opportunity to use Layers as the main containers for Features. For example, this will allow Layers to serve as what is often called a FeatureType or FeatureClass in other GIS programs. (The user would be able to place constraints or validations tests on a Layer.) We are really close to this type of system already, because we require all Features in a Layer to share a common FeatureSchema. It is not that big of a leap to require that Layers also be uniquely identified. This would remove the necessity to uniquely identify FeatureSchema, because each FeatureSchema would belong to a unique FeatureCollection wrapped in a unique Layer.
 We will never, ever, ever expose FeatureSchema to the user through the GUI. We don’t need to do this, because all Features in a Layer share the same FeatureSchema. If a user needs to work with some aspect of a FeatureSchema have them access that functionality through a Layer, don’t expose it directly. What do we gain from this restriction? Things become much simpler from a user’s point of view. They don’t have to worry about FeatureSchema, Feature Types or Feature Classes. They can just think in terms of Layers. Do we loose some flexibility with this restriction? Yes we do. (For example, we won’t be able to let the user apply constraints to multiple Layers that essentially share a common FeatureSchema. They would have to apply these constraints to each Layer individually.) But I think this price is worth preserving simplicity.
 We will not allow FeatureCollections that can also act as a Feature themselves. This adds some significant complexity to OpenJUMP's Feature Model. We’ve already had some discussion on the JPP Development list about this. I think an alternative way to facilitate this type of functionality is by allowing associations or relationships between Features. This could be done with a plug-in and would not require modification of the current OpenJUMP/JUMP Feature Model. (I am not ruling out exposure of loose groups of Features. These groups could contain multiple Features from different Layers, but would not be allowed to act as a Feature themselves. This could be accomplished with a plug-in and these groups could be created from selection sets. I think of their purpose as being similar to a block in AutoCAD.)
I’d like to see some more discussion about finding the balance between flexibility and simplicity in OpenJUMP’s Feature Model. I’d specifically like a decision on what primary Feature “container” we will expose to the user. Will the Layer object remain in this role, or will we expose something else like a Feature Type in its place. If we do so, what will the price to simplicity be? Will we modify the Feature Model to support “Complex Features”, or FeatureCollections that can act as Features themselves? Are we willing to pay the price of lost simplicity for this functionality, or will we ask that this be done through association via a plug-in.
The Sunburned Surveyor