Originally commented on this "split with lines"9 thread, but thought a separate thread on transfer rules (TR) may be easier to locate.

Split area(s) with lines and transfer numeric columns based on proportional area, is one of the most frequent workflows we deploy in 8. To 9 165.2, split with lines and the associated TR proportional (area / length) has been dropped (see adamw's comments in referred thread for explanation).

Looking for an alternative workflow in 8 that will port effectively to 9, succeeded in getting a result using 8 Drawing / Topology Overlay / intersect, but it takes much longer than a "split with lines" workflow and the results drawing looses the functionality of the active the columns in the data drawing, which is a substantial loss, though it does copy the active column contents on a one-off basis.

With a view to seeing whether the additional time required in 8 could be compensated for by an equivalent workflow in 9: On the same (imported) 8 data, experimenting with a 9 equivalent transform "Overlay Topology, Intersect", we encounter the same obstacle from losing TR / proportional (area / length). In the screenshot, all the highlighted fields plus hundreds more, have 8 TR set to something other than "ignore" or "copy". I'm guessing that any 8 table with a TR of "proportional.." is minimalised to the base level of ignore/copy, when brought into current 9.

Will send further notes to sales as a suggestion and encourage anyone else who is encountering related issues to do likewise - please.

Attachments:
Overlay Topology Intersect limit in 9.jpg

Graeme,

Could you summarize the main point?

After a few re-reads I don't quite get it. Are you being too polite?

(But obviously there is a major data design problem if you're working with hundreds of fields.)

Thanks Tim, circumspect probably. The hundreds of fields represent hundreds 3+ * census periods - trend analysis. Sure we can cull them and regularly do for user-specific scenarios but important to have them available and comparable over time for current spatial area units - that's the main point. The current spatial unit is a regularly changing spatial entity and every time it changes we update data proportionately on new area. Does that shed sufficient light?

No, I have no better clue what the point is yet.

And that's still really bad data design. You should absolutely use separate tables, linked by key fields.

Here is an illustration of how to distribute field values proportionally to area.

I imported a drawing of Mexico states with POP1990. I then created a drawing with a couple of artificial objects overlaying the states, and did Overlay Topology, Identity for that drawing + states. During the overlay, I copied the following fields from the states: MFD_ID for identification and POP1990 because that's what I am interested in. These fields got renamed to O_MFD_ID and O_POP1990 in the resulting drawing. Each object in the resulting drawing thus has some geometry, plus O_MFD_ID and O_POP1990 of the single overlaying state. There are potentially multiple objects with the same O_MFD_ID - a single state is splitting into parts - and they now have the same value of O_POP1990. What we want is to adjust the values of O_POP1990 in these objects to distribute it proportionally to area, giving bigger objects more and smaller objects less, and keeping the sum equal to the original value.

To do this, I first computed total area of each O_MFD_ID in the resulting drawing (we could have just taken the area of the original object from states, but I recomputed anyway to allow the transform to alter objects however it wants: throw away their parts, buffer them, etc, altering the area on the way):

--SQL9

SELECT o_mfd_id, Sum(GeomArea(geom, 0)) AS area INTO temp

FROM [boxes Table Overlay Topology, Identity]

WHERE o_mfd_id IS NOT NULL

GROUP BY o_mfd_id;

Then I took each object in the resulting drawing and changed the value of O_POP1990 to O_POP1990 * area of this object / total area recorded for O_MFD_ID:

--SQL9

UPDATE (

  SELECT d.mfd_id, d.o_POP1990,

    d.o_POP1990 * GeomArea(d.geom, 0) / t.area AS POP1990_proportional

  FROM [boxes Table Overlay Topology, Identity] AS d INNER JOIN temp AS t

  ON d.o_mfd_id = t.o_mfd_id

) SET o_POP1990 = POP1990_proportional;

See the attached MXB.

Attachments:
transfer-proportional.mxb