On Tue, Nov 20, 2012 at 1:09 PM, Jochen Topf <span dir="ltr"><<a href="mailto:jochen@remote.org" target="_blank">jochen@remote.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Nov 20, 2012 at 06:57:50PM +0100, Stephan Knauss wrote:<br>
> Frederik Ramm writes:<br>
><br>
> >I really don't mind *how* it's done but I would really love to<br>
> >have one agreed way to place a timestamp in a PBF instead of<br>
> >everyone rolling their own.<br>
><br>
> I would prefer epoch timestamps. That's a widely accepted way of<br>
> storing time information without the need to worry about time zones<br>
> and such.<br>
<br>
</div>The other timestamps in PBF files (at all the objects) use 64 bit integers with<br>
seconds since epoch. So it would make sense to use the same format.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Not quite. The granularity of timestamps can go down to the milliseconds.</div><div><br></div><div><a href="https://github.com/DennisOSRM/OSM-binary/blob/master/src/osmformat.proto#L96">https://github.com/DennisOSRM/OSM-binary/blob/master/src/osmformat.proto#L96</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
</div>You can have optional fields in protobuf, but unfortunately this doesn't<br>
help us in this case. There are two ways nodes can be stored in PBF files:<br>
as a series of "Node" objects or as "DenseNode" objects. "Node" objects<br>
have required fields "lat" and "lon". We could change this to be optional.<br>
There would be a has_lat() or has_lon() call to check for this.<br>
<br>
Unfortunately in most cases the more space efficient "DenseNode" objects are<br>
used. In this case the latitude and longitude of all nodes of a block are<br>
stored in a special delta encoding. This doesn't allow for optional fields.<br>
As far as I can see we could either add a boolean for each node in a block that<br>
defines whether the coordinate field is valid or use a special value for an<br>
invalid coordinate.</blockquote><div><br></div><div>Correct. There is no way in the current DenseNodes format to encode 'no value' for a latitude or longitude. Changing the message buffer to include, (say) a boolean array for the hasLatitude()/hasLongitude() would be a breaking format change, and would add about 18-40 bytes to each block of 8000 nodes. </div>
<div><br></div><div>How many nodes in the planet lack a latitude or longitude? Using a MAXINT encoding will cost about 8 bytes for each missing latitude or longitude.  It's possible to reduce this to 2-3 bytes, but the format gets uglier/hackier. IMHO, probably not worth that cost.</div>
<div><br></div></div>