[OSM-dev] Simpler binary OSM formats
andrew at fastmail.net
Tue Feb 16 12:34:28 UTC 2016
> On 08 Feb 2016, at 13:07, Colin Smale <colin.smale at xs4all.nl> wrote:
> There are discussions going on which may change the underlying data metamodel. I am thinking of support for polygons/areas as primitive types and multi-valued keys. Although the model has been stable since API0.6 it would not be prudent to preclude changes in the future.
Thanks for pointing this out. You are right that we should consider how any format can be adapted to such changes in the OSM data model.
Adding a new primitive type is in fact very straightforward, because every vex block contains only entities of a single type. We would simply introduce a new block type that would have its own distinctive marker in the block header (probably P or A instead of N, W, or R that are currently used for Nodes, Ways, and Relations). Existing readers would not recognize this type and would either skip these blocks or fail reporting an unrecognized block type. These area blocks would be structured similarly to all the others.
Multiple tag values are also straightforward to support. Nothing in the current vex format specification prevents the same key from appearing more than once, or separator characters appearing in the values for example. There is no practical limit on the length of value strings.
I am confident that the vex format can readily adapt to these anticipated changes to the OSM data model. Adapting would create a new, incompatible version of vex, but a few simple additions to the specification would make readers certain to detect incompatible extensions and fail gracefully.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev