Hi Colin,
> On 08 Feb 2016, at 13:07, Colin Smale <[email protected]> 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.
Andrew
_______________________________________________
dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/dev
