Query document types for closest location by latitude and longitude properties
I have setup a custom controller (route hijacking) from which I need to query a "Store" document type which has latitude and longitude properties. I need to return the closest store to the user's location (which I will also have latitude and longitude for).
All .NET examples I have found use Sql Server Geography data type. I'm not sure how to translate this to my Umbraco document type, and/or how I could get Umbraco to store a Geography location (and then subsequently query it).
In this case I need to find the nearest location, but I also need to find all locations by distance. I've asked that here (https://our.umbraco.org/forum/using-umbraco-and-getting-started/78876-store-locator-in-umbraco-7plus) but unfortunately haven't gotten a solution.
I'm hoping I can figure it out one step at a time, as I need to do both anyway...
I see your method, but I'm wondering at which point I would run into issues with performance. For example if there are hundreds of Stores, or thousands? Would that present a performance issue? My initial thoughts were that I was after a way to query for this directly from the database, which I assumed would be much faster or more performant.
Also in your method, what kind of storage should I be submitting to the cache? Would I create a new class to store this with an (int) Node ID and GeoCoordinate for the location, then push that into the cache?
You might run in to performance issue if you do the maths on all of them. SQL is probably quicker for 100s of calculations, but the simple approach I've taken in the past mitigates that. The simple approach being only running the maths on viable potential targets, which can be relatively easily concluded by the difference in the lat and long from your reference point, without considering the trigonomety. Essentially, you can do a first pass on all the points and throw out any that you can see the latitude or longitude is a significant different. You could be quite clever about what you consider close by finding the nearest 25% but a simpler option would just be to exclude anything which is more than 0.5 different to where you're searching from. If you're only querying a few dozen points then you'll get your results in milliseconds.
As for what you'd be putting in to that cache, I'd suggest a Dictionary<int, GeoCoordinate> where the key is your node id.
Query document types for closest location by latitude and longitude properties
I have setup a custom controller (route hijacking) from which I need to query a "Store" document type which has latitude and longitude properties. I need to return the closest store to the user's location (which I will also have latitude and longitude for).
All .NET examples I have found use Sql Server Geography data type. I'm not sure how to translate this to my Umbraco document type, and/or how I could get Umbraco to store a Geography location (and then subsequently query it).
In this case I need to find the nearest location, but I also need to find all locations by distance. I've asked that here (https://our.umbraco.org/forum/using-umbraco-and-getting-started/78876-store-locator-in-umbraco-7plus) but unfortunately haven't gotten a solution.
I'm hoping I can figure it out one step at a time, as I need to do both anyway...
Hi Matt,
A simple solution would be:
Does that help?
Thank you for the response David.
I see your method, but I'm wondering at which point I would run into issues with performance. For example if there are hundreds of Stores, or thousands? Would that present a performance issue? My initial thoughts were that I was after a way to query for this directly from the database, which I assumed would be much faster or more performant.
Also in your method, what kind of storage should I be submitting to the cache? Would I create a new class to store this with an (int) Node ID and GeoCoordinate for the location, then push that into the cache?
You might run in to performance issue if you do the maths on all of them. SQL is probably quicker for 100s of calculations, but the simple approach I've taken in the past mitigates that. The simple approach being only running the maths on viable potential targets, which can be relatively easily concluded by the difference in the lat and long from your reference point, without considering the trigonomety. Essentially, you can do a first pass on all the points and throw out any that you can see the latitude or longitude is a significant different. You could be quite clever about what you consider close by finding the nearest 25% but a simpler option would just be to exclude anything which is more than 0.5 different to where you're searching from. If you're only querying a few dozen points then you'll get your results in milliseconds.
As for what you'd be putting in to that cache, I'd suggest a
Dictionary<int, GeoCoordinate>where the key is your node id.is working on a reply...