I'm working on a geolocation based personal project where I'd like to fetch the suppliers based on the user's latitude & longitude value. And the deal is suppliers have variable supply radius, few suppliers supply only within 5km of their radius while some may supply across the entire city.
The general way to go about this is for each supplier calculate the distance between the supplier & the user. If it is less than or equal to it's supply radius then display that supplier in the results.
But this might be very slow, so I thought I'd split the city into four zones(pick four latitude & longitude values from google maps for North East West South) & whenever a supplier is added I'll do the math & assign the zones to which they can supply in the database. Now whenever I get the user's latitude & longitude I'd determine the zone & fetch suppliers that can supply to that zone, do the distance calculation & filter them out. This way I do the calculation on less number of suppliers instead of the entire list.
But is it a good idea or can I do better ?
In you are using Postgres/Postgis, you can make use of spatial indexes, and then use ST_DWithin(geom1, geom2, distance) type queries see ST_DWithin docs. The spatial index will partition the space for you, making this kind of query very efficient and avoid you having to come up with any spatial partitioning scheme of your own.
Another operator you can use is the <-> operator, which is very efficient with a spatial index and is used in the order by clause, to get the nearest y things to some point x, (k nearest neighbour search) see <-> operator docs. One caveat for this operator to work properly with the index, the point you are searching for, needs to be a constant, as it sounds like it would be in your case.
Related
I am currently using Firestore for my iOS app and I need to implement a scalable solution for my posts feed. I need to get posts within say 20 miles, order them by date, and limit the amount of posts fetched for pagination. Any and all database solutions would very much appreciated! Thank you!
As a low budget/time alternative to libraries, we have implemented storing the first few digits of lat/long coordinates as a document or collection name and then accessed data that way. The first decimal place gives resolution to around 10 miles or so (exact values for longitude change depending on what latitude you are at). So in your database you could have a collection or document named something like +33.6-112.0. This would mark a reference in Firestore to put all data within (33.8 N, 112.0 W). Be careful with how you round the exact location data before placing it in the respective document or collection.
Then you can retrieve all data at any location you want. This may not give you exactly 20 miles, but some client side sorting can handle that. Note you could make the reference go to any decimal place necessary to achieve the level of precision you are looking for to minimize data base calls (to save you money) and minimize impact on the user's cell data plan.
This is a rather simple solution with limitations, maybe for an MVP, and if not careful could pull way more data than anticipated.
Below is a chart showing the approximate physical distance between each decimal place at the equator. So for example, the distance between (33.3 N, 0 W) and (33.5 N, 0 W) would be about 14 miles.
Neither of those databases have native geospatial querying capabilities. You would have to use some sort of add-on library to help with that. Geofire and Geofirestore are popular for this.
I'd like to visualize a number of points on a map. Unfortunately, there is no consistent address associated with each one. I've used Google Fusion tables to get a rough read on where the points are, and am relatively satisfied with the approximate locations of most points (sometimes Google figures out where they're located based on a landmark, sometimes based on an intersection provided, sometimes by street address, etc.).
My goal, then, is to create a choropleth map of a city (NYC, in this case), showing the number of points located in each neighbourhood. Is it possible to do this by somehow counting the number of points that fall within each neighbourhood?
I suspect that if fusion tables give me a passable visual, I may be able to use google's geocoding service in the same manner to figure out the number of points in each area, and use this to then build a choropleth (not a heat map — I'm after some level of interaction, like tooltips over each neighbourhood).
Is there any way to do this, or am I way, way off?
Is there a dynamic hierarchical data source out there that I can use to identify a lat lng point into a neighborhood?
For instance, if I was in Manhattan, it would recognize that I'm in Chinatown, Manhattan, New York City in that order. And if I was in a less densely populated area it would just put me into a neighborhood that would span a larger area. It can be a bit fuzzy in this concept.
Ultimately I want to group people into their nearest neighobrhood given evenly sized neighborhood population.
I know that zip codes can roll up into a metro area, but I wonder if there is something that's more granular or more dynamic.
Google's geocoding API can give a variety of levels of detail about a location. It varies by region, country, and even at state/local levels but you should be able to get close to what you're looking for.
'City Block' definition: The area (often a rectangle) bounded by 4 intersecting streets:
http://gyazo.com/46e1e6f0bbe97db8dd7dd19b0f38d016
Is there a convenient way of working out the nearest CITY BLOCK to a long,lat location?
If so, is there a way of getting the long,lat for, say, the lower left and upper right points of the 'City Block'?
I have a preference for a solution in Open Street Maps.
The OverpassAPI has an around query that allows you to get specific objects (for example ways tagged as highway=residential) around a given position. You still have to determine if and which of those streets define a city block and calculate their intersections (there should be a node at every intersection) in order to get lan,lon of those intersections.
You may also ask this question at the OSM help site.
Guys i have a little problem, i tried to find some examples on GeoIP based system that expands searches based on nearest neighbor countries. For example the visitor is from UK and tries to find IPs from France, Spain, Belgium etc. not for example Brazil, Argentina, China. So how can i get nearest countries from a given country/IP and expand incrementing the distance?
Edit: I'm using the free Max-mind version, since i don't care about cities that much. And my project is C# based.
Well, the first step to reduce the problem is to use basic geography, and categorize the countries by continents.
From there you can make a list of distances of within a given continent, and sort based on those "distances" or "weights".
The geographic distance (e.g. km or miles) between capital cities should be a "good enough" approximation to get started if you want to be fancy. I bet you could even find such a list with a bit of searching on the Internet.
From there you have the "post-office problem" (Knuth) or "nearest neighbor search" optimization problem, and in this case I suspect you can [REWORDED] simply go with a linear search within the continents partitions. If you need better performance, then an approximate algorithm approach should suffice. (answers are not guaranteed to be best solution, but should be reasonable most of the time)
Note this form of geography based "routing" is weak in a few exceptional cases, such as Cuba, which does not get Internet access from its (naive) obvious geographic neighbor, USA, and some "black-hole" type countries due to political relations. North Korea and Tibet I suspect are similar cases.
Maxmind gives you the Lat/Long of each country, so you can just calculate the difference of your country to the others and you're done. See this thread for geolocation distance calculation or use a library of your choice.
But keep in mind the the geo location of a country is just a single point somewhere in this country and not the nearest point to you.