Why OMT instead of protomaps? The latter is clearly where the community is moving towards (albeit very slowly).
I'm somewhat sceptical about the "free with no API keys" idea. I guess your service is not guaranteed to be up so no one too big will rely on it. But what if you start getting abuse or someone using them on some humongous site (e.g. one of those cheap restaurant email builders that always embed a map), and you start getting way too much traffic from random sources and websites. What would you do?
> I would have loved to use PMTiles; they are a brilliant idea!
> Unfortunately, making range requests in 80 GB files just doesn't work in production. It is fine for files smaller than 500 MB, but it has terrible latency and caching issues for full planet datasets.
> If PMTiles implements splitting to <10 MB files, it can be a valid alternative to running servers.
That's an interesting claim. I make range requests to 100GB+ files (genomics) all the time for work and it works great. I've never considered total file size as directly related to latency in this respect, assuming you have some sort of an index of course.
Here the requests are really really small, on average 405 bytes each. I guess in your genomics work you are making larger requests, so probably it's not so much of an issue.
If you store the PMTiles in S3 or any other object store that supports HTTP Range Requests, that's a no-brainer... In a normal disk on you own server, this might become interesting, yes.
ok except "full planet datasets" make little sense for terrestrial features. Splitting .. aka sharding the files into basic continents would make SO much sense. Asia is big, but no requests for Africa mixed in.. Australia would be manageable?
The latency for small files and ranges of large files is pretty similar on most storage platforms, but there are some exceptions like Cloudflare R2.
The main reason PMTiles is one file and not two or more files is that it enables atomic updates in-place (which every mature storage platform supports) as well as ETag content change detection in downstream caches. All of the server and serverless implementations at http://github.com/protomaps support this now for AWS, S3-compatible storage, Google Cloud, and Azure.
1) The Protomaps schema is mostly a re-implementation of the Tilezen project https://tilezen.readthedocs.io/en/latest/ which is a linux foundation project. OpenMapTiles, which OpenFreeMap uses, while open source, does not have a license that encourages derivative works or enables distributing styles under a standard FOSS software license (https://www.npmjs.com/package/protomaps-themes-base). That's also one motivation for developing Shortbread which is at this point less developed than Tilezen.
2) The file format (PMTiles) addresses a different audience than either MBTiles or Btrfs images. Both of those require administering a server for tiles, while PMTiles requires static blob storage and nothing else. You do have the option of using a server like MBTiles/btrfs which ought to be comparable in latency, and that's documented here: https://docs.protomaps.com/deploy/ as well as Lambda, Cloudflare Workers, Google Cloud Run and Azure Serverless functions.
3) There are no existing styles for MapLibre GL that work off the Tilezen layer, generalization and tagging scheme, so we need to develop one style, with multiple themes.
This means that software that implements OMT, even if written from scratch, cannot be re-used by other FOSS projects (Apache, BSD, GPL, AGPL, other software in the OpenStreetMap ecosystem, etc) without affecting the license.
Ideally for Protomaps it should be possible to re-use just one portion - like only the label layer with your own layers from other sources, or even bundle it as a JS dependency in another open source project - without affecting the license of downstream projects.
Are you talking about just the OpenMapTiles spec, or some adjacent software? I'm certain that you can build software to some specification without ever agreeing to the spec text's licence, and that a CC-BY licenced spec doesn't limit any implementing system's licence.
Even so, CC-BY is permissive and you could include CC-BY content in a, say, GPL project. You just need to include both licences.
That is the definition of license incompatibility as described in the Creative Commons documentation above. The license is open source and a good fit for if you are running a paid map SaaS or free service as an end product, but is not compatible with the open source ecosystem as a building block.
> That is exactly the opposite of OMT's copyright interpretation.
They are entitled to their opinion, but I don't consider a database to be a derivative work of a schema (this should be clear, since databases of facts aren't copyrightable anyway), same for software (it's at least fair use in the US, see Google v. Oracle). This goes back to the debate on copyrightability of APIs, where a decision for copyrightability would ruin swathes of the software industry and much of free software.
Though I understand if you'd rather avoid using projects by people with weird legal opinions.
> That is the definition of license incompatibility as described in the Creative Commons documentation above.
Where do you see that? All I found was a statement that the CC share-alike licences can be converted to GPL, but no word on non-SA licences:
> Version 4.0 of CC’s Attribution-ShareAlike (BY-SA) license is one-way compatible with the GNU General Public License version 3.0 (GPLv3).
It's not uncommon for a piece of code to have multiple licences in a big project. One for licencing to that project, and another for sublicencing to the end user. Proprietary apps that include FLOSS code do this all the time.
"Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses." https://creativecommons.org/faq/
> Though I understand if you'd rather avoid using projects by people with weird legal opinions.
The scale of the Protomaps project is small (I'm the only full-time developer) and I don't have the resources to interpret novel copyright situations. I think it's best for the ecosystem to abide by the license terms stated by the open source developer, instead of challenging their validity.
I did 150TB+ on a 40 Euro Hetzner server for years without any issue and also did the same amount in a similar price range on multiple different providers. The cloud and CDNs charge a huge markup.
That's great to know! I know of one story where someone got terminated on Hetzner because of the bandwidth but it turned out he was also running a Tor node.
Why OMT instead of protomaps? The latter is clearly where the community is moving towards (albeit very slowly).
I'm somewhat sceptical about the "free with no API keys" idea. I guess your service is not guaranteed to be up so no one too big will rely on it. But what if you start getting abuse or someone using them on some humongous site (e.g. one of those cheap restaurant email builders that always embed a map), and you start getting way too much traffic from random sources and websites. What would you do?