Yes, I agree 100%. It's fine to look at adding functionality for complex feature types, but this should not complicate the use of the current simple feature model!
Rahkonen Jukka wrote: > 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 > > -- 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
