Closed mdsumner closed 6 years ago
Thanks for the contribution!
So my original plan wasn't to do much work on the UI side. I was imagining this pkg as an infrastructure package.
It's because of where you end up and the down_loader()
function is a good example. It's not very nice to ask end users to plug in their own API string, the expectation would be to call a function with that info as parameters. I was thinking that would probably be a separate package(s) that wrapped up calls to a few diff services.
Yeah, I got a bit carried away - it's a good idea to keep it separate. If you have a good name I'll push the PR content into a new package to get images. I can't live without this tile getter now
Ah great. tilegrub
came to me on my bike this morning if that does anything for you?
Ha! Still toying with a few ideas :)
Closing this, belongs in https://github.com/hypertidy/ceramic
I have a strong opinion for downloading tiles, which is to make a slippymath cache and keep the absolute path of the source, so that the source url
becomes a matching file
Then there's no need to have a mapping between the cache structure and the online source, it's completely transparent. There's no clash between provider tiles or types. If we have a set of download tiles that we just obtained, then we have that list - it's also a record of the request (at least at the time), and the tiles can just be downloaded willy nilly without having to worry about what they are called or where they are.
I don't know if there's a precedent, other than that's how we do it with bowerbird. :)
I appreciate this might not be the package that does the downloading, but wanted to get the thought out!