Replies: 1 comment 1 reply
-
Hi @bruno-ga, you are right the feature properties encoding deserve better specification. The length prefix for strings and other length variable types should always be 32 bits unsigned int. Initially I tried to encode properties using a generic flatbuffers schema but that ended up being so space wasteful that I came up with the current simple but custom encoding but it ended up specified by implementation. The geojson2fgb.cpp is not well maintained and I agree it looks suspect, it should read 4 bytes because of the above. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Feature properties are at least a bit structured in the sense that each property is prefixed by the column index and, out of the column, one can get its type and, in most cases, infer the size of the specific property (important to be able to skip to the next one).
Now both for string and binary, they might have an arbitrary size. The C++ sample code (geojson2fgb.cpp) just prepends the size to the actual data which is a sensible way to do this. That code has a bug, BTW:
This code first checks if the length of the string fits in 32 bits. Then, if it does, it proceeds to use the first 2 bytes (?) of the length as the actual length of the property.
This most likely is not an issue as string properties with more than 65535 characters are unlikely but the code is still wrong.
Anyway, this is just to say that based on the code, it is difficult to infer if the expectation is that the size is 16 or 32 bits. What should it be? I assume binary data and json data also have size prefixes, right?
Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions