bdon

Where do you see that?

"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.

If you would like to run this comparison for tileservers reading from disk, I wrote a small tool to simulate traffic based on access logs of OpenStreetMap tiles:

https://github.com/bdon/TileSiege

Thanks for giving it a try! If you're going to revisit this, we could improve the docs around setting CORS configuration on DigitalOcean: https://docs.protomaps.com/pmtiles/cloud-storage#digitalocea...

I don't have any insight into this other than observing how their storage system works, but here's some scripts I made last year to test:

https://github.com/bdon/cloudflare-r2-latency

You can test this claim directly against a AWS S3 bucket.

First 100KB of a 100GB+ file:

curl -H "Range: bytes=0-100000" https://overturemaps-tiles-us-west-2-beta.s3.amazonaws.com/2... --output tmp -w "%{time_total}"

First 100KB at the 100GB mark:

curl -H "Range: bytes=100000000000-100000100000" https://overturemaps-tiles-us-west-2-beta.s3.amazonaws.com/2... --output tmp -w "%{time_total}"

I'm certain that you can build software to some specification without ever agreeing to the spec text's licence

That is exactly the opposite of OMT's copyright interpretation: https://github.com/openmaptiles/openmaptiles?tab=readme-ov-f...

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.

I see, I think that's a good approach to enable serving with stock nginx as well as for companies that are built on Nginx or a plain HTTP serving stack already.

