Not sure but could be that you are looking for the coordinatesystemsetter?
Not sure but could be that you are looking for the coordinatesystemsetter?
Well, the input data have a set coordinate system, and the reprojected have that reset to the target system (I assume). Wouldn't it be adding what's already there ?
Not sure but could be that you are looking for the coordinatesystemsetter?
Nope, sorry. Didn't change anything.
Nope, sorry. Didn't change anything.
Are you using FME or the underlaying db to define the output coordinate system? as mentioned in the article
That's the article I started out with :-)
Hi,
I'm uploading a workspace + a Shape table with test data + a SQL query script which includes the target table definition and a sample query. The target is an MS/SQL, which you'll have to provide (Express will work, I think).
The table has four geometry columns, two pairs of geometry + center point in each projection.
The query shows that the SRID is 0 as-is for all four geometry columns.
The query also shows, the if saved with an non-zero SRID (the "wkt" columns), the SRID is non-zero upon request.
Cheers
Lars I.
I would contact Safe for this issue
http://www.safe.com/support/
I have done a similar process before.
The only way I could get this done is writing the record with a single geometry (and SRID).
Then writing the other geometry using a writer in UPDATE mode (or a DatabaseUpdater transformer) adding the second geometry (with a different SRID) to the existing record.
I would contact Safe for this issue
http://www.safe.com/support/
Yes, please do contact support. I looked into the issue but I don't see any existing reports of this and nothing from our developers. The only thing I saw was when the SRID was not in the FME coordinate systems and didn't have an EPSG number - but I think that's unlikely to be an issue for all four of your coordinate systems. I think we'll need our SQL Server developers to comment on the issue.
Mark
I haven't tried different SRIDs for multigeometrycolumns.
wkt can't pass SRID's. Afaik only extended Wkt wich fme does not use. In fact fme uses old one (at least in 2015)
Either build SDO_GEOmetry strings. Wich i did to by-pass the wkt extractor limitation using external (not in database) geometries , tough not easy.
Better yet use a update function.
Run it after it is written to the tables.
UPDATE tabelname T
SET T.geometryname.SDO_SRID = YOUR_SRID
WHERE T.geometryname IS NOT NULL
I have the same issue in SQL Server (FME 2017 & 2018).
I have a point feature type. I can write it with proper coordinate system as single geometry.
When I try the multiple geometry (the modified geometry has the same coord sys) the SRID becomes 0.
I tried to set the coordinate system at several points (writer parameter, CoordinateSystemSetter after the reader, before the writer, after the GeometryPropertySetter, before the Aggregator) without any success.
I ended up with the
update <table> set <column1>.STSrid=<SRID>, <column2>.STSrid=<SRID>;
SQL Command After the Translation.
