Google's Android has now broken that.

On the web, we used to use:

<input type="file" accept="image/jpeg">

That opened the phone's photo picker and let the use upload a geotagged photo. But a while ago Google deliberately broke that.

Instead, we were encourage to use the file picker:

<input type="file">

That opened the default file manager. This had the unfortunate side-effect of allowing the user to upload any file, rather than just photos. But it did allow the EXIF metadata through unmolested. Then Google broke that as well.

Using a "Progressive Web App" doesn't work either.

So, can users transfer their photos via Bluetooth or QuickShare? No. That's now broken as well.

You can't even directly share via email without the location being stripped away.

Literally the only way to get a photo with geolocation intact is to plug in a USB cable, copy the photo to your computer, and then upload it via a desktop web browser?

Why?!?!?

Because Google run an anticompetitive monopoly on their dominant mobile operating system.

Privacy.

There's a worry that users don't know they're taking photos with geolocation enabled. If you post a cute picture of your kid / jewellery / pint then there's a risk that a ne’er-do-well could find your exact location.

Most social media services are sensible and strip the location automatically. If you try to send a geotagged photo to Facebook / Mastodon / BlueSky / WhatsApp / etc, they default to not showing the location. You can add it in manually if you want, but anyone downloading your photo won't see the geotag.

And, you know, I get it. Google doesn't want the headline "Stalkers found me, kidnapped my baby, and stole my wedding ring - how a little known Android feature puts you in danger!"

But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.

I don't know what the answer is. Perhaps a pop up saying "This website wants to see the location of your photos. Yes / No / Always / Never"? People get tired of constant prompts and the wording will never be clear enough for most users.

It looks like the only option available will be to develop a native Android app (and an iOS one?!) with all the cost, effort, and admin that entails. Android apps have a special permission for accessing geolocation in images.

If anyone has a working way to let Android web-browsers access the full geolocation EXIF metadata of photos uploaded on the web, please drop a comment in the box.

In the meantime, please leave a +1 on this HTML Spec comment.

You can read more about Dr Judy John and her work on biodiversity.

Using the power of advanced machine learning, it is possible to plot the growth on an innovative form of data visualisation known as "a graph"!

That's the sort of "number go up" that investors like to see. I reckon someone will come along to give us a bazillion dollarydoos any minute now.

For those of you who like text rather than graphics, here are our historic milestones:

• 10K - December 2018
• 20K - August 2021
• 30K - November 2023
• 40K - March 2026
• 50k - ??? Probably September 2027 ???

Tell you what, when we get to fifty-thousand, we'll throw a big party and you'll all be invited 🥳

If you spot a lovely memorial bench while you're out and about, please take a geotagged photo and upload it to OpenBenches.org.

Sadly, despite the best efforts of the AV team, the video had a missing section. I took my own audio recording and zipkid took some photos, so I was able to recreate it using the Flowblade video editor.

Enjoy!

Many thanks to Edward Betts for running the dev room and providing the display laptop.

It is, thankfully, surprisingly cheap! In part, that's because it is a relatively simple tech stack - PHP, MySQL, a couple of API calls to external services. It was designed to be as low cost while also being useful. Here's the breakdown:

Hosting - £171 per year

Our biggest expense but, I think, our most reasonable. Krystal charges around £342 for a 2 year contract. That includes unlimited bandwidth and storage, as well as the domain name. We have nearly 400GB of photos and bot scraping means we can use over 900GB of bandwidth per month - so Krystal give us a rather good deal!

Use this affiliate link and code EDENT to get a small discount.

Stadia Maps - US$20 / month

Geocoding is surprisingly hard to do locally. We need to transform latitude and longitude into addresses, and then back again. Stadia Maps cost about the same as our hosting! What's rather annoying is that we only use about half the API calls in our plan. We need to find a cheaper solution.

Mapping - Free!

When we used Stadia for drawing maps, we regularly ran over our quota. So we switched to OpenFreeMap which produces gorgeous interactive maps.

The service has been rock solid and very responsive to bugs on GitHub.

Logo - US$5

I'm not a good designer, so we bought a logo from The Noun Project and then coloured it in. Bargain for a fiver!

Image CDN - Free!

Although we have unlimited bandwidth with Krystal, we're only located in one region - the UK. WeServ. It's also pointless serving full resolution images to small screens.

So WeServ offers free image resizing and global CDNs. Personally, I'm not a fan of CloudFlare (their CDN partner) so I'm looking to change provider.

OCR - Free!

People don't want to type in the inscription of the photo, so we use Google Cloud Vision.

We send less than 1,000 requests per month - so we're inside their free tier. If we get more popular, that'll get more expensive. But I don't know of a local-first OCR which is as good as Google's. Sadly, Tesseract is rubbish for extracting text from photos.

Authentication - Free!

We don't want to store anyone's passwords. The free tier of Auth0 allows us to do social login for up to 25,000 monthly users. Which is more than enough for us.

Sadly, Auth0 don't support the Fediverse, so I had to build my own "Log-in with Mastodon" service.

As much as we'd like to run social login locally, we simply don't want to be responsible for securing users' details & API keys.

Software - Free!

As per the OpenBenches colophon we use a lot of cool FOSS. Small JS libraries, big PHP frameworks, and everything in between.

Income

Thanks to GitHub Sponsors we make a whopping US$3 per month!

Similarly, our OpenCollective Sponsors brings in about £3 per month.

Merchandising! You can buy OpenBenches branded t-shirts, mugs, and hats. That nets us about £20 per year

