[fdo-users] Question on associations between classes

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
uniquely.

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
automatically.

Orest.

-----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
I
resorted to creating pair of X,Y double value data properties. They are
used
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
IdentityProperties,
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
IdentityProperties
since they're simply collection of objects in whatever order I created
them. 

This introduces one more drawback - I had to create an IdentityProperty
for
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
collection.
Now I'm confused :-) since I have no idea of how to create
contained-only
class definition to include it's meta-data only, and use it as
instantiated
collection element at the same time.

Anyone, please help :-)

P.S.
Autodesk Map 3D 2007 (SP3) went berserk when I introduced object
property to
a feature class. It's DataGrid ceased working (error reported:
"Unhandled
exception at 0x7c812a5b in acad.exe: Microsoft C++ exception:
IGWSException
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
I'm
> wrong at some point:
> 
> 1) Annotations
> 1.1) Create Annotation Class (not FeatureClass) since Classes are
globally
> 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
and
> geometric properties. As an extra, it also posseses an Object property
- a
> collection of Annotation objects - meaning that one Parcel may posses
zero
> 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
and
> 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"
(a
> 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
also
> refer to the same Parcel. I also don't want my Project instance
affected
> 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
one
> 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
(other
> way round), meaning that Project class has association property
> associating zero or more feature classes. The answer is simple -
anytime
> schema changes and new feature class gets added to it - I would have
to
> 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
associated
>> classes described by schema:
>> 
>> 1) My features have annotations
>> Each instance of my FeatureClass may have 0..n annotations.
Describing
>> 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
class
>> (table) with rows (annotation instances) pointing to it's owner
(physical
>> class). Maybe there's more "proper" approach, as shortly described in
FDO
>> 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
same
>> time. Naturally, there's only one instance of a feature class in a
>> datastore. Using classical RDBMS approach, I would create Projects
table
>> with records describing actual projects, accompanied by related table
to
>> keep pointers on features belonging to that project. What FDO has to
say
>> about this type of association?
>> 
>> With kindest regards,
>> Maksim Sestic
>> 
> 
> 

-- 
View this message in context:
http://www.nabble.com/Question-on-associations-between-classes-tf4073626
s18162.html#a11595320
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