On Tue, Jan 28, 2014 at 11:11 AM, Peter Körner <osm-li...@mazdermind.de> wrote: > Am 28.01.2014 03:18, schrieb Matt Amos: >> On Fri, Jan 24, 2014 at 2:56 PM, Peter Körner <osm-li...@mazdermind.de> >> wrote: >>> What do you think about adopting the osmium-naming-scheme for history files? >> >> personally, i think it's misleading >> [...] >> in the case of .osm files, they're all potentially history files, and >> the file format does not change depending on whether multiple versions >> are present for a single ID or not. > > History-Files carry an extra attribute (bool visible) that distinguishes > them from regular osm files.
all .osm files can carry the visible attribute, and they're present in all responses from the API. they are only elided from the "current" planet dump because they all have the value "true", so would simply be a waste of space. to be clear: the presence of the visible attribute does not mean the file contains multiple versions with the same ID. > Also it's not only about the parser. [...] > So from a data-user point of view it does not matter if the format is > actually-quite-similar, as long as there are separate programs and tools > required to handle the two types of file, they are actually different. the "current" planet is a strict subset of the "history" planet - anything which can load and process a "history" planet file should be able to process the "current" planet. also, it is trivial to turn a "history" planet into a "current" planet by discarding old versions and deleted elements. > I'd compare it more to tiff/aiff. While they are actually quite similar > from a file-format point of view, no one would argue that audio-files > and image-files should be handled as if there were no difference. i would agree that audio files and image files are completely different :-) but that is not the case with "history" and "current" planet files - as i've said above, the former is a strict superset of the latter, so the comparison to tiff/aiff is misleading. i can't think of a good comparison - the best one i've thought of so far is one version of HTML compared with a previous version, and programs which understand only previous versions will ignore some elements of a later version file. >> whether something is a "history" >> osm file or a "current" osm file is a matter of the content - so >> wanting a different extension is a bit like wanting .png for >> truecolour images and .pgr for greyscale images (in the same PNG >> format). > The main difference here is that all applications capable of reading png > MUST be capable of reading pgr as well. That's not true for osm/osh > applications. > > Also the tasks you can perform on both file formats are the same > (display, crop, combine, ...). This is also not true for osm/osh files. > One can import both into a database but the database-format required and > the actions possible on those databases are quite different. indeed, the analogy with image files was not good. however, there are tasks that one can perform on osm files regardless of whether they contain multiple versions with the same ID - one can pull out elements matching certain tags & attributes, perform transformations on the basis of tags & attributes, reproject nodes or extract those within certain areas, etc... >> having said that, it would seem reasonable to add a flag to >> the document element to indicate whether the .osm file is a special >> case, having a single version for each ID, as many programs seem to >> rely on this assumption and it would be better to be able to check it. > Isn't that already implemented via the required_features header of > pbf-files? > > See > <https://github.com/joto/osmium/blob/master/include/osmium/output/pbf.hpp#L880> > for a reference. no, actually, that flag has a different meaning. setting "HistoricalInformation" in the PBF header simply means that some elements may be deleted (have visible="false"). one can create a conforming file, with all elements having visible="true", and yet still have multiple versions for the same ID. to correct this, PBF should probably deprecate "HistoricalInformation"[1] and have a header field "CurrentInformationOnly", which indicates that *both* there are no visible="false" elements and no two elements of the same type share an ID. and our XML should probably have the same attribute on the header. cheers, matt [1]: one could simply change what "HistoricalInformation" meant, but that runs the risk of already-written (and previously conforming) files becoming non-conforming, which will be confusing. _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
