More detailed Version 3 Specification #172
Conversation
| |`5`|`1337`|`42`|`0`|A leaf directory whose first tile has an ID of 5 is located at byte 1337-1378 of the _leaf directories section_| | ||
|
|
||
| ### 4.2 Encoding | ||
| A directory can only be encoded in its entirety. It is not possible to encode a single directory entry by itself. |
There was a problem hiding this comment.
@bdon in #107 (comment):
What implies this? An archive that addresses a single tile should be valid, AFAIK.
There was a problem hiding this comment.
The values you encode for an entry always depend on the entry that came before that entry. That's why I said that entries can't be encoded by itself.
Yes an archive that addresses a single tile should be valid, but that would have to have a root directory with one entry. At least you would to have to prepend a 1 to indicate the number of entries, that are contained in the directory and at that point it's a directory and not a single entry.
There was a problem hiding this comment.
At least you would to have to prepend a 1 to indicate the number of entries, that are contained in the directory and at that point it's a directory and not a single entry.
OK, I see what you mean here. I meant to say that a directory with length 1 is valid; any directory with length > 0 is valid. So I think 4.2 should simply say "A directory must have at least one entry".
There was a problem hiding this comment.
I'm happy to add something like "must have at least one entry", although it's already mentioned in another chapter.
But I still think we should keep something along the lines of "A directory can only be encoded in its entirety", because I remember that wasn't really clear to me when I first started implementing PMTiles. What I wanted to know then was how the entries are encoded / decoded, but that's just the wrong starting point, since they are always interleaved. So I was trying to clarify that you always have to encode / decode an entire directory to get the single entries. You cannot encode a single entry since all attributes are spread out over the directory.
|
This is finally ready for review. The only thing I'm still not sure about if we should move the changelog into a own file instead of having it directly in the spec itself. |
DerZade
changed the title
This PR fixes #107, by attempting to introduce a more detailed specification for version 3.