Hi Paul,

  Great!  I think this is a useful list.  I would extend it to show
columns of JUMP forks (JUMP, OpenJump, SkyJUMP, Kosmo, Pirol Jump,
deeJUMP, SIGLE JUMP, etc.) with an "x" showing which forks have
implemented which model concepts.  In this way, OpenJump development
can best benefit from pioneering work already done, and perhaps avoid
problems already solved (or not solved).

regards,
Larry Becker

On 6/13/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> A comment that SS made regarding Layers vs. FeatureSchema objects made
> me think that we probably need a Wiki page where we can define the
> concepts and purpose of these concepts within OpenJUMP before we start
> changing around anything to do with the feature model, schema etc.  So
> I've put together a list below of some of these concepts and my
> understanding of these. These are quick notes and would need to be word
> smithed.
>
> User Facing concepts:
>
> Project - A user defined grouping of data that they wish to work on for
> a specific task.
> Category - Visual Grouping of layerables in a Project
> Layerable - A visual item that can be displayed on the Projects viewport
> Layer - A vector based Layerable used to render Feature instances using
> Style objects
> Style - A way of changing the rendering of a feature, Color, width.
> pattern, text, line decorations
> LayerTheme - Currently this is a ColorThemingStyle that will render
> features using different style based on attributes of a feature. The
> theme also displays additional names under the layer. I think this
> concept needs to be extended to allow different types of themes and to
> have show/hide for the themes. Maybe a Layerable.getThemes() that would
> return a collection of LayerableTheme objects rather than the current
> approach which hard codes the ColorThemingStyle
> WMSLayer - A raster based Layerable loaded from a WFS Server
>
> Internal Concepts:
>
> Feature - An in memory representation of user's data, which can have
> geometry and attribution. Question: can we use the Feature concept for
> data without geometry or should Feature be a subtype of a DataObject
> interface that has the same interface but without the Geometry methods.
> FeatureSchema - Provides the names and types of the attributes on a Schema
>
> DataStore - A connection to a store of feature and attribute only data.
> Examples would be File, ZipFile, Postgis database connection, Oracle
> database connection. A DataStore can contain many data sets.
> DataSource - A connection typically to a source of data that contains a
> single type of feature for example a Shape file
> ConnectionManager - Saved list of previous database connections
>
> I'm sure I missed a whole bunch of concepts but this should be enough to
> start discussion.
>
> 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
>


-- 
http://amusingprogrammer.blogspot.com/

-------------------------------------------------------------------------
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

Reply via email to