<p>On Thu, May 5, 2011 at 9:42 AM, Peter Körner <<a href="mailto:osm-lists@mazdermind.de">osm-lists@mazdermind.de</a>> wrote:<br>
> Hi<br>
><br>
> I'm working heavily with the full-history-dumps. Lately I wrote a splitter<br>
> [1] that allows splitting the full-history-dump into smaller extracts and I<br>
> plan to publish some of the extracts on a GWDG mirror.<br>
><br>
> Right now the splitter uses osmium as Framework, because its xml-reader<br>
> passes the visible-flag along through the pipeline. The xml-writer I wrote<br>
> for osmium [2] is also able to write the visible-flag out.<br>
><br>
> But actually it would be nice to let the whole xml-bz2-thing be and use our<br>
> new cool pbf stuff. But unfortunately the pbf format does not support saving<br>
> the visible-flag, which is really important when working with the history.</p>
<p>There are two implementation approaches. <br><br></p>
<p>><br>
> I talked with Jochen Topf about the extensibility of out pbf-format and he<br>
> anticipated problems with the DenseInfo message. So my questions are:</p>
<p>><br>
>  - is it feasible to release a new version of the pbf<br>
>   definition, that contains a boolean visible-flag<br>
></p>
<p>Yes. If you want to create an incompatable hpbf (History PBF) format that is very similar to the existing PBF format. Encode the visible flag into the protocol buffers along the lines of Jochen's suggested patch, with a few small tweaks. Existing pbf code can support the new format with very minor changes. This would be an incompatible change because it is impossible to telling existing software to ignore nodes whose visibility is 'no'. They're there, and will be read. You'll need to indicate these files with a new required_features = "InvisibleFlag", and conforming software will reject the file.</p>

<p>>  - is it possible for an app like my splitter to add a boolean<br>
>   visible-flag to nodes, ways and relations in a pbf file, so that<br>
>   other apps like osmosis can still read the generated pbf file (just<br>
>   ignoring the visible flag)</p>
<p>Yes, but via a different mechanism. Create a new blob type: 'OSMInvisibleHistoryData', it will contain a serialized ordinary PrimitiveBlock message. In this block you'll place invisible nodes/ways/relations. Standard readers will see this block and skip right past it. Your reader will feed it to the normal pbf decoder function and have it mark those entities as invisible. You'll want to indicate these files with a new optional_feature 'ContainsInvisibleHistoryData'.</p>

<p>>  - if not: how could a pbf-file generated with the visible-flag but<br>
>   incompatible with common apps like osmosis be named, to clearly show<br>
>   that it's NO .osm.pbf file? (eg. germany.hosm.pbf or<br>
>   germany.osm.history.pbf or ..)</p>
<p>If you go with the incompatible approach, I'd name it .hpbf.</p>
<p>Which approach do you want? Or both?</p>
<p>Also, if we are going to do another revision of the format, I will use it as an opportunity to change from java package crosby.binary to osm.format.pbf. </p>
<p>And maybe add other features? CRC32?</p>
<p>What else do people want to consider putting in? Anything else that would help in recording history? Consider adding LZMA? Someone want to run a test?</p>
<p>Scott</p>
<p>><br>
> Peter<br>
><br>
><br>
> [1]<br>
> <<a href="https://github.com/MaZderMind/OpenStreetMap-History-API/tree/master/splitter">https://github.com/MaZderMind/OpenStreetMap-History-API/tree/master/splitter</a>><br>
> [2] <<a href="https://github.com/MaZderMind/osmium/tree/xml_output">https://github.com/MaZderMind/osmium/tree/xml_output</a>><br>
><br>
</p>