Skip to main content
  • EN
Hi all.

 

 

I have a question.

 

I don't think i've seen this before, but maybe any of you knows what, if at all, i am missing here.

 

 

I read a set from a oracle spatial. These are all area's.

 

I do a spatial query using lines as supplier.

 

All is well, the inspector shows results as they should be.

 

 

But when i try to write a polygon shape file, it insists there are a huge number of lines and arcs. A larger number of lines/arcs then the input too.

 

In the inspector i see conflicting information on the objects:

 

 

 

As you can see in the picture it relates the area objects with line /arc objects and puts this in a list. On the bottom you see appear SHAPE_Geomtery....this is the supplier geometry. It should not be there as far as i know and have previously experienced.

 

Espescially when there are actually only area's in the selected data.

 

 

From the objects in this pictures most are therefore rejected.

 

I have never seen this before and i am stumped. (or the dentist hurt me too much yesterday..and i incured brain damage or something...i got a tooth pulled...lol)

 

 

This does not occur if i buffer the supplier lines with a small buffer, turning them in area's. The conflicting info dissapears.

 

 

This is FME2014 sp2.

 

 

Anyone knows what could be causing this?

 

 

 

Thanks for any attempt at answering. :)

 

 

 

 

 
Hi Gio,

 

 

The "de9im" indicates that the relationship between the selected area and a line is topologically equivalent to this image.

 

 

Your question is "why did the SpatialRelator detect this relationship even though the area doesn't cross with any lines?" ?

 

 

Takashi
But, "CROSSES" is not defined for Area vs. Area.

 

If you set "CROSSES" to the Tests to Perform parameter of the SpatialRelator, naturally it will no detect any relationships between buffers of lines (areas) and the polygons...
I must have been pretty uncler in my question.

 

Im not talking about realtional criteria at all. lol.

 

 

 
what i ment is that the line/arcs wich are supplier seem to be passed to the output along with the areas.

 

If i test this with a geometryfilter it says the output is area only.

 

If i try to write shapepolygon, it starts rejecting lines/arcs.

 

 

The inspector shows the correct desired reuslt, wich are areas only.

 

Teh oicture is correct result. Upon writing though, it rejects a lot of those areas and says they are lines/arcs.

 

I understand they are related, its what i tested for, but they should not be passed to the output as geometry, only their attributes.
I got it :)

 

 

Looks like the SHP writer will determine the geometry type of features seeing SHAPE_GEOMETRY attribute, if it exists.

 

See also this page.

 

FME Readers and Writers > Esri Shape Reader/Writer > Feature Representation (http://docs.safe.com/fme/2015.0/html/FME_Desktop_Documentation/FME_Desktop_Help.htm#../Subsystems/FME_Readers_Writers/Content/shape/Feature_Representation.htm)

 

 

This behavior has not been changed in FME 2015.0.

 

I'm not sure whether it's an intended behavior. But, in my personal opinion, I think any writer should always determine geometry type of features based on the actual structure, regardless of predefined format attribute values.

 

 

 

In the interim, removing "SHAPE_GEOMETRY" before writing is a workaround.
More tested. The unexpected rejection seems to happen only if "SHAPE_GEOMETRY" contains one of:

 

shape_arc

 

shape_polyline

 

shape_polylinem

 

shape_polylinez

 

and also the actual shape is polygon.

 

 

If it contains other value (e.g. "shape_point"), the SHAPE writer can determine the geometry type based on the actual shape (i.e. polygon) of features.

 

This may be a kind of bug. I'll inform it to Safe support.

 

Hi Takashi,

 

 

 

That is exactly what i did. As it was clear by studying inspector outputs, that al rejected objects had a SHAPE attribute, i exposed and then removed this attribute. (without exposure i could not remove it, and exposure is manual as one cannot choose this attribute from any list) Now all objects pass (without the need to buffer the supplier lineshape).

 

(well i did find a point posing as a area in the database, a clear error wich i reported to the responsible colleague...ehehe)

 

 

What surprises me about this is that i have done a zillion spatialtrasformations, and never have encountered this problem before.

 

 

I think this is a error/bug. This should not be, this attribute should not be passed i think.

 

 

You did report it to safe i understand?

 

 

Thanks for your efforts.
Yes, I already reported it to Safe yesterday.

 

After receiving their answer, I'll share that with you, here 😉
P.S. You can use the BulkAttributeRemover to remove a hidden attribute without exposing, if you know the name or its unique pattern. FYI
Hi Gio,

 

 

I got an answer from Safe.

 

"Unfortunately this is a known issue and it works by design - the format attributes SHAPE_GEOMETRY, igds_type, etc. will take precedence over fme_type and fme_geometry.  The problem arises whenever a reader and writer are the same and the geometry changes within the translation.  I'm told that it would be very difficult to change this."

 

 

It would not be fixed immediately, unfortunately...

 

..it works by design .. should be ..it is flawed by design..

 

 

Anyway, i have a SQL-creator to acces a database and a shape reader. Output is shape. Though they are same type they are definitely not the same "feature-type".

 

 

Sql creator is not a reader; "reader is same as writer" ...do they mean reader-type?en.

 

 

If i enterd a dummy reader of different type, then it should not happen?? i could try of course...someday.

 

 
In my observation, some transformers that change geometry type remove the format attribute storing geometry type automatically. e.g. GeometryCoercer.

 

The issue seems to occur typically when the format attribute was merged from one to another, as you experienced.

 

So I think the Safe's explanation is not enough.

Reply


Community Stats

30,108
Posts
114,295
Replies
37,744
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.