[OSM-dev] Simpler binary OSM formats

Colin Smale colin.smale at xs4all.nl
Mon Feb 8 12:07:35 UTC 2016

On 2016-02-08 12:45, Andrew Byrd wrote:

> Hello Benjamin, 
> I was aware of Cap'n Proto, but thanks for pointing out FlatBuffer. I've studied this system and considered how it might be useful for OSM data exchange. Here are my impressions: 
> 1. Each FlatBuffer message does indirection through a table "to allow for format evolution and optional fields". The basic OSM data model is quite stable at this point and to my knowledge evolves only through the introduction of different tag strings. Unlike existing formats, I'd like vex to be extremely simple and non-extensible so developers can easily and completely support reading or writing it. I would hesitate to devote space in every serialized entity to unused extensibility features.

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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20160208/f5fb014f/attachment.html>

More information about the dev mailing list