[Tilesathome] Tileset as one file v2

[Matthias Julius]

spaetz <osm at sspaeth.de> writes:

> I just read through the tileset as one file v2 description on the
> wiki. A couple of comments:
>
> - Looks ok in general

Good.

>
> * ''userid'' is set twice, once in the beginning of the file and once
> as "metadata" in the end. Do we really need to set it twice? I'd
> rather not.

Techically, the userid doesn't need to be in the header.  That's why
it is in the meta data section.  I left it in the header for
compatibility reasons.  This way v2 is a pure extension of v1 and v1
is a special case of the v2 format (except that v1 has no meta data).

>
> - we have the base zoom level at the end and the number of zoom levels
> and the first zoom level in the beginning of the file. Is this
> inconsistency needed? Why not put the base zoom level in the last byte
> at the beginning of the file too?  - Also, I am still a bit sceptical
> about that "size" data. It does mean that the tile serving module
> needs to do more work for each served tile even if t@ is never going
> to need it. Why can't we just skip this and those who want to skip
> levels just leave them as "0" (unknown) tile in their tileset files
> (e.g. this means 5*4 bytes wasted, if mapnik people want to start a
> tileset at z14 (containing 4x4 tiles)).

Maybe the pain killers have thrown you off here, too. ;-)

The first zoom level is not in the header.  The header contains only
information needed to interpret the file (besides the userid).  That
is the size of the top level and the number of levels.  Everything
else is in the meta data.

>
> - OSM-Timestamp can be easily be shown via tilesetfile mtime, for
> example. So while I don't mind this as metadata, it does blow up our
> disk usage (although it's unclear whether the time stamp is recorded
> as a string or as a binary number). This should be clarified at least.

mtime might get lost when copying a file across different systems or
media like HTTP.  I think it is better if all relevant information is
contained in the file.  This is worth the 25 bytes it will take, IMHO.

The beginning of the meta data section states that it consists of
lines of plain text.  I think this excludes a binary representation of
the data.  Do I need to clarify this a bit more?

> - Generally it remains unclear how "tile, x,y,zoom" info is stored as
> metadata, string or binary number? Also for layer, do we store
> "captionless" in each tileset file, or the server internal layer
> number?

See above.  Everything is stored in plain text strings.

I didn't even know the server is maintaining an internal layer
number.  And the client certainly won't know what it is.  So I meant
the layer name.

>
> Overall, I am fine with the changes. I will be looking into a way to
> store the tileset file at it's final place as part of the upload
> process, so that we can ditch the serparate upload processor again, if
> possible.

This will remove a bottleneck and a potention point of failure.  I am
looking forward to that.

I won't do anything major to the client besides a bit tidying up and
updating comments until the current _unstable has been migrated to
stable.  After that I will start working on the client side changes
necessary for uploading tileset files.

Matthias