[fdo-internals] FW: [fdo-users] RE: Object and Association Support

Mon Jul 26 10:17:46 EDT 2010

Switching to fdo-internals ...

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Monday, July 26, 2010 8:30 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] RE: Object and Association Support

Hi,

One of the things available with associations is the definition and handling of cardinality rules and cascade delete rules. With object properties, the objects are contained within the parent object and automatically would be deleted when the parent is deleted. It provides not just the advertising of where there are associations and object properties, but some management of them as well.

Crispin, yes, these allow the handling of association rules and complex objects that contain ADT style properties to be managed by the provider / server. You said 'These can, of course, be modelled at the application level but rich object management is just a "better" way of handling the real-world.' It's a question that comes up for the more advanced capabilities and data types that may only be implemented by a smaller number of FDO providers. If a user wanted to take advantage of those capabilities, then they would be restricted to the providers that support them. The other argument is that if advanced capabilities can be implemented above the FDO level, then possibly they could be available with more providers since the providers don't have to be upgraded to handle all the new capabilities (and there are quite a few providers available now, open source and commercial, and growing). Personally, I feel that there are cases where something cannot be done easily or with enough performance above FDO where you can argue that it should be at the FDO level. But, should we also be looking at the alternative where it may make sense? There is obviously a trade off of where data integrity rules are known versus more wide-spread use of the capability. Open question. Note that there was some roughly related discussion a while ago as part of a "futures discussion": http://trac.osgeo.org/fdo/wiki/FdoClientUtilities 

Thanks,
Orest.

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Brent Robinson
Sent: Friday, July 23, 2010 1:30 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] RE: Object and Association Support

Associated geometry is an interesting case. I tried a select, with filter similar to:

    ParentClass.ChildAssociation.Geom EnvelopeIntersects
    GeomFromText('<geometry text>')

with the OSGeo.MySQL and OSGeo.PostgreSQL providers but it didn't work. The scoping got removed and it tried to filter on ParentClass.Geom. However, a filter on a data property such as:

    "ParentClass.ChildObject.Value = 1"

works fine. I don't know of any technical reason why the filter on associated geometry would not work; it would probably be just a matter of bug fixing to get these providers to support it.

In the case of 1:m associations, the "ParentClass.ChildObject.Value = 1" would select all ParentClass features with at least one associated ChildObject with Value=1. However, when I tried this with the MySQL provider, if a feature had 2 ChildObjects that passed the filter, then the feature got selected twice. 

Since associations have been under-utilized sofar, there are probably a few bugs like the above-mentioned ones, that would need to be fixed before association properties would be working smoothly. 

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Crispin_at_1Spatial
Sent: Friday, July 23, 2010 3:46 AM
To: fdo-users at lists.osgeo.org
Subject: [fdo-users] RE: Object and Association Support

Orest,

Orest Halustchak wrote:
> 
> Crispin, do you have some examples of the types of data models that you
> would like to support?
> 

This very simple example is for the management of cartographic labelling for
an object - is positioned text.  I am sure this is something that has been
asked of some of the high-end editing clients using FDO.

Take a river class - some rivers are short and have no labels (these
requirements are for positioned 'cartographic' labels, not auto-generated
labels).  Some have one and some have many.  The labels do not exist as a
"layer" themselves as are only ever associated with the river - when the
river is off they disappear without needing to have application-level logic
such as a layer-group fudge.  Editing the label geometry is really editing
one of the complex geometry/attribute the river object.

More complex examples such as property boundaries containing properties and
masts where the properties and masts are entities of their own and also
shared with other objects.  These can, of course, be modelled at the
application level but rich object management is just a "better" way of
handling the real-world.
Just as managing topographic detail is moving from classic lines
(historically print/plot/carto driven needs) to polygons (GI
representation)... business modelling is moving to multi-cardinality
representation rather than simple features.

Another Question:
If an object in a class has a geometry and the association/object properties
include geometry, what will happen with a spatial query?  By default I
assume that only the parent geometry be used in the query as the filter must
explicitly define the geom column that it is acting on.
Brent said above that you could do a filter like
"ParentClass.ChildObject.Value = 1" so I assume this is supported for
spatial filters.  Where there is 1:m cardinality on associations does the
query below automatically run on *every* association - that would be very
good!!!
 ParentClass.ChildAssociation.Geom EnvelopeIntersects
GeomFromText('<geometry text>')

e.g. For a river labelling it may be expected that either the labels are
only show when the river object is visible in some applications, but for a
cartographic map tiling generation (where consistency is needed) the label
should show even if the river is on the adjacent tile but the label geom is
on this tile.

-- 
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Object-and-Association-Support-tp5325810p5328676.html
Sent from the FDO Users mailing list archive at Nabble.com.
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users