Skip to main content
  • EN

Hi all.

An I correct in assuming, that FME cannot handle non-point geometries, i.e. with multiple nodes, when some nodes have Z values, and some don't ?

I'm seeing that GeometryReplacer adds dummy Z values (0) where they're missing when importing from WKT og GeoJSON.

Is this a problem with the transformer only, or a more general problem with the handling of Z values ?

In a system we're running on FME Server, I need to replace any missing Z values with an official fixed value: -99. This is done using the 3DForcer. But if I can't control missing Z values during import, things are very problematic.

I made a small test workspace, and ran it in 2020.2 and 2022.2, and both exhibited the same behaviour.

Cheers

It does seem to handle them in the native readers and writers. If I read a table with that geometry in this is what it looks likeimageIf I then write that geometry back into a MS SQL table that missing z value is respected

image 

It does seem to handle them in the native readers and writers. If I read a table with that geometry in this is what it looks likeimageIf I then write that geometry back into a MS SQL table that missing z value is respected

image 

Interesting, so the problem lies with the transformer then.

To circumvent this buggy behaviour, I've opted to insert the official dummy Z (-99) instead of just removing them. It's not optimal, but this way I can get things working.

Interesting, so the problem lies with the transformer then.

To circumvent this buggy behaviour, I've opted to insert the official dummy Z (-99) instead of just removing them. It's not optimal, but this way I can get things working.

Did you try using -nan? If you are writing back to a MS SQL database this should give the result you expected.

 

i.e. if you put the following through a geometry replacer you will get a geometry in MS SQL without a z value for the first coordinate

LINESTRING (571385.6196 6138491.615 -nan,571392.3857 6138491.1588 109.433,571398.7318 6138488.917 109.209)

 

Interesting, so the problem lies with the transformer then.

To circumvent this buggy behaviour, I've opted to insert the official dummy Z (-99) instead of just removing them. It's not optimal, but this way I can get things working.

No. As I wrote, I opted for replacing faulty Z values instead of removing them. If I get more time later, I may look into it, but not now.

Reply


Community Stats

30,162
Posts
114,488
Replies
37,809
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.