[Tilesathome] Tileset files

[Matthias Julius]

spaetz <osm at sspaeth.de> writes:

> On Tue, Sep 16, 2008 at 08:47:49AM -0400, Matthias Julius wrote:
>> > Is this really worth the bloat? We know who uploaded a tileset and
>> > we know when it was rendererd.
>>  How do you know when it was rendered?  Does the server look at the
>> file dates of the PNG files?
>
> The client sets the png mtime to the download date of the .osm
> file. The tilesetfile mtime is currently not set to a specific time
> (but usually it's only within 1-2h later) but it could be set to the
> api download time or the render time or whatever.
>
>> > I am not opposing it. Someone just needs to adapt all the tools
>> > that work with it (mod_tah.c, server, client) to allow for that
>> > and allow for a gradual switchover too. Can it be done? yes. Does
>> > it require effort and will destabilize things even more for a
>> > time? likely.
>>  I was proposing to put that data at the end of the file.  So, the
>> last offset in the index would point to the start of the meta data
>> instead of the end of the file.  This way current tools will just
>> ignore it and it is easy to find for tools that are aware of it.
>> They just need to read from the last offset to EOF.
>
> mmh, besides that it feels a bit hackish and ugly to distribute meta
> data before AND after the tile data, this would be feasable. If not
> too much effort, I'd rather bump the file version number though and
> keep all metadata in one place.

If the number of zoom levels in a tileset file remains fixed at 6
there is no need for any meta data to be before the tile data.  Only
the file version needs to be in the header.  If the number of zoom
levels is variable this number needs to be stored in the header as
well.  But, I wouldn't call that meta data.  Of course, this would
break compatibility with the current format.  The uid that is
currently stored in the header does not need to be there if there is a
meta data section.

To avoid having to change the file format version every time someone
thinks another piece of information would be useful to store in a
tileset file there are a couple of possibilities:

1. <header> <offset to index> <meta data> <index> <tile data>
2. <header> <index> <meta data> <tile data>
3. <header> <index> <tile data> <meta data>

I prefer the last one.  It remains compatible with the current format
(I know, I'm repeating myself.), writing of meta data is simple (just
write at the end of the file) and reading is simple, too (just read from
last offset to EOF).

>
> Feel free to design v2 of the tileset file format. I'll try to adapt
> the server side then to use it.

In which form should we store meta data?  Someone suggested XML, but I
would like to avoid that.  The simplest form is probably the internet
header format (RFC 822) limited to single lines.

Better ideas?

Matthias