Call it roughly £80 income. OK, it is better than nothing - but doesn't even cover a quarter of our costs. Sometimes people give us a higher donation privately, which is also very welcome. These people are listed on our README.

Total

On the assumption that our time is worthless (ha!) and that we only rarely go over our providers' API limits, and we get in some revenue, the cost of running OpenBenches is less than £300 per year.

That's not bad for a fun little hobby. People certainly spend more than that on Funkopops, vaping, and mechanical keyboards!

Nevertheless, I'm always slightly worried that we'll go viral and have an unexpectedly high bill from our API providers.

I would love to be able to hire a proper designer to make the site look a bit nicer. I also want to be able to buy a modern iPhone so that I can test it in the latest Safari.

If you have any suggestions for cutting costs, or non-scummy ways to help us raise funds, please drop a comment below.

My wife Liz and I have been running the OpenBenches project for about 8 years - it's a crowd-sourced repository of memorial benches. People take a geotagged photo of a bench's plaque, upload it to our site, and we share it with the world. Might sound a bit niche, but we have around thirty-nine thousand benches catalogued from all over the world.

From the start, we had a comment form under each bench. Of course, we pre-moderate any comments. That helps with our Online Safety Act obligations and prevents spam from being published. We don't collect any personal data, to reduce our GDPR exposure. Our comments are self-hosted using the excellent Commentics - which means we don't send people's data off to a 3rd party.

We thought that this would be used to tell us that an inscription was wrong, or if a bench had moved, or something like that.

We were completely wrong!

People use OpenBenches comments for all sorts of things. Of course, there are a few which provide details about the bench itself:

Other provide a little context about the person:

But those sorts of comments are hardly the majority. The comments break down (roughly) into these categories:

I want to know more about this person

I sat on this bench, searched for the inscription and found this site. I want to share my feelings

Thank you for putting a bench here

This has moved me

My heart has broken

I can't visit this bench, but I'm glad someone has shared a photo

Thank you for adding a photo

I don't know the person this bench commemorates, but I want to let them know they're still loved and remembered

That's nice

Hundreds of people sharing connections. Wanting to express their feelings. Understanding the terrible pain of loss and the hope that, someday, someone will think fondly of us.

You can view all the comments on OpenBenches.org.

Our plan was never to compete with something like OpenStreetMap. The OSM project is vast, complex, and brilliant - we are small, simple, and differently brilliant. But, over the years, people have repeatedly asked if there's any way to combine the two data sets.

This has proved logistically complex for several reasons.

1. Our users aren't experienced mappers.
   • Most of our entries are uploaded with fairly fuzzy GPS co-ordinates. Mobile phones aren't always the best at accurate locations and, besides, people tend to stand away from the bench when taking its photo. So our data isn't quite at the level of quality rightly demanded by OSM.
2. OSM didn't have a tag specifically for memorial benches.
   • We started out site in 2017. OSM added the Tag:memorial=bench in 2021. Up until then, there wasn't a great way to record that a bench was a memorial.
3. Data licencing is complicated.
   • We chose the Creative Commons Attribution ShareAlike licence - it seemed like a good idea at the time! OSM use ODbL which is subtly incompatible. As such, OSM volunteers asked us to sign a waiver so they could use the data - which we happily did.
4. Adding or editing data on OSM can be complicated.
   • OpenBenches is designed to be an upload-and-forget process. It doesn't matter much to us if a bench is recorded a dozen metres away from its true location. But that isn't the way OSM works. We didn't want to bulk upload data which was inaccurate, incomplete, or inappropriate. Luckily, there are now tools to help with that!

Things have been working away in the background. Some people have manually added Key:openbenches:id to appropriate benches, and others have edited our database to make the locations closer to reality.

And now, thanks to the sterling work of the brilliant Pieter Vander Vennet we're moving to our next phase of increased collaboration!

Firstly, there are about 1,060 benches on OpenStreetMap which have an OpenBenches ID. I've taken all those OSM IDs and put them into our database. Which means that the OpenBenches website can display a button like this:

One click and you're looking at OSM - ready to investigate, edit, or admire.

But what about the other 38,000 benches? Well, that's where MapComplete comes in. MapComplete is sort of like Pokémon Go for maps. As you wander this Earth, you can complete little quests to help improve OpenStreetMap. For example, on the "Pubs" quest, you can add details of all the pubs you visit.

With the "Bench" quest, it is a little different. If an OpenBench is sufficiently nearby an OSM bench, you'll get the option to link the two with a couple of clicks.

But there are loads of benches we have discovered which aren't in the OSM database. In which case, you can add a new bench to OSM using the data from OpenBenches!

This has been a couple of years in the making - but it looks like most of the kinks are now sorted out. I'm sure there will be a few early problems, and no doubt a bit of late-night bug fixing, but I hope that this is the start of something long-lasting. The joy of decentralised sites using open data is that we can all build on each others' work in a spirit of fun and exploration.

How do I turn -33.755780,150.603769 into "42 Wallaby Way, Sydney, Australia"?

Luckily, that's a (somewhat) solved problem. Services like OpenCage, StadiaMaps, OpenStreetMap, and Geocode.Earth all provide APIs which transform co-ordinates into addresses. Done! Let's go home.

Except… Not everywhere has an address. Some benches are in parks. They typically don't have a street number, but might have an interesting feature nearby to help with location. For example a statue or prominent landmark.

And… Not every address is relevant. Some benches are on streets. But we probably don't want to imply that the bench is inside or belongs to a specific nearby house.

Let's step back a bit. Why do we want to display a human-readable address?

We have two use-cases.

