[OSM-dev] Timestamp in PBF files

Scott Crosby scott at sacrosby.com
Wed Nov 21 23:18:38 GMT 2012


On Wed, Nov 21, 2012 at 5:26 AM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> On 11/21/2012 11:50 AM, marqqs at gmx.eu wrote:
>
>> OK, this seems to be consensual: PBF id 18 in the header block for a
>> signed int UNIX timestamp value.
>>
>
> In both his messages, Scott had suggested PBF id 18 for a signed int epoch
> value of the file creation, not for a signed int epoch value of the
> replication state.
>
> It would probably be premature to call this a consensus for a replication
> state timestamp at PBF id 18.
>
>
I think for Frederik's immediate needs, we should add a have a field called
osmosis_replication_timestamp or osmosis_replication_state = 32, which
contains a submessage containing a replication timestamp and other
replication data that he feels is appropriate.

As for the timestamp =18 field, Dennis, what was your intended use of this
field?  Marqqs, what is the intended use of your timestamp
optional_features field?

By this, I mean, what semantics are you attaching to these timestamps. I
think its perfectly reasonable to have several timestamp fields, perhaps:
   The timestamp the file was generated.
   The state needed to resume replication of an extract/planet (which
contains an internal timestamp)?
   The timestamp of the when the file was extracted/excerpted?

If you two could give me a better idea of what your timestamps are used
for, I could advise on how we can try to integrate them into one or more
standard timestamp fields. And after that, we can then figure out how we
might want to assign timestamps to field names/ids --- keeping in mind
prior uses of those field names and numbers.

Thoughts,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20121121/2da507ac/attachment.html>


More information about the dev mailing list