Skip to content

Instantly share code, notes, and snippets.

@schuyler
Last active March 31, 2025 18:57
Show Gist options
  • Save schuyler/9e7c75b253252072af80d2389ad54337 to your computer and use it in GitHub Desktop.
Save schuyler/9e7c75b253252072af80d2389ad54337 to your computer and use it in GitHub Desktop.

Questions for the ATGeo working group

Here are some potential questions for the ATProtocol geo working group to consider. Some of them may not be relevant and some may be nonsensical. This list is just meant as a starting point for discussion.

What is the mission of the working group?

  1. What problems are we trying to address within the Atmosphere?
  2. What's in scope for the working group? What's out of scope?
  3. How will we know if we are succeeding?

What is a gazetteer?

  1. Does the Atmosphere need definitive references to real-world places? For what purposes?
  2. Is the term "gazetteer" appropriate for our purposes? Do we need to define it?
  3. How is it similar to or different from a "geocoder" or "reverse geocoder"? Do we need to differentiate them clearly?

What is a location?

  1. What is a "location"? Is it simply a point coordinate or a geometry?
  2. Are (latitude, longitude, altitude) in WGS84 coordinates sufficient for all use cases?
  3. Are we considering supporting only venues / points-of-interest? Or do we want to support other geometry types, e.g. polygon boundaries?
  4. ATProtocol doesn't support floating point values. If needed, can we store complex geometries instead as blobs using standard location formats? (e.g. GeoJSON, WKT)

What is a place?

  1. What is a "place"? Is it just the combination of geometry and attributes? If not, what else is it?
  2. What attributes are required for a place object to be valid?
  3. What does a long-term durable reference to a real-world place look like?
  4. Can we future-proof such references against changes both in the real world and in the network? e.g. through combining name, location, URI, etc.?
  5. How do we address the reality that places often have many names, and in different languages?

How are places modeled in community lexicons?

  1. Can a "place" object be treated as just another ATProtocol record?
  2. Can a place dataset (e.g. Foursquare OSP, Overture Maps) be treated as a static ATProtocol collection?
  3. Can a "gazetteer" service be treated as an ATProtocol repository? In what ways is a gazetteer database definitely not a repository?
  4. Can a dataset vendor ID be used as a place record key? What limitations or requirements need to be applied?
  5. If datasets can be treated as collections, how do we compose collection NSIDs that reference the dataset provider's authority (in the ATProto sense)?
  6. Should we define Lexicon schemas that are specific to each dataset's attribute data model?

How is place data published to the Atmosphere?

  1. In what ways, if any, should a gazetteer service resemble a PDS on the network?
  2. Should gazetteer services use did:plc identifiers? did:web identifiers? handles?
  3. What kinds of collection metadata does a gazetteer service need to publish? Attribute schemas? Licensing terms?
  4. Can gazetteer services leverage existing query schemas, like com.atproto.repo.getRecord?
  5. What new query schemas do we need to define that are specific to place collections? e.g. geocoding, reverse geocoding, point-in-polygon?
  6. Is there any practical difference between a "definitive" gazetteer and one serving application-specific attribute data?

How do ATProtocol applications use location data?

  1. How can place records be referenced from other kinds of ATProtocol records?
  2. Can place records be composed into other kinds of ATProtocol records?
  3. Can existing, non-spatial ATProtocol records be annotated with place records? If so, how?
  4. Do we need to explicitly distinguish between public and private places?

How does the Atmosphere moderate location data?

  1. What concerns do we have about end-user safety? What needs to be built into the protocol? What recommendations should we make to app developers?
  2. What explicit considerations do we need to give to user-generated place records?
  3. Is there a functional difference between content moderation of place and real-world quality control?
  4. How do we enable these moderation processes?
  5. Is attestation of public gazetteer records desirable? How would it work?

Practical questions for the Working Group

  1. Which lexicons should the working group seek to publish?
  2. Where do we draw the line between protocol and application concerns around location data?
  3. How do we know when our lexicons are ready for publication? How frequently should they be updated?
  4. Are we planning to publish a complete user-facing reference application? UI components? Libraries?
  5. Should we draft and test an explicit threat model for bad actors employing ATProto location data?
  6. Should we draft and publish a moderation and safety guide? What are our guiding principles?
  7. Should we set up public gazetteer services under the auspices of lexicon.community? Who administers them? Which collections? How will costs be covered?
@thisisaaronland
Copy link

In the "What is a gazetteer" section I might add a corollary to question about real-world places:

  • Does (should) Atmosphere allow references to colloquial or imaginary places?

My favourite example is always "The body-scanner at SFO" which was added to Foursquare (along with countless other similar places).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment