<div dir="ltr"><div><div>Looks pretty similar to o5m, except tags key=value are not round-buffered.<br><br></div>As a further extension, it would be nice to have the ability to have blocks of fixed size. <br>Just write nodes one by one while you haven't full-fill byte buffer.<br></div><div>For extremely big relations (which are larger than one block) it's possible to mark two adjacent blocks as connected, but there should be a few of them.<br></div><div><br></div>It would help to read write and seek over files.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-07 3:47 GMT+05:00 Stadin, Benjamin <span dir="ltr"><<a href="mailto:Benjamin.Stadin@heidelberg-mobil.com" target="_blank">Benjamin.Stadin@heidelberg-mobil.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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" target="_blank">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" target="_blank">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><div class="h5">
<div><br>
Am 06.02.2016 um 22:37 schrieb Andrew Byrd <<a href="mailto:andrew@fastmail.net" target="_blank">andrew@fastmail.net</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Hello OSM developers,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>I have written a new article describing of the revised format:<br>
</div>
<a href="http://conveyal.com/blog/2016/02/06/vex-format-part-two" target="_blank">http://conveyal.com/blog/2016/02/06/vex-format-part-two</a>
<div><br>
</div>
<div>
<div>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>
</div>
<div>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><br>
</div>
<div>Regards,</div>
<div>Andrew Byrd</div>
<div><br>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>On 29 Apr 2015, at 01:35, andrew byrd <<a href="mailto:andrew@fastmail.net" target="_blank">andrew@fastmail.net</a>> wrote:</div>
<br>
<div>
<div>
<div>Hello OSM developers,<br>
</div>
<div> </div>
<div>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>
</div>
<div> </div>
<div>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/" target="_blank">
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>
</div>
<div> </div>
<div>Regards,<br>
</div>
<div>Andrew Byrd<br>
</div>
</div>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org" target="_blank">dev@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/dev" target="_blank">https://lists.openstreetmap.org/listinfo/dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>dev mailing list</span><br>
<span><a href="mailto:dev@openstreetmap.org" target="_blank">dev@openstreetmap.org</a></span><br>
<span><a href="https://lists.openstreetmap.org/listinfo/dev" target="_blank">https://lists.openstreetmap.org/listinfo/dev</a></span><br>
</div>
</blockquote>
</div></div></div>
<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Thank you for your time. Best regards.<br>Dmitry.</div></div>
</div>