Skip to main content
Solved

FME cannot handle mixed-Z node in a single feature ?

lifalin2016
Contributor
Forum|alt.badge.img+29

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

Best answer by ebygomm

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 

View original
-- Cheers, Lars I.
Did this help you find an answer to your question?

4 replies

ebygomm
Influencer
Forum|alt.badge.img+31
  • ebygommInfluencer
  • Influencer
  • Best Answer
  • March 28, 2023

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 

lifalin2016
Contributor
Forum|alt.badge.img+29
  • lifalin2016Contributor
  • Author
  • Contributor
  • March 30, 2023
ebygomm wrote:

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.

-- Cheers, Lars I.
ebygomm
Influencer
Forum|alt.badge.img+31
  • ebygommInfluencer
  • Influencer
  • March 30, 2023
lifalin2016 wrote:

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)

 

lifalin2016
Contributor
Forum|alt.badge.img+29
  • lifalin2016Contributor
  • Author
  • Contributor
  • March 30, 2023
lifalin2016 wrote:

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.

-- Cheers, Lars I.

Reply


Most helpful members this week

Community Stats

30,859
Posts
116,996
Replies
38,689
Members
Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie 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.