Sad news from Placemark today, the platform is shutting down in January:
Well, I’ve made the decision to wind down my efforts on Placemark - it’s been a lovely journey thanks to great folks using it (like you!) but ultimately wasn’t self-sustaining financially.
Starting today,
New signups will be disabled
Existing paid users will have free access until January 19, 2024
In January 2024 I’ll release the full source code for the application as open source
The writing has been on the wall since Tom MacWright wrote in January:
I’ve envisioned it as a tool that you can use for simple things but can grow into a tool you use professionally or semi-professionally, but maybe that’s not the future: the future is Canva, not Illustrator.
Tom was the creator and only person who worked on Placemark (as far as I know). It’s hard to compete as a one-person company, when products as impressive Felt launch at the same time.
A short programming announcement: In addition to Twitter and Mastodon, I’ve started posting updates to Bluesky.
I also have a couple of Bluesky invites to give away. If you’re interested, shoot me an email at letters@latlong.blog. Yes I prefer email; I’m that old. I’ll send the invites out on a first come, first serve basis. I will be using your email adress for this purpose only, I won’t store your email or sign you up for a newsletter.
I’d like to use the occasion to remind everyone that the feeds are the best way to get notified of new content on the site. No sign-up required, you get full articles delivered to your favourite feed reader, and you get to support the open web.
react-google-maps is a library containing React components and hooks for building Google Maps user interfaces. It includes components to render maps, customisable markers, info windows and control panels. The hooks allow developers to access underlying object instances, such as the Map object, or to load additional APIs, like the geocoding or direction services. If you work in React and use the Google Maps JavaScript API, this library will save you a couple lines.
In his NACIS conference talk, Brandon Liu positions Protomaps as an altenative to what he call scarcity maps: Tile services offered by commercial companies that cost a small fortune once your project becomes popular and exceeds the number of tile requests in the free tier.
Nothing is free in this world, even hosting PMTiles yourself isn’t. If you want to convince someone that hosting Protomaps is a financially viable alternative then you need to compare numbers.
So let’s do some quick math and compare a rough estimate of the costs for hosting PMTiles on S3 to the monthly costs of Mapbox Vector tiles.
For the sake of simplicity, let’s assume that clients make 1.5 million tile requests per month. The costs incurred on S3 fall into two categories. Data storage and transfer.
On 3 November, the size of a PMTiles dataset based on OpenStreetMap covering the whole world was 107.62 GB. AWS charges $0.023 per GB and month to store data in S3, so the cost to store a global map is $2.47.
To estimate the transfer costs, we need to know the average size of a PMTile that is delivered over the network. The Protomaps website conveniently has an example that shows size of each tile response. I zoomed and panned around on the map and logged the individual size of about two hundred requests. The average size per tile in my sample was 68.88KB. 1.5 million tile requests at 68.88KB rack up about 103GB in transferred data. AWS charges $0.09 per transferred GB from S3 to the internet, so the overall data-transfer cost is $9.27.
The cost to host and serve a world-wide map dataset is about $12. But here’s a catch. If you put a Cloudfront CDN in front of your S3 bucket (which you probably want to do), then data transfer from S3 to Cloudfront is free, so is the first terra-byte from Cloudfront to the internet. Chances are your can host your PMTiles for less than $5.
The same 1.5 million vector-tile requests on Mapbox will cost you $325; a significant difference. Even considering the labour costs of setting up the infrastructure and data on AWS, and making the occasional update, PMTiles will save money. Like a lot of money.
Disclaimer: This is an informed estimate not a scientific study. I literally did this on the back of an envelope. It’s not my fault, if you take these numbers to your boss to convince them to adopt Protomaps and it turns out you’re paying $25 per month.
One of the important new features in this release is the introduction of Global Entity Reference System (GERS) IDs. GERS IDs have been assigned to over 1.6 million building footprints across several cities in North America, South America, and Europe.
GERS is a system of encoding map data to a shared universal reference, which provides an easy mechanism to conflate data from different data providers based on a specific GERS ID.
Overture introduced GERS recently; it aims to provide a globally unique reference for every entity that can be mapped. It appears, the idea is that data providers outside of Overture can enrich their data sets with GERS to increase interoperability and ease the effort required to fuse data. An enticing idea, sure, but it seems GERS is of little use outside of Overture’s ecosystem.
Let me explain.
In order to retrieve and enhance a data set with GERS IDs, you have to match your data to Overture’s using geometry intersections. This works, but it’s not a novel approach. We were able to do spatial joins before, and IDs also existed before. If a feature is not yet part of Overture’s data, then the only way to create a GERS ID is to add it to Overture’s data set. GERS practically doesn’t exist outside of Overture data.
And questions remain how GERS keeps up with changing data. What if I knock down my house and build a new one at the same place? Does the original GERS ID continue, or is this a new one. What if I subdivide my property; does this result in two new GERS IDs, or is the existing one applied to one part? How about I buy the property next door and connect the two house so they become one?—New GERS ID or one of the original ones? And what if the GERS ID for an entry changes? How do I keep track of these changes to update the IDs in my dataset? If we look at GERS as a gateway to keep datasets in sync, then these are crucial questions to answer.
It’s early stages and I’m sure there are discussions within Overture to address these concerns. But for now, GERS’ only application will be conflation of data from Overture data donors to produce their building datasets.