Similarly, if I bump into an old acquaintance at a conference, we both tend to say "If only I'd known you were here, we could have had dinner together last night!"

I do enjoy the serendipity of events like FOSDEM - randomly seeing a mate and expressing the joy of spontaneity. But I also like arranging to meet up in advance.

At the moment, my strategy is sending a blast on social media saying "I'm visiting [this city] next week, anyone fancy a beer and a natter?" I've met friends all over Europe, Australia, and New Zealand that way. It mostly works. But I can't help feeling it is inefficient and prone to missing connections.

I even wrote my own code to auto-post FourSquare checkins to my other social media sites.

Here are my ideal scenarios. Imagine something built in to Signal / WhatsApp / Whatever app you already use.

Plan In Advance

I tell my app that I'm going to Barcelona from 14th - 19th February and am happy to meet any of my friends.

✨Background Magic✨

My friend Alice has also planned a trip to Barcelona around those dates. She gets a ping saying that one of her friends is going to be in the same city. Does she want to know more?

So far, so Dopplr.

My friend Bob lives just outside of Barcelona. He's set his "willing to travel" settings to be about 30 minutes, so also receives a ping.

I don't know that either of them have seen the notification until they decide they want to meet.

Spontaneous Fun

I step off the train in Manchester, England England. Perhaps the app notices I'm away from home, or maybe I press the "Anyone Around?" button.

On a map I can see friends who have shared their rough location. I decide to message Chuck to see if he's free for a chat.

Dave notices my location is now within his preferred travel distance. He gives me a ring.

A bit like how FourSquare used to be - but with less precision.

Downsides

The above is very much the "happy path". It doesn't look at any of the knotty problems or grapple with the UI that would be needed to make this work. But we know the technology for sharing location is viable - so what are the social issues that make this so difficult?

Social Awkwardness

"Oh, fuck, Edgar's location says he's in town. Can we pretend to be out of the country?"

Alternatively, "Huh, I know at least a dozen people who live in Skegness. Why aren't any of them responding to me?"

Social pressure and awkwardness are hard problems. No one wants to use the app that makes you feel like a friendless loser.

Privacy

Do you want your friends knowing your every movement? I'm sure some people do, but most probably don't. It's possible to sketch out some vague controls:

• Only send a notification if I push this button.
• Don't send alerts if I am within this radius of my home / work.
• Fuzz my location to the city / state / country level.

Danger

Is it a risk to let people know vaguely where you are? Is meeting up with (semi-) strangers from the Internet a smart life choice? Is having an app stalk you across the globe giving too much data to advertisers?

Does that creep from work abuse the system to keep popping up whenever you're out with friends?

Technology

I said the technology exists for this, and that was sort of true. Every device has GPS & an Internet connection. Storing a log of friends and sending them a message is a solved problem.

But is it solved in a decentralised and privacy preserving way?

No one wants to give all this power to one company. Google will build it and kill it. Facebook will sell your secrets to dropshippers. A funky start-up will be acquhired by Apple & restricted to iOS devices.

My location is fuzzed to an acceptable degree of imprecision and then sent… where? To all my friends directly? To a central server? Can k-anonymity help?

Is this a separate app? Everyone seemed to leave FourSquare after they buggered around with it. Perhaps it is just a feature in existing apps?

What's Already There?

Messaging apps like Signal, Telegram, and WhatsApp allow you to share your location with one or more friends.

To me, it feels a bit weird to manually send a dropped pin to some / all of my contact. It also doesn't let you share "tomorrow I will be in…"

Using "Stories" is the common way to share an update with all contacts - but none of them let you automatically share your location in a story.

FourSquare's Swarm app allows you to check in to a "neighbourhood". But there's no obvious way of saying "London" or "Manchester" - and I'm not sure how close to an area you need to be to get an alert that your friend is there.

What's Next?

I don't want to build this. Trying to get everyone I know to adopt a new app isn't going to happen. With the fragmentation of messaging and the lack of interoperability, this is likely to remain an unsolved problem for some time.

So here's my strategy.

