<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>Hi Andrew,</div>
<div><br>
</div>
<div>Cap'n Proto (successor of ProtoBuffer from the guy who invented ProtoBuffer) and FlatBuffers (another ProtoBuffer succesor, by Google) have gained a lot of traction since last year. Both eliminate many if the shortcomings of the original ProtoBuffer (allow
for random access, streaming,...), and improve on performance also.</div>
<div><br>
</div>
<div><a href="https://github.com/google/flatbuffers">https://github.com/google/flatbuffers</a></div>
<div><br>
</div>
<div>Here is a comparison between ProtoBuffer competitors:</div>
<div><a href="https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html">https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html</a></div>
<div><br>
</div>
<div>In my opinion FlatBuffers is the most interesting. It seems to have very good language and platform support, and has quite a high adoption rate already. </div>
<div><br>
</div>
<div>I think that it's well worth to reconsider creating an own file format and parser for several reasons. Your concept looks well thought, it should be possible to implement a lighweight parser using FlatBuffers for your data scheme. </div>
<div><br>
</div>
<div>Regards</div>
<div>Ben <br>
<br>
<div>Von meinem iPad gesendet</div>
</div>
<div><br>
Am 06.02.2016 um 22:37 schrieb Andrew Byrd <<a href="mailto:andrew@fastmail.net">andrew@fastmail.net</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div class="">Hello OSM developers,</div>
<div class=""><br class="">
</div>
<div class="">Last spring I posted an article discussing some shortcomings of the PBF format and proposing a simpler binary OSM interchange format called VEX. There was a generally positive response at the time, including helpful feedback from other developers.
Since then I have revised the VEX specification as well as our implementation, and Conveyal has been using this format in our own day-to-day work.</div>
<div class=""><br class="">
</div>
<div class="">I have written a new article describing of the revised format:<br class="">
</div>
<a href="http://conveyal.com/blog/2016/02/06/vex-format-part-two" class="">http://conveyal.com/blog/2016/02/06/vex-format-part-two</a>
<div class=""><br class="">
</div>
<div class="">
<div class="">The main differences are 1) it is more regular and even simpler to parse; and 2) file blocks are compressed individually, allowing parallel processing and seeking to specific entity types. It is no longer smaller than PBF, but still comparable
in size.</div>
<br class="">
</div>
<div class="">Again, I would welcome any comments you may have on the revised format and the potential for a shift to simpler binary OSM formats.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Andrew Byrd</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 29 Apr 2015, at 01:35, andrew byrd <<a href="mailto:andrew@fastmail.net" class="">andrew@fastmail.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<title class=""></title>
<div class="">
<div class="">Hello OSM developers,<br class="">
</div>
<div class=""> </div>
<div class="">Over the last few years I have worked on several pieces of software that consume and produce the PBF format. I have always appreciated the advantages of PBF over XML for our use cases, but over time it became apparent to me that PBF is significantly
more complex than would be necessary to meet its objectives of speed and compactness.<br class="">
</div>
<div class=""> </div>
<div class="">Based on my observations about the effectiveness of various techniques used in PBF and other formats, I devised an alternative OSM representation that is consistently about 8% smaller than PBF but substantially simpler to encode and decode. This
work is presented in an article at <a href="http://conveyal.com/blog/2015/04/27/osm-formats/" class="">
http://conveyal.com/blog/2015/04/27/osm-formats/</a>. I welcome any comments you may have on this article or on the potential for a shift to simpler binary OSM formats.<br class="">
</div>
<div class=""> </div>
<div class="">Regards,<br class="">
</div>
<div class="">Andrew Byrd<br class="">
</div>
</div>
_______________________________________________<br class="">
dev mailing list<br class="">
<a href="mailto:dev@openstreetmap.org" class="">dev@openstreetmap.org</a><br class="">
<a href="https://lists.openstreetmap.org/listinfo/dev">https://lists.openstreetmap.org/listinfo/dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>dev mailing list</span><br>
<span><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a></span><br>
<span><a href="https://lists.openstreetmap.org/listinfo/dev">https://lists.openstreetmap.org/listinfo/dev</a></span><br>
</div>
</blockquote>
</body>
</html>