Open xiam opened 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.
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:
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).
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.
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.
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
@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.
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.
thanks @fergalwalsh for the insights!
Thanks @fergalwalsh and agreed on using PostGIS and official libraries.
good plan.
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...
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:
We can save all that information to a new
locations
table and create a relation to a hub using alocation_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
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.
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.
What do you think?