Attention AtProto app developers: have you tried incorporating location data into your app? If you’ve got a strategy and are building momentum, please drop a 
in the comment section. If you are stuck, post two comments. This is Part 1 of 5, with a continuation later as I’ll be off the grid next week. Thanks in advance for your patience, I won’t be able to get back to you right away, but I WILL get back to you.
First, definitions. Way back in April when I was first introduced to this space, did a little exploration I called Understanding User Journeys in the ATmosphere. Looking back at that and boiling it all down, there are two applications of location data that make sense in the context of ATProto / Bluesky:
- Search and geotagging: what I mean by search is a “location” box ideally with autocomplete that prompts users to attach or geotag a location, e.g. to a post, profile or photo (note: no to a person, see personal location section below).
- Geofencing and topology: what I mean by geofencing is using spatial relationships to define the status of a location, and by topology I mean defining the relationships between spatial entities, e.g. is this post, profile, or photo near or within or not in a separately defined spatial entity, such as my house, Adler Planetarium, Moscone Center, Seattle, or Wisconsin?
There are two additional applications of location data that make sense in in the context of Bluesky:
- Personal location: what I mean by personal location is any location data derived from a person, e.g. a photo, mobile phone, or other personal device. Note that even though the location aspect of EXIF data attached to a photo is often referred to as a “geotag”, I am defining that data here as personal location data, a.k.a. PII (personally identifiable information) because it carries different legal implications than geotags as defined generically above.
- Maps and geographic data visualizations: this could be a reference map with a marker or pin representing a location, either a UI element as a static thumbnail, or as an interactive map surface allowing for many types of interactions. It could also be a thematic map or data visualization that aggregates locations or shows their density, such as a heat map, hex bin aggregation, cartogram or flow map.
Beyond this point, my assumption is that your use of location data fits one of these four categorical definitions. I could be wrong, or my definitions could be insufficiently inclusive or clear. If you have an application of location data that doesn’t fit the above definitions, please shout it out!
Otherwise, read on. In my next post, I will further illustrate how and why Search and geotagging and geofencing and topology are areas where an ATProto data commons can be useful and beneficial, whereas personal location and maps and geographic data visualization must (in most cases) be domains of individual app developers.