[fdo-users] RE: Object and Association Support
brent.robinson at autodesk.com
Fri Jul 23 13:29:40 EDT 2010
Associated geometry is an interesting case. I tried a select, with filter similar to:
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.
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 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.
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
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
More information about the fdo-users