protomaps
API refactor
Hi first thanks for this project.
I'm moved my project from mbtiles to a dedicated kv solution and finally to pmtiles which is way better, problem is the actual go-pmtiles is not directly usable as an API.
I had to copy some private part of your code, to create a different http handler https://github.com/akhenakh/kvtiles/blob/master/storage/pmtiles/pmtiles.go
Are you planning on making a more Goish API?
Hi, the current code isn't really meant to expose a programmatic API beyond the CLI. Copying those bits of low-level parts seems like a good enough solution for now.
Because I don't use the Go module myself yet I would appreciate some feedback on what the use cases are, for example which of the CLI functionality you would want to use in your Go program. The big one is #31 which isn't finished yet.
You can see your public code over here:
https://pkg.go.dev/github.com/protomaps/[email protected]/pmtiles
- There is no way to parse a headerv3.
- There is no way to read a tile without using all your server handler, this one is the bare minimum for this lib to be usable.
@akhenakh thanks - would adding utility functions for parsing headers help accomplish what you need for your project?
On the topic of reading tiles - I don't think there is one single answer for all use cases. The server right now barely handles local files and S3-like cloud storage with an LRU cache, however it needs to be adaptable to:
- public HTTP endpoints
- other caching strategies - if you are reading a large block of tiles, an LRU cache may not be efficient compared to pre-loading the entire directory section in memory
A program that scrapes (politely) or generates tiles and inserts them into a PMTiles archive is a good example of what I envision the Go API being used for. This is definitely on the roadmap but not an immediate priority right now so I'm open to an intermediate "good enough" refining of the API.