"As a visitor to the site, I want to:"

1. Read a (rough) textual representation of where the bench is.
2. Click on a component of the address to see all benches within that area.

The first is easy to explain:

The second is harder. Suppose a bench is in Wellington, New Zealand. We want to create a URl like openbenches.org/location/New Zealand/Wellington/. That way, users can click on the word "Wellington" and find all the benches nearby. A user can also manually edit that URl to increase or decrease precision.

Both of these are problems of precision.

Let's take a look at how one of the reverse geocoding services deals with transforming 51.476845,-0.295296 into an address:

Royal Botanic Gardens, Kew, Sandycombe Road, Kew, London Borough of Richmond upon Thames, London, Greater London, England, TW9 2EN, United Kingdom

That is too much address!

Yes, it is technically accurate. But it contains far too much detail for humans, the postcode is irrelevant, and the weird-subdivisions are nothing that a local person would use.

Looking at the full API response, we can see:

{
  "place_id": 258770727,
  "licence": "Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
  "name": "Royal Botanic Gardens, Kew",
  "display_name": "Royal Botanic Gardens, Kew, Elizabeth Cottages, Kew, London Borough of Richmond upon Thames, London, Greater London, England, TW9 3NJ, United Kingdom",
  "address": {
    "leisure": "Royal Botanic Gardens, Kew",
    "road": "Elizabeth Cottages",
    "suburb": "Kew",
    "city_district": "London Borough of Richmond upon Thames",
    "ISO3166-2-lvl8": "GB-RIC",
    "city": "London",
    "state_district": "Greater London",
    "state": "England",
    "ISO3166-2-lvl4": "GB-ENG",
    "postcode": "TW9 3NJ",
    "country": "United Kingdom",
    "country_code": "gb"
  }
}

Aha! Perhaps I can build a better address using just those components!

Except… Not every country has states. And not all states are used when giving addresses. Not every location is in a city. Some places have villages, prefectures, municipalities, and hamlets.

New York, New York is a valid address, but Berlin, Berlin is not!

There's an address formatter by OpenCage which is pretty sensible about stripping off irrelevant details. But, to go back to my first point, not every map location on OpenBenches is a street address and - even if it is on a street - it probably shouldn't have a house number.

Well, there's kind of a solution to that! Most mapping provider have a POI function - we can find nearby things of interest and use them as a location.

Here's a bench in Cook County, Illinois, USA. The POI address is:

{
…
   "name": "Central Park",
   "coarse_location": "Des Plaines, IL, USA",
…
}

I assume there's only one Central Park in Des Plaines. Do people know that "Il" is Illinois? Would "Cook County" be useful?

On the subject of localisation, not everywhere speaks English. Do I want to display addresses like "原爆の子の像, 広島, 日本"? How about "原爆の子の像, Hiroshima, Japan"?

We're an international site, but most benches are in Anglophone countries.

Of course, just because something is physically near a POI, that doesn't mean it is logically close to it.

Consider a bench situated at the edge of this park

The nearest POI is "Gay's Creamery" - across the river. Is that what you'd expect? Is there any way to easily say "if a point is inside an amenity* then use that as the address?

I don't want the users of our site to have to select from a list of POIs or addresses, this should be as automated as possible.

The Plan

For each bench:

1. Use StadiaMaps to get the nearest POI.
2. Get the data in English.
3. Concatenate the name and coarse location.
4. Save the "address".
5. Wait for complaints?

Thoughts?

Spoiler alert: yes!

Basic Globe

Here's a basic example which I've trimmed down from this example.

When you load the below code, you'll get a globe which you can spin and zoom. Nifty!

<!DOCTYPE html>
<html>
    <head>
        <title>Globe Projection using OpenFreeMap</title>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <link rel="stylesheet" href="https://unpkg.com/maplibre-gl@5.0.0/dist/maplibre-gl.css">
        <script src="https://unpkg.com/maplibre-gl@5.0.0/dist/maplibre-gl.js"></script>
        <style>
            body { margin: 0;padding: 0; }
            html, body, #map { height: 100%; }
        </style>
    </head>
    <body>
        <div id="map"></div>
        <script type="module">
            const map = new maplibregl.Map({
                container: "map",
                style: "https://tiles.openfreemap.org/styles/liberty",
                zoom: 2,
                center: [0.123, 51.2345],
                pitch: 0,
                canvasContextAttributes: { antialias: true }
            });

            map.on('style.load', () => {
                map.setProjection({
                    type: 'globe',
                });
            });
        </script>
    </body>
</html>

Adding Markers

In most respects, this acts like a normal MapLibre GL map. To add a marker, add this code:

const marker = new maplibregl.Marker()
    .setLngLat([12.345, 54.321])
    .addTo(map);

GeoJSON Clusters

Now for the big one! On OpenBenches we display markers and clusters of markers. On a flat map, it looks like this:

We want to turn it into this beauty:

Here's the code, adapted from the tutorial:

const map = new maplibregl.Map({
    container: "map",
    style: "https://tiles.openfreemap.org/styles/liberty",
    zoom: 2,
    center: [0.123, 51.2345],
    pitch: 0,
    canvasContextAttributes: { antialias: true }
});

map.on('style.load', () => {
    map.setProjection({
        type: 'globe',
    });
});

//  Load GeoJSON
async function load_GeoJSON() {
    const response = await fetch( "geo.json" )
    var benches_json = await response.json();
    return benches_json;
}

