Handling of TzWorld data on a Pi Zero

[cloud8421]

Thanks @kip!

@kip

Would there be value in making the DETS file a downloadable asset of the library? I didn’t do that initially because I was worried about version mismatch between the data and the library but its been a couple of years now and the format hasn’t changed (although clearly the data does change over time).

My only concern there is size of the download, but it would work. From the OTP side, the version of the table should be stable enough.

@kip

The next question would be whether the bounding boxes (aka “the index”) can also be generated as an artefact for download and I expect that is probably true as well but I will need to refresh myself on how the index is built and accessed.

That would also work - the cached data is a list of tuples, so it can be converted to an Erlang binary and written to disk - this is what I had in mind when I mentioned writing the index cache to disk.

@kip

A spatialite backend implementation would also be a very intersting thing to explore and I’m up for collaborating on that as well. I may well hold the best chance of a more manageable and performant solution at the small compromise of requiring another dependency. That could also presumably be a release artefact since sqlite database tables are just files.

I did come across this while researching and indeed it would provide the necessary APIs - I don’t know how one would go at having this installed and working in the context of an Elixir application (and Nerves in particular) but I’m happy to try and figure that out.

One thing I noticed while working on the problem is that both Astro and TzWorld could be made more extensible to sidestep some of these issues. For example, Astro doesn’t allow injecting a dependency to resolve location → timezone, while TzWorld doesn’t allow custom backends (I forked it to provide mine).