Which database are you using and how are the geometries stored?
One solution could be to cast both geometries to e.g. WKB and then use two separate GeometryReplacers to extract the geometries. Something like (pseudo-code):
select
as_binary(t1.geom) as geom1,
as_binary(t2.geom) as geom2
from
mytable1 t1 join mytable2 t2 on t1.id=t2.id
Then expose "geom1" and "geom2" and send them to the GeometryReplacer as OGC Well-Known Binary.
Which database are you using and how are the geometries stored?
One solution could be to cast both geometries to e.g. WKB and then use two separate GeometryReplacers to extract the geometries. Something like (pseudo-code):
select
as_binary(t1.geom) as geom1,
as_binary(t2.geom) as geom2
from
mytable1 t1 join mytable2 t2 on t1.id=t2.id
Then expose "geom1" and "geom2" and send them to the GeometryReplacer as OGC Well-Known Binary.
@david_r oracle sql says as_binary invalid identifier
as_binary
Why do you need to use the SQLExecutor transformer and not an Oracle Spatial reader or the FeatureReader.
In your case the SQLExecutor seems to complicate matters only.
Why do you need to use the SQLExecutor transformer and not an Oracle Spatial reader or the FeatureReader.
In your case the SQLExecutor seems to complicate matters only.
It's pretty handy if you need to join several tables and haven't got the option of creating a view in the database.
@david_r oracle sql says as_binary invalid identifier
as_binary
It's pseudo-code, you'll have to replace that with whatever your backend supports.
Why do you need to use the SQLExecutor transformer and not an Oracle Spatial reader or the FeatureReader.
In your case the SQLExecutor seems to complicate matters only.
i extractring the data by joining many tables. i use oracle spatial.
@david_r
my database is oracle spatial
Why do you need to use the SQLExecutor transformer and not an Oracle Spatial reader or the FeatureReader.
In your case the SQLExecutor seems to complicate matters only.
OK, I can see the point.
But in this example I would use two SQLCreators (not SQLExecutors), each with a query containing 1 geometry.
No need to de-aggregate afterwards.
OK, I can see the point.
But in this example I would use two SQLCreators (not SQLExecutors), each with a query containing 1 geometry.
No need to de-aggregate afterwards.
Not sure I follow. You mean doing the join in the workspace rather than in the database?
Not sure I follow. You mean doing the join in the workspace rather than in the database?
Yes, if needed. But according to the question, two geometries are read, aggregated by the read and afterwards de-aggregated to be used separately. If used separately, why join in the first place?
Yes, if needed. But according to the question, two geometries are read, aggregated by the read and afterwards de-aggregated to be used separately. If used separately, why join in the first place?
Ah, I see. I must admit I didn't take the "aggregate" bit literally in this context.