• Get back in to using FourSquare. Most of my friends seemed to stop using it back in 2017 when it was split into Swarm. But a few are still on there.
• Manually post a story on Mastodon, BlueSky, Facebook, WhatsApp, Signal, and Telegram saying "Visiting Hamburg next week. Anyone want a beer?"
• Hope that something better comes along.

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.

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?

So, is there a way to recreate that early Web 2.0 experience with open data and ActivityPub? Let's find out!

This quest is divided into two parts.

1. Get nearby "Points of Interest" (POI) from OpenStreetMap.
2. Share a location on the Fediverse.

OpenStreetMap API

OpenStreetMap is the Wikipedia of maps. It is a freely available resource which anyone can edit (if they're skilled enough).

It also comes with a pretty decent API for querying things. For example, nw["amenity"]({{bbox}}); finds all "amenities" near a specific location.

As you can see, it has highlighted some useful areas - a pharmacy and a pub. But it has ignored other useful locations - the train station and the park. It has also included some things that we may not want - bike parking and a taxi rank.

What API call is needed to get useful locations of of OverPass?

It's possible to specify the type of thing to find using nw["amenity"="restaurant"]; - but adding every single type of thing would quickly end up with a very large query containing hundreds of types.

It is also possible to exclude specific types of places. This retrieves all amenities except for fast food joints:

nw["amenity"]({{bbox}});
-
nw["amenity"="fast_food"]({{bbox}});

Again, that would be complex.

Perhaps one solution is just to return everything and let the user decide if they want to check in to a telephone kiosk or a fire hydrant? That's a bit user-hostile.

Instead, this query returns everything which has a name nw["name"]({{bbox}});

That cuts out any unnamed things - like park benches and car-sharing spots. But it does add named roads and train lines.

It is possible to use filters to exclude results from OverPass. The best that I can come up with is: nw["name"][!"highway"][!"railway"][!"waterway"][!"power"]({{bbox}});

That gets everything which has a name, but isn't a highway or railway or waterway or powerline. It isn't perfect - but it will do!

This is the query which will retrieve the 25 nearest things within 100 metres of a specific latitude and longitude. It includes the name and any other tags, the location, and the OSM ID.

overpass-api.de/api/interpreter?data=[out:json];nw["name"][!"highway"][!"railway"][!"waterway"][!"power"](around:100,51.5202,-0.1040);out center qt 25;

ActivityPub

There's good news and bad news here. Firstly, ActivityStreams (which are subscribed to in ActivityPub) supports the concept of "Place" and "Location".

Once the user has a latitude and longitude, the can share it - along with a message, photo, or anything else.

Something like:

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Note",
    "content": "Here in NYC! <a href=\"https://www.openstreetmap.org/way/958999496\">John Lennon's Imagine Mosaic</a>.",
    "attachment": [
        {
            "type": "Image",
            "mediaType": "image\/jpeg",
            "url": "https:\/\/fastly.4sqi.net\/img\/general\/590x786\/56367_9pxuZJD7d1hgPdaMFcFq1pipvTTMynBJsYcpHH-b8mU.jpg",
            "name": "A photo of a mosaic which says 'Imagine'."
        }
    ],
    "location": {
        "name": "John Lennon's Imagine",
        "type": "Place",
        "longitude": 40.77563,
        "latitude": -73.97474
    }
}

For example, here's a PixelFed post with an attached location - and this is the JSON representation. That status can be reposted into other social networks.

It is worth noting that Mastodon doesn't (natively) support location - if you view my repost of that PixelFed post you'll see there's no location metadata attached. That's OK! It just means that the status needs to include human-readable data.

Similarly, Mastodon doesn't support the arrive vocabulary. So this will be limited to a message with a location attached.

Other ActivityPub services do support location.

Putting it all together

Well… that's a job for next week. Probably!

• Building a web site which gets the user's location is easy.
• Getting the data from OverPass should be straightforward.
• Creating an ActivityPub server which can post geotagged notes into the Fediverse might be a little beyond my skillset! Some testing with Darius Kazemi's AP Glitch suggests this should work.

If you'd like to help, please leave a comment.

Peugeot's new mobile advert has a couple of critical flaws - but has just enough innovation to redeem it in my eyes. Read on to find the two basic mistakes they made, how to solve them, and the cool feature you should be incorporating into your adverts.

