Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test data suit #182

Open
nyurik opened this issue May 25, 2023 · 4 comments
Open

Test data suit #182

nyurik opened this issue May 25, 2023 · 4 comments

Comments

@nyurik
Copy link

nyurik commented May 25, 2023

It seems both Rust implementations of pmtiles got the spec wrong - based on my testing of pmtiles and pmtiles2 crates. I think the reason for that is that they both had to come up with their own test cases - thus obviously failing :)

In order to have the same behavior for all pmtiles implementations, we desperately need a standard set of test files that all implementations must pass (reminds me of the ACID browser tests.... memories...)

Anyway, could you standardize the tests by:

  • consolidate all test data files in the https://github.com/protomaps/PMTiles/tree/main/js/test/data - or else it is unclear if they are the same or not? (I see some files in the /js dir)
  • create a readme in that same dir that points to the specific test code in one of the implementations (no point of describing the tests in the markdown, as i am sure it will quickly out of sync with the actual unit tests)

The reason for all this is that Martin tile server has received a great bug report maplibre/martin#675 (thx @tobinbradley !) that highlights a bug, but I have no good way of converting that 200MB file into a useful pmtiles test file - so was hoping to find a test fixture here :)

Once again, thanks @bdon !

@bdon
Copy link
Member

bdon commented May 25, 2023

A lot of the low-level logic might fit unit tests better by standardizing the test cases used in this file:

https://github.com/protomaps/PMTiles/blob/main/js/test/v3.test.ts#L126

Because a directory is a flat list of elements we could potentially store it as a CSV file that each test suit reads for its data+assertions.

But yeah, I need to add at least one more complex integration testing file that has > 1 directory depth, which might be the root cause of the linked problem. While > 2 depth archives are allowed by the spec AFAIK there aren't any writers that make these (and I have yet to discover a realistic use case)

@nyurik
Copy link
Author

nyurik commented May 25, 2023

yeah, perhaps we should have a simple utility to encode arbitrary complex JSON/YAML into protobuf, where the actual tile content is just a few bytes long. This way we can set up a yaml like this:

metadata:
  field: value
  field2: value2

dir:
  tiles:
    "0/0/0": "1"
    "0/0/1": "1"

(i am actually not certain about the dir/tiles structure - basically we need anything that would allow simple encoding of a tile by specifying its zxy coords plus content or same value as something else)

@jjzazuet
Copy link

Same. I'm trying to implement deserialization support for Java. Any updates? Thanks!

@bdon
Copy link
Member

bdon commented Sep 22, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants