Do you intend to merge the features in the order of arriving? i.e. merge the 1st supplier to the 1st requestor, merge the 2nd supplier to the 2nd requestor, merge the 3rd supplier to the 3rd requestor, ... and so on
If possible, consider deciding that the "sql_statement" should always return a column with a fixed name using column alias, e.g. "oid". For example:
select t.objectid as OID, t.*
from my_table t
That way you can expose "OID" in your workspace and use it in the FeatureMerger, without having to know in advance which column it represents.
Thanks!
atm i use this:
SELECT M.id as ID
,Kf1.f1 AS Street,
Kf2.f2 AS city
K.fx.fx AS other attributes till max join limit is reached
FROM 2m1 M
LEFT JOIN 1k2 Kf1 ON M.f1=Kf1.id
LEFT JOIN 1k2 Kf2 ON M.f2=Kf2.id
etcetera
The id is the attribute used for merging the objects and identifying an object during the process. This is the only attribute that is present in both the A and B (and later C, D ect.) part of the dataset. Thats why i use the attribute exposer so i can use it in the feature merger.
Without the schemasetter I only get the geometry in the GML and it does not export the other attributes. Now atleast i get the atributes of part A (requestor). Could it be that hidden attributes get removed when entering a featuremerger?
Thanks!
atm i use this:
SELECT M.id as ID
,Kf1.f1 AS Street,
Kf2.f2 AS city
K.fx.fx AS other attributes till max join limit is reached
FROM 2m1 M
LEFT JOIN 1k2 Kf1 ON M.f1=Kf1.id
LEFT JOIN 1k2 Kf2 ON M.f2=Kf2.id
etcetera
The id is the attribute used for merging the objects and identifying an object during the process. This is the only attribute that is present in both the A and B (and later C, D ect.) part of the dataset. Thats why i use the attribute exposer so i can use it in the feature merger.
Without the schemasetter I only get the geometry in the GML and it does not export the other attributes. Now atleast i get the atributes of part A (requestor). Could it be that hidden attributes get removed when entering a featuremerger?
No, hidden attributes won't be removed through merging process itself.
However, supplier's attributes that conflict with requestor's attributes on their names will be removed by default, regardless of whether exposed or hidden. See also the Conflict Resolution parameter in the FeatureMerger.
Here, you should be aware that the conflict resolution rules will also be applied to list attributes.
The SchemaSetter generates a list attribute called "attribute{}" consisting of "attribute{}.name" and "attribute{}.fme_data_type". The list is the body of schema definition.
In the FeatureMerger, if supplier's "attribute{i}.name" and "attribute{i}.fme_data_type" (i = 0, 1, 2, ....) conflict with requestor's "attribute{i}.name" and "attribute{i}.fme_data_type", supplier's schema definition won't be preserved. It could be your problem.
No, hidden attributes won't be removed through merging process itself.
However, supplier's attributes that conflict with requestor's attributes on their names will be removed by default, regardless of whether exposed or hidden. See also the Conflict Resolution parameter in the FeatureMerger.
Here, you should be aware that the conflict resolution rules will also be applied to list attributes.
The SchemaSetter generates a list attribute called "attribute{}" consisting of "attribute{}.name" and "attribute{}.fme_data_type". The list is the body of schema definition.
In the FeatureMerger, if supplier's "attribute{i}.name" and "attribute{i}.fme_data_type" (i = 0, 1, 2, ....) conflict with requestor's "attribute{i}.name" and "attribute{i}.fme_data_type", supplier's schema definition won't be preserved. It could be your problem.
So in theory i could force the listname to be different and then the FeatureMerger does not see it as a conflict, am i correct? So, I tried copying the schemasetter to a new custom transformer and edit the pythonscript. So i have 2 different schemasetters.
Old:
else:
#add schema attributes to feature
nfeature.setAttribute("attribute{"+str(i)+"}.fme_data_type",type)
nfeature.setAttribute("attribute{"+str(i)+"}.name",six.text_type(att))
nfeature.setAttribute(att,feature.getAttribute(att))
i+=1;
New:
else:
#add schema attributes to feature
nfeature.setAttribute("attributes{"+str(i)+"}.fme_data_type",type)
nfeature.setAttribute("attributes{"+str(i)+"}.name",six.text_type(att))
nfeature.setAttribute(att,feature.getAttribute(att))
i+=1;
But it seems to be that this does not work in my flow.
OK... Moving the SchemaSetter after the merge did the trick.
With this flow I can now create fully dynamically generated GML
