<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>One more question:</div>
<div style="font-family: -webkit-standard;"><font face="Calibri,sans-serif">4) The documentation says: "</font><span style="color: rgb(37, 37, 37); font-family: sans-serif; background-color: rgb(255, 255, 255);">The current serializer (</span><a href="http://wiki.openstreetmap.org/wiki/Osmosis" title="Osmosis" style="color: rgb(11, 0, 128); font-family: sans-serif; text-decoration: none; background-image: none;">Osmosis</a><span style="color: rgb(37, 37, 37); font-family: sans-serif; background-color: rgb(255, 255, 255);">)
preserves the order of OSM entities, and tags on OSM entities."</span></div>
<div><span style="color: rgb(37, 37, 37); font-family: sans-serif; background-color: rgb(255, 254, 254);"> What would be the downside if this order was lost (when the FileBlocks are recreated in a custom spatial order)?</span></div>
</div>
<div><span style="color: rgb(37, 37, 37); font-family: sans-serif; background-color: rgb(255, 254, 254);"><br>
</span></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">Von: </span>Benjamin Stadin <<a href="mailto:benjamin.stadin@heidelberg-mobil.com">benjamin.stadin@heidelberg-mobil.com</a>><br>
<span style="font-weight:bold">Datum: </span>Dienstag, 5. Januar 2016 um 17:32<br>
<span style="font-weight:bold">An: </span>"<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a>" <<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a>><br>
<span style="font-weight:bold">Betreff: </span>[OSM-dev] OSM PBF and spatial characteristics of blocks<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I’m thinking about a design for an efficient storage container for OSM PBF (planet size data, minutely updates), for the purpose of TileMaker as well as for an internal application. </div>
<div><br>
</div>
<div>One thing I stumbled on is the usage of the bounding boxes within OSM PBF. The documentation [1] does not clarify on the spatial characteristics of the individual FileBlocks. Some questions:</div>
<ol>
<li>Is it correct that there is exactly one HeaderBlock in a .pbf file? If so, the BBOX defined within the HeaderBlock defines the whole region of the .pbf export?</li><li>What are the spatial characteristics of an individual FileBlock within the FileBlocks sequence? Is a FileBlock generated by any kind of spatial ordering? For example, is it save to assume that all content is very dense / close to a region of the world?
Or can this be controlled when creating a .pbf? If there was a spatial loose relationship, it would allow to relate FileBlocks to map „tile“ regions (a FileBlock may obviously relate to several „tiles“, but would be fine as long as the blocks relate to a certain
region for most of it’s content)</li><li>There is a commented BBOX definition within the PrimitiveBlock. What remains to be done to to enable this proposed BBOX extension? I’d have the same question about this BBOX as with my second question.</li></ol>
<div><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre;">message</span><span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);"></span><span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre;">PrimitiveBlock</span><span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);">
{</span></div>
<div> …. </div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>// Proposed extension: </div>
<div> <span class="Apple-tab-span" style="white-space:pre"> </span>//optional BBox bbox = 19;</div>
<div>}</div>
<div><br>
</div>
<div>I’d add an additional parse step to create this spatial relationship, if there is no spatial relationship yet or the spatial characteristics are not „good enough“. </div>
<div><br>
</div>
<div>~Ben</div>
<br>
<div>[1] <a href="http://wiki.openstreetmap.org/wiki/PBF_Format">http://wiki.openstreetmap.org/wiki/PBF_Format</a></div>
</div>
</div>
</span>
</body>
</html>