Multiple Parent Hierarchy...

[Andrew Meador]

I have searched and found where this has been discussed, but the
suggestions I have found have all ended up tuning into debated about
whether it needs to be done - but - as far as I can tell - I need to.

I am trying to setup a database that tracks parcel history. I want
to be able to choose a parcel and see a list of its children (smaller
pieces to the property that have been sold off) and a list of its
parents (previous tracts/parcels that created the current parcel).
This does happen, where I have had pieces of larger parcels that were
sold off from the larger parcels and combined into a single new
parcel. I would like to represent this in some hierarchy 'tree' view
to make it easy for users to select a parcel to see it's details, but
to be able to quickly move up and down the 'tree' studying details of
the selected parcel.

I figured on using a database table with a parcelID, parentParcelID
and other parcel related fields. I could then use selects to return
the parents and childrent o populate some control to display them.
TreeView can't do this since it only supports a single parent. Is
there any other control or method you could recommend to accomplish
this?

Thanks!

 

[Jon Skeet [C# MVP]]

I have searched and found where this has been discussed, but the
suggestions I have found have all ended up tuning into debated about
whether it needs to be done - but - as far as I can tell - I need to.

I am trying to setup a database that tracks parcel history. I want
to be able to choose a parcel and see a list of its children (smaller
pieces to the property that have been sold off) and a list of its
parents (previous tracts/parcels that created the current parcel).
This does happen, where I have had pieces of larger parcels that were
sold off from the larger parcels and combined into a single new
parcel. I would like to represent this in some hierarchy 'tree' view
to make it easy for users to select a parcel to see it's details, but
to be able to quickly move up and down the 'tree' studying details of
the selected parcel.

The trouble is, what you have isn't a tree. In a tree, each node *does*
only have one parent.

What would you want the UI to actually look like? How would you
represent the multiple parents for multiple children?

One option might be to use a tree view, but populate each of the
parents with the child. It could get ugly very quickly though...

 

[Arved Sandstrom]

I have searched and found where this has been discussed, but the
suggestions I have found have all ended up tuning into debated about
whether it needs to be done - but - as far as I can tell - I need to.

I am trying to setup a database that tracks parcel history. I want
to be able to choose a parcel and see a list of its children (smaller
pieces to the property that have been sold off) and a list of its
parents (previous tracts/parcels that created the current parcel).
This does happen, where I have had pieces of larger parcels that were
sold off from the larger parcels and combined into a single new
parcel. I would like to represent this in some hierarchy 'tree' view
to make it easy for users to select a parcel to see it's details, but
to be able to quickly move up and down the 'tree' studying details of
the selected parcel.

I figured on using a database table with a parcelID, parentParcelID
and other parcel related fields. I could then use selects to return
the parents and childrent o populate some control to display them.
TreeView can't do this since it only supports a single parent. Is
there any other control or method you could recommend to accomplish
this?

Thanks!

With respect to the data modelling, I'd start with the thought that you have
a directed acyclic graph (DAG). Where the 'acyclic' comes in is due to the
fact that logically, if parcel A is subdivided into parcels A1 and A2, that
if sometime later A1 and A2 are combined into a new parcel, that will be B,
not A, even though the plot of land is identical.

The vertices of the DAG represent parcels. You'd store history (start/end
dates) here as well as other parcel information. This system would easily
account for changes in ownership or appurtenances, not just fragmentation
and consolidation of parcels. So you'd have one table to store vertex
(parcel) data.

The edges represent lineage. Another table would store edge data, and each
row would have two parcel IDs - parcelID and parentID. Bear in mind that
"parent" means not just spatial parent but also temporal parents. For a
graph these are the predecessor vertices.

The edge table makes it easy, for any vertex/node V, to find what the
predecessors (parents) and successors (children) are. In the first case you
are looking for all parentIDs for a given parcelID. In the second case you
want all parcelIDs for a given parentID.

I may have just taught my grandmother how to suck eggs, for which I
apologize in advance. But you did mention _one_ database table.

For viewing, well, I'd look for something that just displays graphs. I'm
taking a gander at this:
http://www.codeproject.com/KB/miscctrl/quickgraph.aspx

AHS

 

[Andrew Meador]

With respect to the data modelling, I'd start with the thought that you have
a directed acyclic graph (DAG). Where the 'acyclic' comes in is due to the
fact that logically, if parcel A is subdivided into parcels A1 and A2, that
if sometime later A1 and A2 are combined into a new parcel, that will be B,
not A, even though the plot of land is identical.

The vertices of the DAG represent parcels. You'd store history (start/end
dates) here as well as other parcel information. This system would easily
account for changes in ownership or appurtenances, not just fragmentation
and consolidation of parcels. So you'd have one table to store vertex
(parcel) data.

The edges represent lineage. Another table would store edge data, and each
row would have two parcel IDs - parcelID and parentID. Bear in mind that
"parent" means not just spatial parent but also temporal parents. For a
graph these are the predecessor vertices.

The edge table makes it easy, for any vertex/node V, to find what the
predecessors (parents) and successors (children) are. In the first case you
are looking for all parentIDs for a given parcelID. In the second case you
want all parcelIDs for a given parentID.

I may have just taught my grandmother how to suck eggs, for which I
apologize in advance. But you did mention _one_ database table.

For viewing, well, I'd look for something that just displays graphs. I'm
taking a gander at this:http://www.codeproject.com/KB/miscctrl/quickgraph..aspx

AHS- Hide quoted text -

- Show quoted text -

You understand this very well! Thanks! I hadn't thought about
trying to handle it through graphing methods, but the link you gave me
would seem at first glance to be a great solution. I could use the
vertixes as parcels (as you suggested) and this library would allow
the user to click on any node - upon which I could pull the related
details to population other fields on the form. All parcels have a
parent parcel, so it made sense to me to put the reference to the
parentParcelID within each parcels data withing one table. I guess
that could be separated out as you suggested, and maybe could get
better performance vs. having this data in one table with and index on
the table. Not sure - I'd have to think about the pro's/con's of each
approach.

Anyway, thanks for your link and suggestions - this gives me a good
direction to continue with!

Andrew