//  Asynchronous function to add custom layers and sources
async function addCustomLayersAndSources() {
    //  Get the data
    var geo_data = await load_GeoJSON();
    //  Load the GeoJSON
    if (!map.getSource('geo_data')) {
        map.addSource('geo_data', {
            type: 'geojson',
            data: geo_data,
            cluster: true,
            clusterMaxZoom: 17, // Max zoom to cluster points on
            clusterRadius: 50 // Radius of each cluster when clustering points (defaults to 50)
        });
    }

    //  Custom point marker
    if ( map.listImages().includes("marker-icon") == false ) {
        var image = await map.loadImage('/marker.png');
        map.addImage('marker-icon', image.data);
    }

    //  Add the clusters
    if (!map.getLayer('clusters')) {
        map.addLayer({
            id: 'clusters',
            type: 'circle',
            source: 'geo_data',
            filter: ['has', 'point_count'],
            paint: {
                // Use step expressions (https://maplibre.org/maplibre-style-spec/expressions/#step)
                // with three steps to implement three types of circles:
                //   * Blue, 20px circles when point count is less than 100
                //   * Yellow, 30px circles when point count is between 100 and 750
                //   * Pink, 40px circles when point count is greater than or equal to 750
                'circle-color': [
                    'step', ['get', 'point_count'],
                        '#51bbd655',
                    100, '#f1f07555',
                    750, '#f28cb155'
                ],
                'circle-radius': [
                    'step', ['get', 'point_count'],
                        20,
                    100, 30,
                    750, 40
                ],
                'circle-stroke-width': [
                    'step', ['get', 'point_count'],
                        1,
                    100, 1,
                    750, 1
                ],
                'circle-stroke-color': [
                    'step', ['get', 'point_count'],
                        '#000',
                    100, '#000',
                    750, '#000'
                ],
            }
        });

        //  Show number of markers in each cluster
        map.addLayer({
            id: 'cluster-count',
            type: 'symbol',
            source: 'geo_data',
            filter: ['has', 'point_count'],
            layout: {
                'text-field': '{point_count_abbreviated}',
                'text-font': ['Noto Sans Regular'],
                'text-size': 25
            }
        });

        //  Show individual markers
        map.addLayer({
            id: 'unclustered-point',
            source: 'geo_data',
            filter: ['!', ['has', 'point_count']],
            type: 'symbol',
            layout: {
                "icon-overlap": "always",
                'icon-image': 'marker-icon',  // Use the PNG image
                'icon-size': .1              // Adjust size if necessary
            }
        });
    }
}

//  Start by drawing the map
map.on('load', async () => {
    await addCustomLayersAndSources();
});

Obviously, there's a lot more you can do - but I hope this shows just how quickly you can get a clustermap working on a globe.

Huge thanks to Gene Liverman for having me on.

It is available, as they say, wherever you get your podcasts.

A few weeks ago, Stuart Orford added the thirty-thousandth entry!

Here's what all that collective human effort looks like when plotted on a very exciting graph.

Using a proprietary mix of AI and BIG DATA, I can confidentially predict that there is a slight uplift in entries when the weather is nice. And, by the end of the decade, every bench in the solar system will be mapped.

You'll notice we've had more than 30k submissions. Some are duplicates - which I then merge with the originals. Some are not memorials - which I delete.

More Stats!

We have 535 registered users. Registration is optional for submitting - but mandatory if you want to edit an existing entry. Users can sign in with Twitter, Facebook, WordPress, GitHub, and LinkedIn - I'd like to add Mastodon, but Auth0 doesn't support it.

Photos have been taken with 455 different cameras. Ranging from the obscure DJI FC330 (one photo) to the ubiquitous Motorola G(7) Power (9,825 photos). You can see all the different cameras and their statistics.

The 69,074 photos which have been uploaded take up 281GB of disk space.

Bandwidth is about 5TB per year. About 1.5TB of that was an incredibly aggressive "AI Crawler" which has since been blocked.

We deliberately do not track visitor numbers. But Google's search console says we get about 170,000 impressions per year, and about 12,000 click throughs. However, Google refuses to index the majority of our pages. No idea why - it's has crawled them, but won't show them in search results.

18 people have contributed to our Open Source code on GitHub.

A few times per year, people ask if they can use our data with OpenStreetMap. The answer is yes, our data can be reused. But there are two caveats. Firstly, our data includes historic benches which may not be present any more. Secondly, our benches are mapped with GPS, so might not give a location which is accurate enough for OSM. There is some ongoing work to see if they can be combined. We're not competing with OSM - you should use them for mapping.

We've sold about a dozen t-shirts, mugs, stickers and other merch. Doesn't bring in a huge amount of cash, but it is delightful to see people wearing the gear. We've had a few sponsors on OpenCollective and GitHub Sponsors. Again, not life-changing amounts of cash - but keeps things ticking along without adverts.

What's next?

When we go on holiday, we take photos of benches - and we hope you do too!

That's all we want from this site. No VC buyout. No AI / NFT / Crypto grift. Just people exploring the psychogeography of their surroundings.

You can get involved by taking a geotagged photo of a memorial bench and uploading it to OpenBenches.org.

Most hobby sites and side projects don't cost a lot to run. Lots of services have generous free tiers to (ab)use, and they can pay well in "exposure". But OpenBenches is reaching a tipping point where it is slowly overwhelming us.

We've now got nearly 300GB of photos - which means our storage and bandwidth costs are on the high side. Yes, we could losslessly transcode them all (which takes up compute resources) or store them in Glacier (which involves transit costs) and get a better CDN (as opposed to using free tiers). Similarly, we do a lot of forward and reverse geo-coding, OCR, map drawing, and other little bits and pieces.

