Skip to main content
Hi,

 

I couldn’t figure out what’s going on with the ESRI file geodatabase writers, Here is a workbench that was set to use 2 writers ( Esri FilegeodatabaseAPI, and shape file).

 

The translation was successfully finished (21 features was written to both writers). Now when I go to ArcMAP I found that the shape file is correctly generated with 21 features on it while the feature class that was stored inside the file geodatabase API is empty.

 

What is the issue here ?

 

 

 

 

 

 

 

Here is the workbench and all of its related data, in the case of your intrested in testing this issue.

 

http://www.mediafire.com/download/9rwdwe1tk5y9hj7/UMP.zip

 

 

Regards,

 

Ahmad

 

 
Hi Ahamad,

 

 

Major reason could be that the length (number of characters) of "autocad_layer" of every feature is longer than 50.

 

The FILEGDB writer seems to reject features which have a longer string attribute value than the specified width for the destination field.

 

And also, the writer seems not to be lenient to invalid geometries, like too narrow (almost linear) polygon. It might be necessary to validate and repair the polygons before writing.

 

 

Takashi
Hi Takashi,

 

Thanks for your reply, I did some modifications on my workbench before your replay and the API writer shows the values but still there missing ones while the ArcObject writers succeeds to write all values correctly.

 

Have a look at this

 

 

 

 

 

 

Neither of the two points that you provided in your answer helps to overcome the issue, the geometry validator have repaired the polygons also reducing the name of the Autocad layer to be less than 50 characters didnt solve the issue.

 

What should I also consider in my workbench, At the beginning I thought that that the API fails to write the repaired polygons but after connecting the repaired polygon to an inspector I found that my beliefs was wrong.

 

 

 

 

Thanks,

 

Ahmad

 

 
The GeometryValidator is not all-round player, you will have to try other approaches in some cases. All depends on the actual data condition.

 

The question polygon is an aggregate, and a part is too narrow shape, like a needle. For example, this data flow could remove the "needle" part.

 


Dear Takashi,

 

Thanks for you quick response and valuable inputs and answers, Yes your right, first if no polygons was appeared in the API written features the solution will be as you mentioned in your first answer “ By reducing the name of the AutoCAD layer or by increasing the fields length”, at the same time the features will be successfully written if the writer was shape file or Arcobjects.  

 

Then if there some missing polygons the “deaggregator > Spikeremover > Tester” transformers will do the job efficiently.

 

Now I am stuck again the FME shows that the number of features written is 4678, but when I open the attribute table I found that only 3045 features are included also some polygons are missing at large scales but when I zoom in they appear correctly, I have exported the featurecalss to a new Geodatabase just to see the areas of the features (by the way Why the API file geodatabase doesn’t show the shapArea in the attribute table ?!!), but only 1650 features was exported the ones that was disappearing at large scales is missing here!!, After sorting the shape area I found polygons with negative and zero areas “check geometry and repair geometry ” fails to delete or repair them. What might be the explanation for this strange behavior?

 

 

 

 

 

 

 

Thanks in advance

 

Ahmad

 

 
The writer could reject a feature when its geometry and/or attribute value was invalid. Some warning messages might be logged in the log file.

 

Firstly see the log to check if there were rejected features.
The log shows this massage:

 

"FileGDB Writer: Failed to write Geometry to feature class 'LanduseAndRoadsPolygons_FME' with geometry type 'esriGeometryPolygon'. Dropping containing feature... Last line repeated 1432 times ".

 

 

But what about the zero value areas ?!

 

 

thanks,

 

Ahmad

 

 

 
I guess that the zero areas are shapes where the ArcGIS cannot calculate correct area in the valid precision because they are too small or narrow.

Reply