[fdo-users] Question on associations between classes

Orest Halustchak orest.halustchak at autodesk.com
Mon Jul 16 08:32:58 EDT 2007

Hi Maksim,

You should be aware than currently neither MapGuide nor Map handle FDO
associations or object properties. Map should have skipped the object
properties rather than getting unhandled exceptions in the data table,
but either case is not going to help you.

The issue with requiring an identify for object property collections is
to be able to identify each item in the collection. It would only need
to be a local identifier within the parent's collection. It would be
used for update and delete processing as a way to identify an item

You had a question about multiple associations for parcels and projects.
This sounds like a many:many case? You could do that by having an
intermediate class that has 1:many associations to both parcels and
projects. However, Map and MG wouldn't be able to use this


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
Sent: Saturday, July 14, 2007 12:36 PM
To: fdo-users at lists.osgeo.org
Subject: Re: [fdo-users] Question on associations between classes

Current status :-) on Parcel Annotations:

Class definition (not FeatureClass) doesn't have a Geometry property, so
resorted to creating pair of X,Y double value data properties. They are
in AutoCAD only anyways, MapGuide has it's own way of displaying them so
it's not a problem for me.

Now for one little quirk:

ObjectPropertyDefinition assumes that both Collections and
OrderedCollections may contain Classes with mandatory
which is bit strange. I understand requiring IdentityProperty on
OrderedCollection (it's order is based on identity of it's elements, I
assume), but simple Collections, in my view, do not need
since they're simply collection of objects in whatever order I created

This introduces one more drawback - I had to create an IdentityProperty
my Annotation class, making it concrete in that way. I just want it's
meta-data definition within FeatureSchema and nothing more - actual
instances of Annotation will get added to the Parcel.Annotations
Now I'm confused :-) since I have no idea of how to create
class definition to include it's meta-data only, and use it as
collection element at the same time.

Anyone, please help :-)

Autodesk Map 3D 2007 (SP3) went berserk when I introduced object
property to
a feature class. It's DataGrid ceased working (error reported:
exception at 0x7c812a5b in acad.exe: Microsoft C++ exception:
at memory location 0x0b2cfea0"... But this is a lesser problem.

With kindest regards,
Maksim Sestic

Maksim Sestic wrote:
> I was thinking of using following FDO approach, please correct me if
> wrong at some point:
> 1) Annotations
> 1.1) Create Annotation Class (not FeatureClass) since Classes are
> accessible throughout DataStore.
> 1.2) Annotation class, among other properties, posesses one geometric
> property (it's insertion point). It does not posses identity property
> since it's always used as a child of a FeatureClass.
> 1.3) Create FeatureClass named "Parcel". It posesses identity, data
> geometric properties. As an extra, it also posseses an Object property
- a
> collection of Annotation objects - meaning that one Parcel may posses
> or more Annotations.
> 2) Projects
> 2.1) Create globally accessible Project Class (not FeatureClass).
> 2.2) Project class posesses identity and data properties.
> 2.3) Create FeatureClass named "Parcel". It posesses identity, data
> geometric properties. As an extra, it also posesses an Association
> property.
> 2.4) An instantiated Project object gets associated to Parcel feature
> class in the following manner:
> 2.4.1) FdoAssociationPropertyDefinition::SetAssociatedClass refers to
> existing Project class instance.
> 2.4.2) FdoAssociationPropertyDefinition::SetMultiplicity is set to "1"
> (given Project instance may hold only one Parcel instance).
> 2.4.3) FdoAssociationPropertyDefinition::SetReverseMultiplicity to "0"
> Project may or may not have Parcels when instantiated).
> 2.4.4) SetReverseName to "Parcel"
> 2.4.5) Set Delete rule to Break (I don't want to have my Parcel
deleted if
> someone deletes Project containing it, since some other Project might
> refer to the same Parcel. I also don't want my Project instance
> if someone deletes this particular Parcel either).
> 2.4.6) Rinse and repeat 2.4.1) to 2.4.5) for each Project this Parcel
> belongs to.
> Now, for the tricky part - one Parcel may get associated to more than
> Project. Is it possible to add more than one
> FdoAssociationPropertyDefinition to a FeatureClass?
> Someone might ask why don't I associate features to the projects
> way round), meaning that Project class has association property
> associating zero or more feature classes. The answer is simple -
> schema changes and new feature class gets added to it - I would have
> change Project's associtaion definition to include newly added feature
> class. Or am I wrong? :-)
> Regards,
> Maksim Sestic
> Maksim Sestic wrote:
>> Dear all,
>> I need to decide on what approach to take regarding logically
>> classes described by schema:
>> 1) My features have annotations
>> Each instance of my FeatureClass may have 0..n annotations.
>> them is a lesser problem, the general question is - how do I store
>> annotations and how do I relate physical class to them? I was
thinking to
>> resort to standard RDBMS approach - creating Annotations feature
>> (table) with rows (annotation instances) pointing to it's owner
>> class). Maybe there's more "proper" approach, as shortly described in
>> DevGuide, using other types of Classes than the FeatureClass?
>> 2) My features belong to projects
>> Each instance of my FeatureClass may belong to 0...n projects.
Meaning -
>> one feature may belong to two (or more) different projects at the
>> time. Naturally, there's only one instance of a feature class in a
>> datastore. Using classical RDBMS approach, I would create Projects
>> with records describing actual projects, accompanied by related table
>> keep pointers on features belonging to that project. What FDO has to
>> about this type of association?
>> With kindest regards,
>> Maksim Sestic

View this message in context:
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 mailing list