Search By City/State

[jasonkalmeida]

This might be something we want to tackle a little further down the line, but it is an obvious feature enhancement that we should implement.

[joegoldbeck]

This would require calling out to a backend or another API right?

Looks like the mobilize event api only has zip code as an option

[jlev]

Would also be great to enable the browser location api, so people on mobile won't have to type anything. I've done something like this for StoriesOfSolidarity.org, using the OSM Nominatim reverse geocode API to go from lat/lon to city/state (https://github.com/storiesofsolidarity/website-frontend/blob/master/app/scripts/views/storyPost.js#L118)

[Hucxley]

Actually, @joegoldbeck the mobilize event API has the lat/long in location.location object (which I learned about when searching the site for events while texting people (it wants to ALWAYS return the lat/long in the query URL after you submit search). Ref:

"location": { "venue": "", "address_lines": [ "204 E 13th St", "" ] "locality": "", "region": "", "postal_code": "10003", "location": { "latitude": 40.7322535, "longitude": -73.9874105 },

[joegoldbeck]

Right, but you can’t pass in lat/lon, so to search by city/state we first need to do a lookup elsewhere from city/state -> zip

[jlev]

Basic implementation of geolocation on demand, using Nominatim to look up zip from lat/lon (limiting accuracy to 3 decimal places for user privacy).

UX could be improved by showing spinner or progress indicator, as the location API takes a few seconds to return.

[Hucxley]

@joegoldbeck I was looking at this again...

IF we're getting a user's geolocation, wouldn't we pull all (public) events for an organization, presumably on a regular basis, let's say hourly, store all of the events using the event ID as the key for the record and the location.location data. After getting the user's location, quickly loop through each event, and if the INT value of the lat === INT user's lat, then look if INT of long === INT user's long, and if both === true, push the event ids to an array of "possible" events to drill down closer to the user.

The other option is to fetch all events on a regular schedule and store the event IDs into arrays organized by INT values for lats and longs (creating and absolute maximum 52 Lat arrays and 113 Long arrays, though practically much smaller since there certainly won't be an active event in every lat and long of US territory), with eventIDs pushed into the lat and long arrays that match the INT values of the lat and long of the event location. (for example, any events in Chattanooga would have their eventIDs in the lat: {35: [$eventIDs]} and long: {85: [$eventIDs]} entries in storage)

Then, it would seem rather quick to check user's INT value of lat and long against the stored events:
if(docStore.lat.$intUserLat && docStore.long.$intUserLong) => return events that appear in both arrays
Go back to our event storage dic, and pull the event details that match the events from the step above, and drill down to the locations.

Maybe this is over-engineered. I don't know, I haven't written or tested any code for it, but I don't think we want to ping the mobilize API every time a user comes to our event map, especially in about 7 or 8 months from now. Instead, we'd probably be better served to update our stored events on a regular basis and query against our own storage instead.

[joegoldbeck]

@Hucxley I think you’re right that at some point we may want to add caching (you can just use a LRU cache, you don’t need to proactively fetch things. Happen to explain further in a PM), but as you suggest, that’s an optimization for later, in the case that we get to scale.

That doesn’t have especially bearing on this ticket though. The issue here is that we need to do a lookup on city/state in order to find the zip code to pass in. We could definitely cache that, as well, once we implemented it, if warranted based on rate-limits/cost (I’d file premature caching under over-engineering 😄)

But we’d need to implement it first 😅

[joegoldbeck]

Speaking of which: @jlev, could we use nominatim to power a city/state -> zipcode lookup? (Assuming you haven’t already done that)

[Hucxley]

@joegoldbeck I guess I'm disconnecting in why we'd need to look up a zip code from the user's geolocation to pass to a query if we have a list of events (which contain the location.location data as well as other event details) AND the user's geolocation. If we want to limit a return of results within a radius of the user, that can still be done with event.location.location and the user's geolocation.

I guess I'm looking at it from a user who is looking for something near them and automatically returning upcoming nearby events. I recognize there's also another use case of looking up events FOR someone else, for which the zip code + distance query would be preferred intent. But, those are separate user stories that don't have a lot of overlap.

Am I missing something super obvious here? I'm on Slack if you want to send me a PM over there.

[joegoldbeck]

Oh I see what you’re getting at. I think the only obvious thing you’re missing is that this ticket is *originally* about resolving City/State queries 😄. As in, say I want to type in Cambridge, MA, on my desktop, instead of 02139. So that’s what my comments have been about, primarily.

[joegoldbeck]

I believe the lat/lon lookup you're asking about has already been solved via a7f6df0 , so the geolocation api integration is 👌

You're definitely right that we could find a way to cache some of this intelligently (I think you have some good ideas there!), and almost certainly should at scale, but that's a later concern imo. We've gotta get this MVP out the door :). If we have the good problem of hitting scale (or the likelihood of being advertised in such a way that we expect to hit scale) we can deal with that then.

A maxim I tend to go by in software engineering (though occasionally to my detriment, admittedly) is "The future is uncertain and you will never know less than you know right now (<--- strongly recommend POODR which is the book this is from)

[Hucxley]

As in, say I want to type in Cambridge, MA, on my desktop, instead of 02139.

@joegoldbeck That's the part I was missing. I thought the point was to be able to determine city/state by using geolocation, then lookup the zip code for that and pass it through to the query for events automatically. I may have aggregated some stuff from Slack/Tech Talk/Idea Board and read more into this issue that was intended. :headbonk