Basically, assuming we value our time at zero, OpenBenches costs us about £250 per year.

Now, that's not extravagant, but it's also not nothing. So, how do we make it cost neutral to us?

Having a paywall is the antithesis of open data.

Placing adverts next to memorials and expressions of grief feels grim, so we've decided against advertising.

We don't think that a VC is going to invest a million bucks into this. But, hey, if someone out there wants to make us an offer...

That leaves us with merchandising and sponsorship.

Merch!

We've opened a shop on Spreadshirt.

Spreadshirt is pretty easy to use. Upload a graphic, select your products, launch. Each t-shirt brings us in about £4 after VAT. So far we've sold half a dozen things. Early days, but promising. It's a fairly low effort way to (hopefully) get in a trickle of cash.

Sponsorship

Perhaps you have enough t-shirts from random websites? Wouldn't you prefer a shout out on the website and unending gratitude?

We've set up GitHub sponsors but, infuriatingly, it only accepts donations in USD - which means hefty foreign-exchange fees. Luckily, Open Collective accepts payment in GBP which is a lot easier to manage.

Between the two of them, we've had about £175 so far this year. Again, a promising start.

Other plans

I'm not (para)social enough to do a Patreon. I don't want a job of delivering monthly newsletters, livestreaming my coding, or keeping the hype train running. I don't want 1,000 True Fans. In short, we're not trying to make a profit out of this.

We just want to keep the site running for the foreseeable future and, hopefully, pay a bit forward to the brilliant Open Source projects we're built on.

For now we'll stick with those and see how the year plays out. If you have any clever ideas for how to make the site more self-sustaining, please let us know.

Photo CC BY-SA from Lewis MacKenzie.

It is a perfectly pleasant little memorial poem. I wondered about its origins.

A quick search shows that the opening couplet was used on war graves from 1916. But are its origins any earlier than that?

One of the problems of trying to search old records - especially newspapers - is that text recognition isn't particularly effective.

But the British Newspaper Archive has these examples from 1900:

The poem is different - and much less secular.

I wasn't able to find anything earlier than the year 1900.

Websites have variations of the poem, suggesting it might be from earlier.

Dennis Townsend's headstone is cut with a family dedication that in one form or another has been in use from the late Victorian period - The cup was bitter the loss severe to part with one we loved so dear. The Thurmaston Military Indexes

That search took me back to 1891:

By searching variations, it's possible to find this from 1885:

The following is the epitaph : The cup was bitter, the sting severe. To part with one we loved so dear

The inscription can also be found on the Saunders Mausoleum in St Pancras & Islington Cemetery.

Photo © Marathon (cc-by-sa/2.0)

John Daniel Saunders died in the 1870s - but the inscription may be from after the death of Mary Saunders, his wife, in 1888.

There's a similar vintage inscription recorded in "Transactions of the Devonshire Association for the Advancement of Science, Literature and Art (Volume 29)"

Google books thinks the phrase appears in 1857's Designs for Christian Memorials. But doesn't have a searchable PDF.

There is a searchable 1886 edition - but that doesn't contain the phrase.

The phrase pops up around the world - newspaper archives suggest it was popular in New Zealand. It also appears in the British cemeteries in Quetta, Baluchistan, Pakistan in 1888:

At which point, the trail goes cold. At least for my limited resources. How curious that a snippet of a poem from nearly 150 years ago still resonates today.

I jest. But only a little. When I build for myself I treat best practices and coding styles as harmful. Chaotic evil but, hey, it's only myself I'm hurting.

Anyway, my wife and I run a hobby site - OpenBenches.org - which was coded in a long alcopop fueled weekend. It's fair to say that it has exceeded our expectations in terms of people getting involved. But is underwhelming in terms of stability, speed, memory usage, efficiency, idempotency, and accessibility.

So I decided to rewrite it using a somewhat modern PHP framework. Partly to improve things and partly as a learning exercise.

I picked Symfony as it seemed to be under active development and had a reasonably simple "getting started" guide. The documentation looked good but, sadly, assumed a tonne of pre-existing knowledge. I ended up sending a few Pull Requests to improve it where I could.

Symfony suffers, like a lot of frameworks, from messy and inconsistent conventions. Some things are zero indexed, some from one. Why? Who know? Similarly, there are a bunch of random YAML (yeuch) files which need to be manually edited and a tangled mess of various config files scattered around.

But... in the end, the Symfony server is reasonably easy to use - with relatively sensible conventions and decent performance. It forced me to actually think about what I was doing and why I'd chosen certain conventions.

I won't claim it to be the best written code on the planet - and there's still some way to go in order to clean it up completely - but I'm pleased with the way things have turned out.

If you'd like to get involved - check out the code

We gave a talk about OpenBenches and how far it has come since launch. It blows our minds that we've have over TWENTY-SIX THOUSAND unique benches added to the site. And it is a little daunting to host nearly a quarter of a terabyte of photos from around the world.

We got lots of great feedback (and free beer). Yes, it was weird to be in a crowded lecture theatre again. And weirder still to be in a crowded pub talking about mapping with friends new and old.

All in all, an excellent night out.

You can read a summary of the event at:

Along with some nice feedback:

Our presentation wasn't recorded, but you can flick through it:

It is all good advice. But I gently disagree with the slide which says:

Avoid side projects with user accounts If it has user accounts it’s not a side-project, it’s an unpaid job

I get the sentiment. Storing passwords securely is hard. Dealing with users changing their names is hard. Updating avatars is hard. GDPR is hard. It's just a lot of pain and suffering.