For PMTiles the module is loadable directly as a Caddy plugin (https://docs.protomaps.com/deploy/server#caddyfile) which I prefer to nginx for security and bugs (and automatic SSL), and also enables serving PMTiles from disk or a remote storage bucket without a separate service running.

OMT use a CC-BY license: https://creativecommons.org/faq/#can-i-apply-a-creative-comm... (edit: link)

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.

I agree, there are tradeoffs to using static storage - the intended audience for PMTiles is those that prefer using static sites instead of administering a Linux server.

I would be interested to see a comparison of Btrfs + nginx serving latency, vs `pmtiles serve` from https://github.com/protomaps/go-pmtiles on a PMTiles archive on disk. That would be a more direct comparison.

I think there's potentially some interesting use case for tiles in Btrfs volumes and incremental updates, which I haven't tackled in PMTiles yet!

See my response here: https://news.ycombinator.com/item?id=41638031

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.

See my response here: https://news.ycombinator.com/item?id=41638031

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.

I'm the developer of Protomaps, to summarize:

The latency you see on https://pmtiles.io/?url=https%3A%2F%2Fdata.source.coop%2Fpro... is representative of how PMTiles works on AWS S3, coming from the us-west-2 region. It will be reasonable to load for those in the western US and likely quite slow from Europe or Oceania.

If you want to make a direct comparison of Protomaps to OpenFreeMap, you need to compare serving OpenFreemap with NGINX from btrfs on disk, to running `pmtiles serve` on a `.pmtiles` file on disk, as described here: https://docs.protomaps.com/deploy/server

The OpenFreeMap page for me (in Taiwan) takes 1-2 seconds per tile, which is more than double the load tile for the PMTiles in us-west-2 example linked above.

The best solution to get latency competitive with commercial providers, for a global audience, is to cache tiles at CDN edge locations. I describe automated ways to do that with Cloudflare Workers and AWS Lambda + Cloudfront here:

https://docs.protomaps.com/deploy/cloudflare https://docs.protomaps.com/deploy/aws

I'm also experimenting with http://tigrisdata.com which lets you geo-distribute a static storage bucket like in this example: https://pmtiles.io/?url=https%3A%2F%2Fdemo-bucket.protomaps....

Here's an example of the entire planet as a PMTiles:

https://pmtiles.io/?url=https%3A%2F%2Fdata.source.coop%2Fpro...

This is zoom 0-15, or 1,431,655,765 addressed tiles. So it is designed for this scale - for a production internet site you can add a lambda, server or CDN as an additional layer for lower latency: https://docs.protomaps.com/deploy/

To mitigate the "denial of wallet" attack on S3 there are a few options:

AWS Lambda: https://docs.protomaps.com/deploy/aws lightweight tile server: https://docs.protomaps.com/pmtiles/cli#serve

The replacement for the UI is to use the "pmtiles extract" command line tool:

https://docs.protomaps.com/guide/getting-started#_3-extract-...

I maintain a small MVT rendering library for Leaflet - I'm overall satisfied with the performance on modern devices, but usually point greenfield projects at MapLibre instead, unless you need some very specific Leaflet plugin.

demo: https://protomaps.github.io/protomaps-leaflet/examples/leafl... repo: https://github.com/protomaps/protomaps-leaflet

There is nothing stopping the OSM Foundation from say, offering a complete SQLite (or PMTiles) tileset download on planet.openstreetmap.org, technically, legally or otherwise. Creating and archiving the tiles shown on osm.org would be at least a couple terabytes once you get to around zoom level 16.

The key distinction is "official" - the only "official" data product of OpenStreetMap are its XML and PBF data dumps at planet.openstreetmap.org. The frequently-updated tiles you see on osm.org are "quasi-official", they're created by a separate project called OpenStreetMap Carto. These tiles have a special status within the OSM ecosystem for historical reasons; by virtue of OSM being map data, it should probably show something for human eyeballs on the website.

The design goals of OSM Carto are to show feedback to map editors; the linked vector tiles project is intended as a successor, or at least complement, to OSM Carto. The consumption of the tiles by third-party sites is a side-effect tolerated by OSMF; the general consensus within OSM seems to be that a consumable tile service for third parties is outside the scope of the project.

Leaflet is a separate project from OpenStreetMap - it's just one popular frontend for viewing tiles served from openstreetmap.org, like OpenLayers.

I don't believe the OSM Foundation has ever been involved in Leaflet development, as Leaflet development was supported in the past by commercial vendors of OSM data like CloudMade and Mapbox.

It doesn't, pmtiles is designed for tilesets updated at a daily to quarterly frequency, by replacing the entire archive on cloud storage. for minute-level updates serving tiles out of PostGIS is the best current approach, which is the approach Paul is taking for the OSMF project.

Most of the development for pmtiles has happened in the last 2 years, including a maturing server implementation (http://github.com/protomaps/go-pmtiles) but some key parts are still missing like the ability to decode an archive in native mobile applications. sqlite (mbtiles) already has ~10+ years of integration into the mapping ecosystem so that still works better if you want to move tilesets around to desktop applications and mobile devices.

The situation Paul is addressing is one unique to OpenStreetMap itself, which is minute-level updates of a global scale tileset. This is a use case pmtiles is designed explicitly not to address, where using a database is a better fit.

If I normally deal with data in the multi-GB range, limiting my uploads to 250MB seems woefully insufficient.

I think you're on to something here, which is that bytes stored isn't a great price discriminator for this class of software. The SaaS business model for Sentry or Notion succeeds because bigger teams store more content and have a higher willingness to pay.

For mapping applications, the county government GIS analyst might work daily with a 10GB aerial raster or parcel footprint dataset and be willing to pay $100 for a slicker solution, while a boutique real estate sales office stores a couple hundred dots (kilobytes of data) and is willing to pay $XXXX for the same solution!

Common situations for founders who describe themselves as bootstrapped:

- doing consulting work on the side

- living off savings

- having a spouse with income

For bootstrapped companies in the software or SaaS space without employees there should be minimal start-up costs compared to say, opening a restaurant. The real loss is opportunity costs: what salary or equity you could have earned as an alternative.

Natural Earth is generalized (low zoom) data and has hand-curated scaleranks on features to determine what features appear at low zooms. None of that is in OSM.

Mapbox is still the best choice where a polished suite of mapping APIs is a better fit for a project.

Mapbox is a venture-backed company with a SaaS business model, and has never been open source in total - it used to be open core with a FOSS frontend and proprietary backend. This SaaS model is absolutely the best way to fund huge companies and give investors a return. Mapbox has also done the bulk of innovation in open source web mapping over the past 10 years - the Protomaps project uses MapLibre (fork of Mapbox GL 1.0) and the MVT tile format. Both required teams of full-time developers - easily tens of millions in salaries and stock - and they have given away version 1.0 for free as a gift, even though 2.0 is not open source.

The ideal software economy is one in which innovators capture a good portion of the wealth they create. This is why it's important for Protomaps to focus on use cases underserved by SaaS, instead of just being a cheaper map API. The sibling comment on wildfire mapping https://news.ycombinator.com/item?id=37989059 is a good example of the applications I want the project to support.

The ordering applies across tiles, and not within - it should be efficient to diff two archives because there is a single, well-defined ordering over the entire archive, and writing algorithms over the tileset is all 1D operations instead of 2D (a single zoom level plane) or 3D (multiple planes)

You can kind of do that already with the pmtiles CLI:

pmtiles extract INPUT.pmtiles OUTPUT.pmtiles --bbox=BBOX --maxzoom=Z --dry-run

--dry-run will output the total size of the final archive without downloading any tiles, so you can adjust the maxzoom from the default of 15 (for basemaps) until it fits under your limit

It's OpenStreetMap (ODbL) and Natural Earth (public domain) currently

* http://openstreetmap.org

* http://naturalearthdata.com

(I've updated the page at https://docs.protomaps.com/basemaps/downloads)