Proposal: Relate hubs with physical locations

xiam commented 8 years ago

Hello @fergalwalsh, @pkieltyka -- I've been looking into geoy recently (nice work!) and considering that our ultimate goal is to relate hubs with locations to get benefit from local searches we well need to work on some plan, I propose the following:

Start associating hubs with places

Use the Google Places API to relate a hub with a place (as suggested here). Users will be able to start typing the name of a place and it will be autocompleted using whatever autocomplete SDK google offers. If the place if not there yet, users must have a way to type an address, or drop a pin into the map.

This map...

...must have an input where users can start typing the name of a place. Results will be influenced by the user's current geographic position.
..should have the ability to enter a full address if the place is not in the map.
...could have the ability to drop and relocate a pin anywhere in the map (Need to think this throughly, as it adds complexity and probably not much benefit).

When the user enters a place name or address, the map will relocate to the specified place and a pin will appear in the desired position. And we will have the following information:

Place name.
Place ID (A Google Places ID).
Full address.
Town, City, Country.
Latitude, Longitude.

We can save all that information to a new locations table and create a relation to a hub using a location_id field.

Looking up hubs near me

Using the Places API we can look up places around a point. We probably don't need elasticsearch at this moment as the Google places API already has a lot of filtering options that we won't have to implement.

We could, for instance, use the places API to lookup places using a radius https://developers.google.com/maps/documentation/javascript/examples/place-search to limit results.

We can then match all the returned Place IDs to places we already stored in our locations table, we can join that with the hubs table to have the hubs near a certain geographic point.

If no hubs are found, the UI can automatically suggest something like "We could not find hubs near you in 200m, try 1km" then jump to 10km, 100km and so on.

We can go back and implement local elasticsearch anytime in the future.

Looking up hubs near other hub or near a particular place name

For a hub, we can grab the latitude and longitude of a particular hub and then look up hubs near a certain radius, like described above.

For a place, we will have to look up the place using the places API to grab its coordinates and then search around that point.

Making location information discoverable

Using the location information that is linked to certain hubs, we can create a small JSON-LD snippet and add it to the hub's page source code.

SEO improvements

Redirect hubs that contain location information to URLs like:

https://pressly.com/goto -> 301 https://toronto.pressly.com/goto

or https://pressly.com/toronto/goto.

For city names that collide, we can do something like https://pressly.com/spain/guadalajara/golang and https://pressly.com/mexico/guadalajara/golang.

Use hub titles that reflect location, instead of "GoTo" we can use "GoTo in Toronto, Canada. - Pressly"
Include location in hub's page meta tags. meetup.com does something like this:

<meta name="keywords" content="Toronto,golang,group,club,event,community,local,networking,meet,sharing,Meetup" />
<meta name="description" content="Find Meetups in Toronto, Ontario about golang and meet people in your local community who share your interests." />

<meta name="ICBM" content="43.74,-79.36" />
<meta name="geo.position" content="43.74;-79.36" />
<meta name="geo.placename" content="Toronto, ON, ca" />
<meta name="geo.region" content="CA-ON" />

Provide a list of public hubs by location:

For instance https://pressly.com/cities/canada/ontario/toronto and https://pressly.com/cities/canada/ontario. See http://golang.meetup.com/cities/ca/on/toronto/ as example.

Explore similar sites that depend on geographical data, for instance, meetup.com also includes listings, like the lifestyle link here:

<a class="simple-category-option " href="http://www.meetup.com/cities/ca/on/toronto/lifestyle/" data-key="lifestyle" data-name="Lifestyle">

What do you think?

pkieltyka commented 8 years ago

this sounds great.

I'm not clear on how you would "find hubs near me" yet though..? I think we should be having a new field on the hub data model called the "geo_location" which is a point, "geo_place_name" as place string and "geo_place_id" which is based on Google Maps place id.. and we should search on our end according to this.

xiam commented 8 years ago

I was proposing to offload those fields to a different locations table, because we can end up with too many geo_* fields over time, we can relate one or more hubs to a particular location with a location_id. But yes, I'd save name, location and the Google Place ID (which is different than the location_id).

I don't think we really need to search in our end, we can use the places API for that as well, it can search places around a point and many other things.

We could implement looking up hubs near me like this:

Look places near point a,b using Places API.
Get the Google Place ID of each place.
Query for the Google Place ID we got in our locations table (we can do a JOIN query here, with the hubs table to get hubs near me).

Probably Elastic Search is a good idea for future optimizations, but for prototyping and see how this works sticking to Google Places API could be better for now, and it also provides more flexibility (in case we need to drop and idea and try another thing).

pkieltyka commented 8 years ago

the locations table / foreign key could work.. we can experiment here, it will just mean we'll be doing some join queries, thats not bad.

From a user's perspective, I'm picturing an "Explore" tab, and it always find the 10 closest hubs to you. If that means they are 2000km away, then it will return 2000km, but as more and more hubs appear, it will show hubs from just a few meters away. I find it interesting that the radius is dynamic, but you always get 10 closest hubs to anywhere in the world.

ie. consider a more basic dynamic which would be top closest hubs in a city. If we limited it to just a place, ie. like a neighbourhood it would show no results, but the next neightbourhood could have a hub.

xiam commented 8 years ago

From a user's perspective, I'm picturing an "Explore" tab, and it always find the 10 closest hubs to you. If that means they are 2000km away, then it will return 2000km, but as more and more hubs appear, it will show hubs from just a few meters away. I find it interesting that the radius is dynamic, but you always get 10 closest hubs to anywhere in the world.

Sounds good! I am sure we can do that with PostGIS.

pkieltyka commented 8 years ago

yea im sure we can. I think @fergalwalsh was playing around with this in elasticsearch.. perhaps that is a good place to do it so we can also search used words from certain places. Think of a "hub" as a type of place

fergalwalsh commented 8 years ago

@xiam To look up hubs near a certain location I think it makes most sense to use PostGIS rather than doing this with the maps api. You would use the maps api to geocode an address but then use the returned point to do a Postgres query. You can either use something like ORDER BY ST_DISTANCE(location, 'POINT(X Y)') LIMIT 10 to find the nearest 10 hubs up to any distance or .. WHERE ST_DWITHIN(location, 'POINT(X Y)', 5000) to find all hubs within 5km of some point. This is extremely fast and simple in PostGIS.

I did some experiments with elastic search (#1) but it's quite limited in the type of geo queries you can do so my recommendation would be PostGIS.

Aside from that your proposal looks good. As I mentioned in #2 I would strongly suggest using the Google Maps client libraries for the UI components for doing the address/location searches because they take care of a lot of the complexity for you.

fergalwalsh commented 8 years ago

One further note: Not sure how familiar you are with PostGIS but just in case: if you do store location geometries in Postgres make sure you are using the Geography type rather than Geometry. If you use Geometry with lat, lon data you get back wrong distance calculations.

pkieltyka commented 8 years ago

thanks @fergalwalsh for the insights!

xiam commented 8 years ago

Thanks @fergalwalsh and agreed on using PostGIS and official libraries.

pkieltyka commented 8 years ago

good plan.

goware / geotools