Query for Location/Venue

[dshanske]

Brainstorming the proposed extension of querying for venues. The proposal https://indieweb.org/Micropub-brainstorming#Query_for_places uses q=geo=uri or :uri which seems confusing. I'd personally rather pass through individual parameters, lat, lon, u to query for.

q=geo&lat=10&lon=20 etc

Suggesting two return variables...

geo, indicating a default suggestion for the location and venues, indicating a series of possible venue suggestions. Not all sites would implement both. So, this would allow for simple location retrieval or a venue picker for check-ins to a url.

Return format for location would be name, lat, lon, optionally a full h-adr.

[dshanske]

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"} }

[dshanske]

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

[dshanske]

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.

[dshanske]

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", }, ] }

[swentel]

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.

[swentel]

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.

[swentel]

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

[dshanske]

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

Also, I prefer the individual parameters myself.

[swentel]

Ok, the Drupal module documents to return an array of 'places' now, see https://github.com/swentel/indieweb/issues/393

[swentel]

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.

[dshanske]

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.

[dshanske]

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.