But I still have user accounts on one of my side projects while avoiding all those issues. Here's how it works on OpenBenches.

Use Auth0

The Auth0 service is a multi-vendor OAuth provider. That means I can offer a button which "login" which leads to this screen:

Auth0 has around 60 different social login providers. I picked the ones which best suited my users' demographic.

So the user hits "Sign In With Twitter⁰", gives Twitter their username, password, blood sample, and 2FA token. Twitter gives OpenBenches an authentication token with read only access.

This is important. Even if I were hacked and the tokens stolen, an attacker wouldn't be able to alter the user's account on a different platform.

But, as it is, I don't store the token. So it can't be stolen.

Only store the essentials

Here's the database which contains my user "accounts":

CREATE TABLE `users` (
  `userID` bigint(20) NOT NULL,
  `provider` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
  `providerID` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
  `name` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

The userID is just an internally-used key which is incremented. I guess it could be a GUID or something.

The provider is a string like twitter or facebook or linkedin etc.

The providerID is the publicly available ID assigned by the social login service. Twitter gives everyone a number, LinkedIn gives everyone a random string, etc.

The name is the string that the provider calls you. My Twitter name is @edent and my LinkedIn name is Thought Leader Terence Eden.

That's it! I don't store any access tokens. I don't store a date of birth. I don't store any data unnecessary to running my project.

What about updates?

I don't store URls to avatar images. Instead, I use Cloudinary's Social Avatar service. That's usually as simple as calling res.cloudinary.com/demo/image/twitter/1330457336.jpg - I have to fuss around a little for GitHub and Facebook. So as soon as the user changes their avatar with their provider, it changes on my site.

Sometimes people change their names. Every time they log in to OpenBenches, I check to see if their name has changed - and update it if it has.

Most services don't let you change your internal ID. So that's fixed.

Where it goes wrong

It isn't all sunshine and roses though. Here are two things which might give you cause for concern.

What if a user wants to merge their accounts? On OpenBenches we sometimes get users who set up two accounts - and then want data from each of them merged. So far, my answer has just been "no".

What if a user wants to delete their account? Well, they can delete it with Twitter or whoever. If someone asked, I'd probably delete their username from the table. But it hasn't happened yet.

Should you do this?

I'm not your real dad. It isn't my job to tell you how to live your life or set up your side projects.

Generally speaking, user accounts are bad news. We resisted having them on OpenBenches for the longest time - people were anonymous. But we had lots of users who wanted a leader board so they could show off how many benches they had uploaded. The only way we could build that is with user accounts. So we added it. You can see the Leader Board in action.

Building side projects can be a bit lonely. So it is sometimes nice to develop a community of people who want to use your stuff.

You can view more at This Bench Does Not Exist.

Here's a video which shows how the process generates images. It gives you an idea of what the model "thinks" a bench is.

Download the model

You can download a 300MB StyleGAN neural net .PKL for your own use.

WHY?!?

What does a bench look like? How can you recognise it? Does the human brain process images of inanimate objects differently than it does with faces and animals? Is there an "uncanny valley" for seats?

5 years ago, my wife and I launched OpenBenches - a site to crowdsource photos, inscriptions, and locations of memorial benches. We have been astonished at how popular it has. People have uploaded over 55,000 photos of about 22,000 benches! That's around 191GB of photos. Nice ☺

I wanted to take all the photos of the benches, and train a computer to produce artificial images of benches. In a similar vein to This [Cat|Person|Paper] Does Not Exist, it's just an interesting way to show off how good (or not) computers are at generating images based off a large dataset.

HOW?!?!

It is relatively simple to create this. There is a pre-built set of scripts called StyleGAN3. You can follow along with the tutorial provided. I was doing relatively well, until I hit the system requirements:

1–8 high-end NVIDIA GPUs with at least 12 GB of memory. We have done all testing and development using Tesla V100 and A100 GPUs.

Ah. I don't even have one NVIDIA GPU - let alone 12! And the sponsorship for OpenBenches barely covers hosting. Let along buying expensive hardware.

I put the call out on Twitter and, very kindly, Simon Butcher volunteered some hardware. Aren't people on the Internet nice!

The computation for the 512x512px training set was run for 20 days on an IBM AC922 POWER9 server running RHEL7, utilising all four Nvidia Tesla V100 SXM2 16GB GPUs.

The OpenBenches API lets us grab the URls of all images, and metadata about whether they're a photo of the inscription or the bench. There were about 25,000 photos to download and crunch through.

With that many images, it wasn't possible to manually go through to find images which shouldn't have been in the set. That might have led to some weirdness in the generation process.

COPYRIGHT?!?!

OK, so here's an odd question. All of the photos on the site have been licenced under Creative Commons. Mostly BY-SA 4.0 but a few imported from Flickr and other sites with different CC licences.

What's the copyright situation of the generated images?

I honestly don't know. If you do, stick a comment in the box below.

WEIRD?!?!

There are a number of "glitches" which seem inherent in AI generated images. Some are just weird little graphical quirks.

It's pretty easy to see where the AI has got a little confused. It is totally recognisable as a bench - but just the wrong side of the "uncanny valley" to look real.

Others, however, are full-on psychedelic hellscapes.

Inscriptions

Training a text model using GPT-2 was relatively easy. A few years ago I taught an AI to write Shakespearean sonnets. I used the same Google notebook to read in several thousand inscriptions and then generate new ones.

But… we decided not to use them in the end. It's downright creepy generating the name of someone and their date of death. It would be horrible to stumble on the website and find the details of you or a friend listed on there.

As there have already been lots of attempts to automatically generate semantically valid text based on an existing corpus - we dropped it from the site.

THANKS!!!

Huge thanks to:

• Simon Butcher for training the model on his supercomputer.
• Tom O'Connor for the doesnotexi.st subdomain.
• All the hundreds of people who have generously uploaded their photos to OpenBenches.

Here is another video for you to enjoy:

Soundex is a clever algorithm for reducing a string of characters into a string which roughly represents its pronunciation. The "roughly" is key here. We could just search the database for identical entries, but users often mistype entries. So comparing sounds is a good way to gloss over those mistakes.

This gives us the Soundex of every inscription in the database:

SELECT soundex(`inscription`) FROM `benches` WHERE 1 

Which results in:

|soundex(`inscription`)                               | 
|=====================================================|
|D531323161545613216323                               |
|J51616565324126143216316531414                       |
|D232624132635253263532154                            |
|H6432534215361312345252342525321625342323153423163...| 
|A2316215635                                          |

Effectively, it's like a fuzzy hash for text.

So, here's how to get a list of all the Soundexs which have duplicates:

SELECT `inscription`, SOUNDEX(`inscription`), COUNT(SOUNDEX(`inscription`))
    FROM    `benches`
    WHERE `published` = 1
    GROUP BY SOUNDEX(`inscription`)
    HAVING COUNT(SOUNDEX(`inscription`)) > 1
    LIMIT 0 , 1024"

Which I can then use to produce a list of duplicates:

And I can then get a list of all benches with a specific Soundex:

SELECT `benchID`, `inscription`, `address`
    FROM    `benches`
    WHERE  SOUNDEX(`inscription`) = "A123"
    AND  `published` = 1

In this case, I can see that they're similar but not identical - so I don't need to merge them.

I started off with a thousand possible duplicates and, after going through each of them, merged a couple of hundred dupes. That was a fun weekend!

Other Strategies

There were a couple of other things I thought of, and then discarded, to deal with dupes.

Ask the user on upload

This is probably the simplest. If a new upload has a similar Soundex to a nearby bench, ask the user if it a duplicate. But, actually, that's fraught with complexity. It puts a lot of pressure on a new user to get it right. And, frankly, we're a tiny community which needs all the users it can get. So I decided to put the pressure back on me, the admin.

There are quite a few benches near each other which have identical inscriptions. So asking a user to check which bench they meant could also be complicated.

Which leads on to...

Check proximity

There are lots of benches near each other. That's understandable. But calculating how near any two benches are is a bit more complex. They're stored in the database with separate latitude and longitude values. So, we can use the Haversine formula to find all benches within, say, 250 metres of position 1.23,4.56:

SELECT
(
    6371 * ACOS(COS(RADIANS(1.23)) *
    COS(RADIANS(`latitude`)) *
    COS(RADIANS(`longitude`) -
    RADIANS(4.56)) +
    SIN(RADIANS(1.23)) *
    SIN(RADIANS(`latitude`)))
)
AS distance, benchID, latitude, longitude, inscription, published
FROM benches
WHERE published = true AND present = true
HAVING distance < .25
ORDER BY distance

That's fine - but when combined with Soundex, it becomes much more complex. Effectively you then have to group similar sounds by geographic closeness. And, frankly, I really can't be bothered!

If you'd like to help out, the code to OpenBenches is open source.

Cameras and phones all have different ways of naming the photos they save. Some files are named with a datestamp - 2019-12-25_01.jpg. Others are sequential - photo_0001.jpg. Or they might have a system generated name - 7bba245908_k.jpg.

Storing all those photos in a single directory gives us a problem. What if two photos have the same name? Even if we split directories by username, or some other factor, we could still get clashes.

This is the solution we came up with:

1. Take the hash of the photo. e.g. A9342C5C39E5AE5F0077AECC32C0F81811FB8193
2. Rename the photo to the hash, add a .jpg extension.
3. Move the file to the /photos/A/9/ directory. i.e. The first directory is the first letter of the hash, the sub-directory is the second letter of the hash.

Why do this?

There's another practical reason to split files into sub-directories. What's the maximum number of files you can put in a directory?

For FAT32, it's 65,536. We're about halfway there! OK, let's hope I never have to move this code to an ancient Windows box!

Linux filesystems like ext2 have an apparent limit of 31,998 files per directory - but suffer performance issues over 10,000.

Even a default ext3 partition seems to suffer after about 2,000 files per directory.

Applying dir_index seems to improve things, but still limits us to "easily" 200,000 files per directory.

I don't know what software this might run on in the future. But it seems obvious to me that splitting files into 36 primary subdirectories reduces the risk of poor performance.

Or, perhaps we won't get billions of images of benches submitted, and this is the ultimate word in premature optimisation.

Is SHA1 the best hash?

Probably. SHA1 is not cryptographically secure. A well funded adversary could create a photo with the same SHA1 hash as an existing photo.

But I don't care. Our system just rejects any file with an existing hash already in the system. So the risk of attack is low. The chances of two legitimate photos having an identical SHA1 hash is miniscule.

And SHA1 is quick and efficient.

A word about metadata

We were originally planning to store the data in date-based directories. Or perhaps username directories. We even considered a separate directory structure depending on camera manufacturer.

In the end, it was easier to store the metadata in a database rather than relying on the vagueries of directory names.

The Future

I don't know how many photos we'll end up with. There are lots of benches.

This storage strategy means that I could mount a separate disk for each directory. In the future, when every bench in the world has a dozen photos, we could match storage needs to directory layout.

I'm sure there are better ways of organising large amounts of UGC - and I'd love to hear about them.

Ryan C. Gordon

@icculus

Google gave me an award for my contributions to Linux gaming and open source, and while I’m honored to be acknowledged, I can’t accept money from a company that is actively engaging in union busting.

---

Ryan C. Gordon

@icculus

Replying to @icculusWhen I agreed to the award, I hadn’t heard about @eiais’s firing, or any of the others. It’s not much money, but I don’t think quantity is relevant.

---

Ryan C. Gordon

@icculus

Replying to @icculusAs such: I’m announcing the 2019 Icculus Microgrant. If you have a cool open source project, reply here about it and the one I like best, I’ll give $250 dollars. Do whatever you want with the money. I’ll try to pick one this week.

If anyone wants to match my donation, DM me.

---

Ryan C. Gordon

@icculus

Replying to @icculus(If I don’t get any good projects, I’ll buy 250 bucks worth of pizza for the next Google organizing meeting or something. But if you’re proud of your project, tiny or not, that should be all you need to tweet it at me. Good luck!)

---

Huge thanks to Ryan, and everyone else who chipped in.

Because I'm part of GitHub Sponsors, the donation will be matched by GitHub.

So, that's US$500 - about £375. Nice!

If you'd like to sponsor us, you can do so on GitHub or via PayPal directly. Or, we have an Amazon wishlist if you'd like to get us a physical present.

What will we spend the grant on?

This is what we said we'd use the money for:

Terence Eden is on Mastodon

@edent

Replying to @icculus@icculus @mjg59 My wife and I run openbenches.org
It's an open source / open data project which crowdsources photos of memorial benches.
$250 would allow us to move away from Google's OCR engine, and on to a faster web host.

---

No one is auditing us, so we could spend it all on a luxury holiday to Bognor Regis. But we won't!

Although... There are a lot of unmapped benches in Bognor...

The web is cheap!

Don't tell anyone who wants to give us money, but it's quite cheap to run a niche site on the web!

We're lucky to be in the free tier of our 3rd party providers:

• OpenCage provides the reverse geocoding, and is free for 2,500 calls per day.
• CloudImage is free for small projects.
• Auth0 does social login - and offers more features free for Open Source projects.
• MapBox renders beautiful OpenStreetMap tiles for free, up to 50,000 per month.
• Google Cloud Vision we're just about within their 1,000 free scans per month limit.

We've occasionally gone over those free limits, so will keep a couple of quid in reserve in case of a surge in our popularity.

Our major cost is hosting. We paid £300 for 3 years of shared hosting with Krystal.uk - use code EDENT at checkout and we both get a fiver.

That hosting deal runs out in August this year, so the bulk of the grant will go to upgrading our package to something a bit bigger. Notably, we're capped at 2GB of RAM which we seem to regularly max out.

Because we have over 130GB of photos, we'll probably stay with Krystal - unless anyone knows of a UK based hosting provider with impeccable green credentials?

In the spirit of the grant, we'll look at moving away from Google's Cloud Vision. Current contenders are

1. Amazon Rekognition
   • Although they're just as ethically dubious
2. Microsoft's Computer Vision
   • Ditto!
3. The Open Source Tesseract OCR
   • Which is sponsored by Google...

Suggestions very welcome!

Unions

Regular readers will know that I'm a proud member of Prospect - the union for ambition. As a professional knowledge-worker, I rely on my union to provide me with legal services and support me in pay negotiations. If you're in the UK and want to be part of a union for professionals - join Prospect today.

If you join Prospect, and mention my name, I'll make a £10 donation to charity.

Here are some rough and ready numbers about how it has gone so far.

9,870 Benches

At the time of writing, we're a little shy of 10,000 benches. As you can see, we have photos from all around the world.

9,000 UK Benches

The majority of our benches are in the UK. Memorial benches seems like a peculiarly Anglosphere habit. I've spoken to people from all sorts of different countries, and they really are rare outside the English-speaking world.

110 Registered Users

That's over a hundred people signing in with Twitter. We've recently added Auth0 support, so people can sign in with Facebook and GitHub.

We also added a leaderboard so that our mate Jenny could see how many photos she added in Edinburgh.

We still have lots of anonymous users.

21,840 Photographs

Most benches have two photos - one of the inscription, and then another of either the whole bench or a view from the bench.

We also have panoramic shots like this:

66GB of Photos

All that media is pretty weighty. Modern camera phones take high-res photos, and a typical shot is around 4MB.

At the moment, our hosting provider is holding up. Huge shout out to Krystal Hosting - use discount code EDENT for £5 off.

I am looking at using Cloudinary to speed up resizing and delivery. But at close to $100 a month, that's too much for a small hobby project.

Hundreds of Moo Cards

Terence Eden is on Mastodon

@edent

Printed out loads of @openbenches moo cards in preparation for Open Data Camp in Aberdeen! Made with ♥ out of #OpenData

Free tickets available tomorrow.
#ODCamp6 #odcam pic.x.com/dVnUQt8Odn

---

Get 25% off your first Moo Card order!

261 Commits, and 8 GitHub contributors

The whole site is open source on GitHub - and it has been lovely using the issues tab to discuss where the site should go next.

Lots of Fun

But, most importantly, it has been a lot of fun. It's wonderful seeing people from around the planet contributing. Thank you to everyone who has submitted a bench, shared our links, or generally been supportive of this daft little endeavour.

Here are some of the benches which made us smile:

And, finally, Liz and her mum in New Zealand - sat on the bench dedicated to Liz's grandparents.