I have implemented a basic version of this for testing.

It supports the variables lat and lon or a single variable uri for geo URIs. There are two returns, venues or geo. Geo is a suggested location, venues would be a list of possible nearby venues. I am not returning any yet. And my return doesn't include specific properties for the location, even though I outlined that above. Just a name property.

{
"venues":[],
"geo":{
"name":"Queens, NY, USA","latitude":"xxxx","longitude":"yyyyy"}
}

It should be label, not name on the return as it is supposed to be an h-adr

Expanding on this thought to propose the following query choices..In all cases, q must equal geo, but, optional query parameters should be either:

• uri - a GEO URI, for example geo:37.786971,-122.399677;u=35
  or:
• lat and lat - latitude and longitude coordinates specified individually
• u as an optional uncertainty/accuracy parameter

I think allowing both of these would be preferable.

Outlined an example return. All returns would follow the common properties of an h-adr object with only label and latitude/longitude being mandatory. The visibility property would reflect the experimental location-visibility Micropub property outlined on the extensions page.

{ "geo": [ "label" : "123 Main Street", "latitude": "18.1123", "longitude": "-72.1933", "visibility": "public", ], "venues": [ { "label" : "Main Street Apothecary", "latitude": "18.1123", "longitude": "-72.1931", "url": "https://example.com/venues/apothecary", }, { "label" : "Main Street Market", "latitude": "18.1123", "longitude": "-72.1931", "url": "https://example.com/venues/market", }, ] }

The Drupal module now supports q=geo too. Geo is returned, if anything is found of course. Venues not yet, but that will come once I started on Indigenous supporting venues selection.

Oh, re: query parameters - I'd love to just keep one format. Currently latitude and longitude as query params are used in the Drupal module too. Makes it less complex imo.

As for 'venues' property in the response, maybe that should be 'places' ?

I'm fine with it being places. No one has implemented it yet anyway.

Also, I prefer the individual parameters myself.

Ok, the Drupal module documents to return an array of 'places' now, see swentel/indieweb#393

Indigenous supports the 'places' parameter in the upcoming release. If places are found, the location name field will have suggestions from the location query response.

Feedback at Micropub Popup Session 2020 was that this requires more research to document use cases and prior art. Furthermore, the venues property should use h-card, not h-adr syntax.

The use cases for this particular query would be twofold:

• To tag posts with a location. This would allow your backend to dictate the location text as opposed to it being dictated by the client. Indigenous allows editing of this text before posting. To @aaronpk's point, more people may want this to just work.
• To query for a list of venues to create a venue selection tool for checkins.