Clicking on the advert takes you onto a fairly swish looking landing page. There are some clear calls-to-action, and some attractive graphics.

I find the text a little hard to read. Let's zoom in.

Yikes! The whole site is an image! This is incredibly bad practice for several reasons.

• The page weight will be excessive. This means your site will be slow to load and possibly cost your customers more to access it.
• Inability to zoom in. With some smartphones like the X10mini having tiny screen, you need to consider how your site will look over a wide range of devices.
• SEO. Search engines can't read images. Plain text will ensure your site is spidered.
• Reflowing - what happens when the user rotates the screen? Your image won't scale and reflow as well as text.
• Updating. If you need to update the site, you'll have to edit a series of images - one for each screen size. With text, one change and you're done.

In Praise of...

The usual "Find A Dealer" service asks the user to type in their postcode or some other location based detail. I'm very pleased to say that Peugeot goes one step beyond this. They take advantage of the geo-location api of the phone so that the user doesn't have to do any extra work. Brilliant. This is a great use of the technology. Let computers do what they do best and reduce the need of your user to type data in. You can use a cross-platform geo-location solution like Google Gears to detect your users' location.

Ideally, the domain name should be that of the product.  The user probably doesn't know who "sevenal-fit.com" are - but they would recognise "peugeot.com".

Text Effects

This is the final fly in the ointment. Is this piece of text a link? How about this one? What about this?

By convention - and good usability practice - links are styled differently than regular text.  Usually by underlining or displaying in a different colour.  It helps the user see what actions they can take on a page.  Have a look at this results page and see if you can tell what you can click on.

Not very intuitive - is it?  It looks like a list of results with no further information.

As it happens, you can click on the dealer names.

Again, there's no text decoration.  While it's good that they've used click-to-call for the phone numbers, there's no indication until you've placed your finger or cursor over the text that it's a link.

Don't make your users think.  Clearly signpost the actions which are available to them.

It's also worth including a map of the area - or even directions from the user's current location.  Remember, the end goal of this advert is to make someone buy a car.  Make it as easy as possible for your users to go from advert to purchase.

Conclusion

Text is better than images.

Remember to decorate your text correctly.

Geo-location is awesome - but don't forget to display a map.

Finally, consider which domain name the users will see and if they will trust it to store their data securely.

As a base experiment, I passed the postcode of a polling station (GU22 7DT) to both Google Maps and Yahoo Maps. Here are the results.

-

Two things of interest to note.

Firstly, Google has a specific "Mobile" call in the API, it reformats the map image to be more readable on the mobile - I think you'll agree that Google edges out Yahoo here.

Secondly, Google maps is less accurate than Yahoo! Maps. Severely so. While maps.google.com is highly accurate when passed a postcode, the API seems only to look at the first part and discard the rest. Yahoo on the other hand is unnervingly precise.

What to do? Well, as all the cool kids are doing, let's have ourselves a mashup!

We can call Yahoo Maps to get the Latitude and Longitude of a postcode thusly http://local.yahooapis.com/MapsService/V1/geocode?appid=YD-9G7bey8_JXxQP6rxl.fBFGgCdNjoDMACQA--&zip=gu227dt&state=uk This will return <Latitude>51.318691</Latitude> <Longitude>-0.543540</Longitude> <Address/> <City>Woking, GU22 7DT</City> <State>United Kingdom</State> <Country>GB</Country> We take the Latitude and Longitude and pass it to Google Maps like so http://maps.google.com/staticmap?center=$lat,$long&markers=$lat,$long,tiny&zoom=14&size=240x240&maptype=mobile&key=&sensor=false Which nets us this map.

Google Map from Yahoo Geo Location

Hey presto! Better looking than the Yahoo Map and better accuracy than the Google Map.

The geocoding prescision of the Google Maps API is very poor for UK postcodes. There really shouldn't need to be this need sort of work around.

This is the sort of data that the UK government should be providing. The Ordnance Survey have an API but it seems restricted to JavaScript which isn't very useful for most mobile phones. Nevertheless I'll have a play with it and see if it's more useful.

Edit

I am now using Ernest Marples' Postcode Latitude/Longitude Lookup API which has much greater accuracy than either Google or Yahoo.