Serialization only uses generic header with nothing more than magic bytes #151
Replies: 3 comments 2 replies
-
You are right, the C# implementations lacks means to define CRS when using the high level methods in FeatureCollectionConversions and it should be fixed at some point. Until then it looks like a valid workaround with your customized BuildHeader. |
Beta Was this translation helpful? Give feedback.
-
I recently ran into trouble using this. FGB data (e.g. files) generated using this are valid and can be opened in third party software, e.g. QGIS. However, when handled by the reference implemention in JavaScript, sometimes an error occurs. Turns out that the reason is that the geometry data is not aligned at 16 bytes bounds. My first guess was that the reason would be that not all fields in the header are filled with proper data, so I rewrote the method. But to no avail. My (ridiculous) workaround therefore is that I repeatedly generate the header, check for 16 byte alignment in the caller (of InternalBuildHeader) and that the callee fills the "Metadata" string with an increasing number of space characters until the alignment fits. Hence, the caller performs something like this:
and the callee now looks like this:
I really think maintainers should get to this. |
Beta Was this translation helpful? Give feedback.
-
Well, it's not reproducable with your code, only with mine, which was only to work around the FGB implementation not writing the CRS into the header while serialization. It's a bug in my code, actually, not yours, but it appeared in code to include a clearly missing feature. Anyway, please find below the code I took from your repo and modified it to my needs. Just call "IntSerialize" as you would call "Serialize". "_SRS" is the class internal storage of the GDAL type spatial reference system of the handled geometry data.
Okay, good to know, I'll adjust my workaround to be more parsimonious with the filling bytes, then.
Sorry, I did in no way mean any offense. What I meant was, actually: Please don't bother fixing my code. Just a humble reminder that, as you said yourself, you have something left open to do here.
|
Beta Was this translation helpful? Give feedback.
-
My workflow is loading an fgb file as a byte array, deserialize it, process the geometry (or whatever), serialize it and save the resulting byte array to disk. Doing so I find that the resulting file does not contain the WKT string nor the name meta information any longer. I found here that the header is not being enriched by the name or the CRS in the process, as these are not passed in and are lost as far as the FeatureCollection is involved in the first place.
I wonder if that is on purpose. I helped myself by copying the
BuildHeader
method into my class. The class has private fields for name and a GDAL spatial reference object ("IntSRS") that is filled during file loading (the class also processes GDAL imports such as Shapefile layers and such). During "re-serialization", I use a modified version ofBuildHeader
like this:Is something like this planned in the future, maybe by handing in name and CRS via method parameters?
Beta Was this translation helpful? Give feedback.
All reactions