Location correction-suggester

[PhantomWatson]

I suggest this, to help reduce the rate of users entering variations on the names of locations (despite the location name field providing automatic suggestions) and administrators needing to manually correct for that:

Location correction-suggester:

• Triggered when the location name field's value is changed and is nonempty
• Displays a limited number of suggestions, ordered by similarity, if
  • The location name is not found in the database (or rather, in the JS variable eventForm.previousLocations)
  • One or more similar location names are found (according to some threshold)
• Allows the user to dismiss the suggestion(s) or click on one to change the value of the location name field

[ericadestoya]

Or just a straight-up location suggester.

I've been ~writing~ (edited: riding) the bus a lot lately.

When you go to the MITS trip planner, it has the official names of buildings & buildings as listed by Google as suggested locations when you begin entering the names of locations. ^ Like that. But, OK, let's say we can't or don't want something like this where it's Google-powered, we could take the time to create a separate locations table with slugs, addresses, etc. there for the auto-populating.

[PhantomWatson]

The current version of the site already auto-suggests locations when you start typing, but based on all of the location names that are already in the database (so it doesn't help with any new locations). The theory is that if it's at a location that's familiar to the site, people would be more likely to accept the suggestion instead of typing in a variation. And if it's the first event that's ever been posted for a particular location, then there's no canonical location name to favor and we might as well let them enter whatever they want.

The current location auto-suggestion thing also automatically populates the address field, I think with the address for the most recently-posted approved event with the same location name.

I think there's still room for a pros and cons debate about using Google for this, though.

[ericadestoya]

So, here's a thing we can do: locations becomes its very own table, not just a field. So the table would look something like this: id, name, address, neighborhood. This would open the door for us to map the events, and to sort locations & events by neighborhood. I quite favor this idea. It also means we can input location names for places around BSU campus, etc. and it will (HOPEFULLY) prevent users from inputting superfluous locations. For now the 3.x version is an improvement but I'd like to work towards this.

[PhantomWatson]

• Are there any possible situations where there could be more than one address with the same location name? (like a business that anticipates moving to a new location in the future)
• Who inputs neighborhood?

[ericadestoya]

• Yes, that's actually a really good point... lots of businesses have changed locations even since I came to Muncie. So that will need to be dealt with.
• I just assumed I would but that does sound like a lot of work *shrug*

[PhantomWatson]

Ideally, we automate anything that can be automated. On account of duh.

A cursory search suggests that the Google Maps API might provide neighborhood data for whatever coordinates you feed it, and that there are other APIs that definitely do. So we'd probably be able to work up a solution that automatically populates a neighborhood field, but only if address is resolvable. Using the Google Maps API to provide suggestions in the address field might help steer people away from "UMM IT'S ACROSS THE STREET FROM THE MORMON ZOO OVER IN THE SCRUBLANDS".

[ericadestoya]

THE MORMON ZOO OVER IN THE SCRUBLANDS

what are you trying to say about my scrublands???

But no for real, OK, the Maps API sounds good.