Hi y’all, I’m writing this with 2 hats on.
Hat 1, app dev: I make https://www.flashes.blue and https://www.skeetsapp.com. Both are about to ship locations: Flashes will let people say where their photos and videos were taken, Skeets will get check-ins.
Hat 2, Eurosky: to power that, we’ve just started places.eurosky.tech, a place service for the open social web. Behind the URL:
-
a worldwide gazetteer rebuilt monthly from Overture (places, divisions, addresses), Foursquare Open Source Places and OpenStreetMap;
-
records merged across the sources (~112M places), ranked with Wikipedia importance.
It offers:
-
suggestions for a position: nearby places, the street, and the areas that contain it (district, city, country), for e.g. a check-in picker;
-
type-ahead search;
-
a privacy-preserving fixed ~1 km squares query API: cacheable, and the server only learns which square you asked for.
It’s built on ATGeo’s conventions: every place carries its ATGeo URN in origin (plus sameAs for the same place in other sources), areas are Overture divisions as in garganorn, and the squares follow garganorn’s idea that a client fetches a whole area so the server never learns its position. It also answers org.atgeo.getPlace, so ATGeo clients can look places up by URN (for example McDonald’s at Hermannplatz); the tile interface (getTiles) could follow if ATGeo apps want a European server. The code is public: https://github.com/eurosky-social/eurosky-places
Before my apps ship, I’d like to agree the record format with you rather than add yet another one. This picks up the check-in thread from last summer, this time with something concrete.
Here’s the draft: https://github.com/eurosky-social/eurosky-places/blob/main/docs/place-pin.md (lexicon: pin.json)
The short version:
-
A small record next to the post, one place per record. It can be limited to some of the post’s photos or videos, named by their blob CIDs, so it works for any media in any app. Without a post it’s a check-in on its own.
-
It follows where we landed in 2025: no
at://URIs for external places. The record carries the place’s ATGeo URN inorigin, plus the subset readers need: name, a coarse category, a point, the containing areas and the place’s IDs in other sources. It uses the same field names asorg.atgeo.place, andcommunity.lexicon.location.*objects for locations. About 0.5–1.3 KB per record. -
The author picks the level: venue, street, district, city, region or country. Coordinates are rounded to it, and the device’s own position is never written.
-
Readers can group by
origin(andsameAs), draw maps and show thumbnails without any gazetteer lookup or fetching the post. Constellation could answer “all pins at this place”.
It’s under our namespace (social.eurosky.place.pin) for now but I’d rather see it become org.atgeo.checkin or a lexicon.community record if that’s the better home.
Questions I’d love input on:
-
Home:
org.atgeo.checkin, lexicon.community, or leave it with us? -
The dataset name for Foursquare in URNs (we currently use
foursquare.com). -
A shared coarse category list, or app-defined?
-
Is a pin without a post the check-in record, or should a check-in be its own record with text?
Some things we learned building the service that may help garganorn:
-
Foursquare Open Source Places isn’t discontinued. It has been gated on Hugging Face since October 2025, and works with a token once you accept the terms.
-
Only ~38% of Overture place IDs survived a year (Overture re-matched its places in July 2026), against ~99% of Foursquare IDs over 19 months and ~97% of OSM IDs over 5 months. That’s why the draft puts the longest-lived ID in
origin. -
Overture’s September 2026 release added company-registry records (BrightQuery) that aren’t venues. Also, Overture’s own “signals” source shouldn’t count as a second confirmation.
-
Overture piles up records at a city’s reference point when it only knows the town: 428 at one point in Nairobi, including national parks.