Hi,
 
As a user, I really hope you can keep the software as simple to use as it is 
nowadays even if the feature model goes complex...
 
-Jukka Rahkonen-

________________________________

Lähettäjä: [EMAIL PROTECTED] puolesta: Markus Müller
Lähetetty: pe 8.6.2007 19:04
Vastaanottaja: List for discussion of JPP development and use.
Aihe: Re: [JPP-Devel] Alternative to a complex feature model...



Hi Landon, Martin,

(as so often) I agree with most points made by Martin. Perhaps a use
case that I have in mind for a while is of interest here.

In Germany (sorry...)  there is a group of people who developed an
object model for urban planning called "XPlanGML" (for those able to
understand German, see http://www.xplanung.de). A "Plan" consists of
several "layers" that itself consitst of different types of object
sometimes having more than one geometry. The model was developed in UML
and converted to a GML application schema.

We implemented support for this GML application schema with deegree WFS
and now a client that is able to display the semantic structure and even
able to crate XPlanGML would be a real hit. If OJ would be extended to
do this you would have to give it a complex feature model. But the main
work would go into the user interface, because object information would
have to be displayed in a tree-like structure able to display all
connections between the objects. If you want to crate XPlanGML, you
would have to define the object type of a newly created geometry, but
also the place in the tree that represents the actual plan.


Have a nice weekend,

Markus


Martin Davis schrieb:
> SS,
>
> Good blog post.
>
> It seems to me that you are recapitulating the object-vs-relational
> debate that was raging strongly in the DB world in the late 90's.  It
> seems like the RDB's have won that round (at least for the time being)
> on the server side, but the object world is obviously in the ascendant
> on the client side.
>
> I also think that this debate is mostly about implementation, but
> doesn't really address the more fundamental issue of what the actual
> semantic model is.  And that's the important question, because that is
> what is needed to motivate the design of the user interface and tools to
> present it to the user.  To put this more concretely, it would certainly
> be possible to represent complex features as sets of related tables. 
> But what would the user interface look like on top of this?  How would
> Paul get his view of complex features?  What would it mean in terms of
> UI to have a complex feature with either two geometries at one level, or
> an attribute which is itself a collection of spatial features?  You
> would still need a way for the user to indicate how he wanted these to
> be rendered, how sub-features were created and destroyed, etc.
>
> Moreover, a table based model in not in fact simpler, it's more
> complex!  This is because it is more general, since relationships
> between tables can model both association and aggregation.  In contrast,
> a complex hierarchical Feature is generally considered to model an
> aggregation.  A concrete implication of this difference is that in a
> table-based model, you either have to explicitly define or explicitly
> manage the life-cycle of related sub-features.  In an object-based
> model, this is controlled by the top-level feature, which is a simple
> model for the user to understand.  (RDBs usually handle this situation
> by implementing "cascading delete on foreign keys" - but you don't get
> this for free, you have to have a language to define this and the user
> has to understand how to model this).
>
> To use another metaphor, I sometimes think of tables as the
> assembly-language of object models.  You can represent pretty much any
> model you want using tables, but *you* have to to all the work of
> defining and maintaining the model.  An object model is presented at a
> slightly higher level of abstraction, with some reasonable defaults
> which can make it easier for a user to work with.
>
> My main point here is that I think the choice of object-vs-table is
> orthogonal to the issues of defining the "mental model" that JUMP
> presents to users via it's UI.  *That* is the key thing to design - the
> rest is just a question of implementation.
>
> Martin
>
>
> Sunburned Surveyor wrote:
>  
>> I put up a post on my OpenJUMP blog about one possible alternative to
>> a complex feature model.
>>
>> I haven't thought the idea through completely, and I don't have any
>> plans on implementing the alternative described, but if you are
>> interested in having the benefits of a more complex feature model in
>> OpenJUMP you might want to read the post. If nothing else, I hope it
>> presents an interseting concept.
>>
>> The post is here:
>> http://openjump.blogspot.com/
>>
>> The Sunburned Surveyor
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>  
>>    
>
>  


--
Dr. Markus Müller
l a t / l o n  GmbH (Hamburg)
Gluckstr. 53a                   22081 Hamburg, Germany
phone ++49 +177 2470742         fax ++49 +228 18496-29
http://www.lat-lon.de           http://www.deegree.org
--


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

Reply via email to