Hi,
Method 1 of many..
Expose feture_type (expose Feature_Typename at readerlevel, or use other feature_type identifier)
You can use the spatialrelator as you said.
Rename Feature_type to something else like "target_ft".
Explode relationships.
You can now use "target_ft" AND "Feature_Typename" as a grouping value.
Built a list grouped by the grouping value.
After that u just explode it, this will give u element_index attribute.
Using list may not be wise if you have an extremely large number (like zillions) of objects though
.
method 2 of many...
Expose feture_type (expose Feature_Typename at readerlevel, or use other feature_type identifier)
You can use the spatialrelator as you said.
Rename Feature_type to something else like "target_ft".
Concatenate "target_ft" and "Feature_Typename".
Use a sorter on this.
Use a counter and use the concatenated attribute as "counter name".
Gio,
You have helped me few times. I really cann't manage this SpatialRelator and things going with it.
Could you attach workspace SS, just to see what, where and when you put these all stuff? If you could, I will be thankful very lot :)
I am constantly trying to get whatever, and allways getting nothing!
Thanks in advance.
Hi Aleksander,
I used neighboorhoods polygons and trees/adress points for this one.
As neighboorhoods are identified by name i use its name rather then teh featuretypename.
Here is method2
I intepretated your issue as counter per (spatial)relation.
Zoom in a bit and see the settings.
Using method2 you basically create a count attribute for the Counter. This attribute works as a group by.
Here is result pic (partial table..). Check the count attribute, it starts counting anew for every neighboorhood.
Gio,
big thanks. It works fine, od cource. Thank you.
(Best answer)
Gio,
Just for a record: When I use ListExploder it (I don't know how) changes my Requestor's feature type to Supplier's feature type, and I get good Join but feature type is Supplier's.
When I remove ListExploder (because I just need to get attribute from Supplier into Requestor's feature types), it keeps original feature types and works good.
I have no idea what is happening, but...
Hi,
To avoid overwriting fme_feature_type of Requestors, consider using the AttributeRemover to remove "_relatiohships{}.fme_feature_type" before the ListExploder. If the name is hidden, you can expose it with the AttributeExposer.
Takashi
Hi,
yes i understand.
The reason being that the proces i illustrated combines suplier and input featuretypes. So all neighboorhoods (wich i limited to 5 for timereducion) are mapped to the requestors. It takes into account occurence of overlapping supliers.
If u have 1 suplier or non-overlapping supliers, then this is not needed.
When exploding there can be a conflict with attributes, if suplier and requester have same attributes. This is something u always need to watch out for (like Takashi is pointing out)
I mentioned in my first post that u need to rename one of the fme_feature_type name attributes (either requestor or suplier to avoid this conflict).
I usualy use names like
requestor: req_ftype
suplier: sup_ftype
