Solved

Is GeometryReplacer displacing geodb_type values?

  • 23 April 2022
  • 8 replies
  • 2 views
janet
Rank

I have a 2016 workspace that I'm upgrading to 2021.2.5.

The basic workflow is SQLExecutor -> GeometryReplacer -> Clipper with an AOI -> FileGDB.

What comes out of the DB is the geodb_type which helps to determine features get routed either the polyline or annotation feature class. GeometryReplacer is used to convert from WKT so that features can be clipped with the AOI.

 

From SQLExecutor, geodb_type has values (geodb_polyline, geodb_arc, geodb_annotation), but when it comes out of GeometryReplacer, geodb_type values are all missing. So after clipping, everything gets routed to the polyline fc, which will produce this error: "Cannot write a non-linear feature to a polyline feature class." [geometryreplacer_geodb_type.png]

 

My workaround is to use GeometryFilter to route the features + a new AttributeCreator to hard-code geodb_type values to ensure the right features are created in FileGDB, rather than rely on geodb_type values. [geometryfilter.png]

 

I've tried to insert completely new transformers with no impact. I made a wks from scratch and that works. [geometryreplacer_works.png] So there must be something else I'm missing that displacing geodb_type values.

icon

Best answer by mark2atsafe 28 April 2022, 17:19

View original
3 Attachments

8 replies

redgeographics
Rank
Userlevel 5
Badge +25

It does seem like the GeometryReplacer is overwriting the geodb_type attribute, but to be absolutely certain, can you inspect that value before it goes into the GeometryReplacer?

janet
Rank

It does seem like the GeometryReplacer is overwriting the geodb_type attribute, but to be absolutely certain, can you inspect that value before it goes into the GeometryReplacer?

geometryreplacer_beforeCertainly... From the SQLExecutors, there are values in geodb_type.

redgeographics
Rank
Userlevel 5
Badge +25

geometryreplacer_beforeCertainly... From the SQLExecutors, there are values in geodb_type.

Could you try upgrading the GeometryReplacer? If that's possible, it should be included in the "Upgradeable transformers" category in your workspace navigator.

janet
Rank

geometryreplacer_beforeCertainly... From the SQLExecutors, there are values in geodb_type.

The non-upgraded GeometryReplacer is the one that doesn’t do anything to geodb_type. The upgraded form is what started this problem in this workspace…

redgeographics
Rank
Userlevel 5
Badge +25

geometryreplacer_beforeCertainly... From the SQLExecutors, there are values in geodb_type.

Gotcha. Hmmm, it does sound fishy to me, I wonder if @mark2atsafe​ can shed some light on this.

mark2atsafe
Rank
Userlevel 4
Badge +25

geometryreplacer_beforeCertainly... From the SQLExecutors, there are values in geodb_type.

It sounds like either...

 

a) this is deliberate, because the output from the transformer is unknown and we don't want you to replace a line with a point, yet have it still tagged as a line. In this case, it's unlikely that we'd change it back.

 

b) this was accidental in a recent update (the transformer was totally rewritten in 2021). It's more likely we'd change this back.

 

To be honest, I think it's more likely to be "a". The solution would be to use the fme_ geometry attributes instead - or the GeometryFilter transformer - and not rely on the source format attributes.

 

But I will check with the dev team and get back to you @janet​ and @Hans van der Maarel​ 

mark2atsafe
Rank
Userlevel 4
Badge +25

I've filed this with our developers as FMEENGINE-73204

However... the more I think about this, the more I think it was intentional.

The transformer acts alone from the rest of the workspace. It knows that a feature is a polygon and tags it with fme_geometry = fme_polygon. But it doesn't understand writers and doesn't know whether geodb_type is correct. Therefore it simply removes it.

If the developers confirm this, I've asked them to update the documentation to include this information. What it means for you is that we must find a workaround. Ideally, you would use the fme_geometry and fme_type attributes instead, and maybe even the GeometryExtractor transformer.

An alternative is to rename the attribute. If you renamed it to my_geodb_geometry then I'm sure the GeometryReplacer would not delete it. Then you could simply rename it back to geodb_geometry.

janet
Rank

I've filed this with our developers as FMEENGINE-73204

However... the more I think about this, the more I think it was intentional.

The transformer acts alone from the rest of the workspace. It knows that a feature is a polygon and tags it with fme_geometry = fme_polygon. But it doesn't understand writers and doesn't know whether geodb_type is correct. Therefore it simply removes it.

If the developers confirm this, I've asked them to update the documentation to include this information. What it means for you is that we must find a workaround. Ideally, you would use the fme_geometry and fme_type attributes instead, and maybe even the GeometryExtractor transformer.

An alternative is to rename the attribute. If you renamed it to my_geodb_geometry then I'm sure the GeometryReplacer would not delete it. Then you could simply rename it back to geodb_geometry.

>> An alternative is to rename the attribute. If you renamed it to my_geodb_geometry then I'm sure the GeometryReplacer would not delete it. Then you could simply rename it back to geodb_geometry.

 

I like this suggestion. Seems like a better workaround. Thanks!

Reply


Community Stats

28,717
Posts
109,495
Replies
36,561
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.