[OSM-dev] Filename extensions for OSM files

Matt Amos zerebubuth at gmail.com
Wed May 11 12:39:29 BST 2011


On Wed, May 11, 2011 at 12:23 PM, Peter Körner <osm-lists at mazdermind.de> wrote:
> Am 11.05.2011 13:17, schrieb Matt Amos:
>>>
>>> We should probably introduce an attribute on the<osm>  tag that says that
>>> this is a history file. Just as we are currently discussing for the PBF
>>> version.
>>
>> while we're at it, let's have a flag to indicate if the elements are
>> sorted by ID, how many prime-numbered elements there are, whether
>> there was a full moon when it was generated and what the colour of the
>> file is. i'm up for all of that as long as it's blue.
>
> history files have similar syntax as normal osm files, but very different
> semantics. A program processing a history file needs to be aware or it
>  - having multiple objects with the same id
>  - having objects that stop being existent in some point in time
>  - that have an extra information attached
>
> that way it is useful for a program to know, if a file fed into it via stdin
> will be processed fine right from the start. nobody likes processes that
> fail after 10 hours because of a missing --this-is-an-history-file flag.

it'll be far less than 10 hours before the first element with
visible="false" or multiple versions comes through. in fact, i bet
it'd happen within the first 10 lines.

all OSM files are potentially history files (e.g:
http://osm.org/api/0.6/node/1/history) - they all have the visible and
version attributes on all elements, despite that not being needed for
dealing with a snapshot. some programs may make assumptions about the
contents of OSM files, but that's for the program in question to
assert, and for the user to be aware of.

cheers,

matt



More information about the dev mailing list