I’m the developer of Trail Sense. With the upcoming release I’m adding support for custom generated DEM (digital elevation model) files that use public domain data (and the generation code is open source). The app ships with a built-in DEM with very low resolution, but users can optionally choose to download higher resolution models. The models are hosted on GitHub releases and there’s a link in Trail Sense (which opens in the user’s browser - no direct downloads) to my site (hosted on GitHub pages), which has direct links to the zip files in the GitHub release.
Since that is hosted on GitHub releases, I believe that counts as NonFreeNet anti-feature. I’m wondering if there are any free or low cost FOSS alternatives to GitHub releases that others are using for file hosting (that doesn’t require me to maintain my own server). I would love to avoid the anti-feature but I don’t want make it hard for f-droid users to find out where to download a better DEM if they are interested.
If I’m not mistaken even if I allow the link to be changed, wouldn’t that still be NonFreeNet because GitHub is proprietary (if that’s the default value of the link shown to the user)?
Thank you, I will look into those. I do plan on releasing the new version of my app this weekend, so I’ll plan for the anti-feature merge request as well.
I’m still not entirely certain where that falls based on the anti-feature descriptions, but I think I’ll get more support requests if I don’t offer a link. I’m just a bit worried about users seeing the NonFreeNet anti-feature and thinking that Trail Sense has access to the Internet. Looking at the F-Droid client on F-Droid, I don’t see any anti-features listed there and there are links to GitHub repos, etc, so maybe it doesn’t fall into NonFreeNet.
Yes, I’ve been developing some geographic data compression algorithms for a bit in Trail Sense (this is the 5th model, but also much bigger than the others - the source was 3+GB). I have three options, the first is to compress into a single channel with an offset and scale factor - on lower quality models I can use lossy webp compression at the expense of accuracy. The second is to store the raw data (with a scale factor to chop off high frequency bits) into 2 channels, but that has to be lossless compression. And the last is to create an “index” which can compress multiple values for the same geographic point across multiple files while cutting out 0 value pixels (not used for the DEM).
So in short, the compression is both of the data and image files.
It actually works pretty well, but takes a while to find a balance between size and accuracy.