[fdo-users] RE: Object and Association Support

Mon Jul 26 10:22:51 EDT 2010

I think I'll re-read the thread from here up a few times and see if I learn
anything.
thanks

On Mon, Jul 26, 2010 at 9:17 AM, Orest Halustchak <
orest.halustchak at autodesk.com> wrote:

>  Hi Brad,
>
>
>
> OK, we’ll switch to fdo-internals.
>
>
>
> Thanks,
>
> Orest.
>
>
>
> *From:* fdo-users-bounces at lists.osgeo.org [mailto:
> fdo-users-bounces at lists.osgeo.org] *On Behalf Of *Brad Nesom
> *Sent:* Monday, July 26, 2010 10:15 AM
>
> *To:* FDO Users Mail List
> *Subject:* Re: [fdo-users] RE: Object and Association Support
>
>
>
> i'm not complaining, (maybe some good programming techniques will rub off),
> but is this an fdo-users thread or an fdo-internals? It is quite a bit over
> my head.
>
> :)
>
> On Mon, Jul 26, 2010 at 7:30 AM, Orest Halustchak <
> orest.halustchak at autodesk.com> wrote:
>
> 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
>
>
>
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20100726/13f39ebc/attachment.html