Are you sure that the encoded geometries aren't truncated in the dbf?
Also, is there a particular reason for not using something more efficient for geometry storage?
Are you sure that the encoded geometries aren't truncated in the dbf?
Also, is there a particular reason for not using something more efficient for geometry storage?
not sure of the first part .. but i am suspecting that it truncating the geometry during the dbf conversion.
is there a efficient way to store the geometry . This is the first time i am trying this to store geometry and then use that file to recreate it .
not sure of the first part .. but i am suspecting that it truncating the geometry during the dbf conversion.
is there a efficient way to store the geometry . This is the first time i am trying this to store geometry and then use that file to recreate it .
It's difficult to give a concrete recommendation without knowing your use case, but if you want to stick with DBF as the underlying data format, you should consider using the Shapefile format, which is simply DBF with some sidecar files containing binary geometries. FME allows you to read and write directly to this format and it's very fast.
For a more modern approach you could consider using GeoPackage or SpatiaLite, both also natively supported by FME.
If the data is only to be used with FME, you could use the internal FFS format, it is very fast and supports anything that you can throw at it.
