The thing is that you want longitute and latitudes that might be bigger or smaller than the number you are querying.
So it might need a few queries.
For instance if I knew I wanted numbers larger than lat and long, then I would have that in the where clause where lat > ? and long > ?
Then I would sort it by lat then long, like ORDER BY lat, long
I would also limit the number of records to 1 or 5, because the first record should be the closest to lat and long but where both are over the lat long given.
So this is where multiple queries come into play, using the combination of > and less than signs for lat and long, always sorting accordingly including asc and descending. In each query take the top record. Then at the end you might have to compare those final records and calculate which is actually closer.
You probably won't want to be doing trigonometry in your query, but given the data you're working with it would be okay to assume the earth is flat (or at least locally flat). And likewise, latitude degrees all have the same length everywhere but longitude degrees have a length which varies depending on the local latitude. (That's the trigonometry part.) But I think you can ignore that as in practice you aren't going to be comparing longitude degrees which are far apart in latitude.
Hopefully you have your data in decimal degrees, rather than in degrees, minutes, and seconds.
Then I think what you want to minimize is (ZipLatitude - InputLatitude) ^2 + (ZipLongitude - InputLongitude)^2. So you would write a query which ordered by that quantity and selected the first few rows of the result. Now, that number isn't the actual distance, it's just a surrogate for that. But once you have used it to identify the closest points from the database, you can then unleash the trigonometry to calculate the actual distance for the few points you actually choose.
This is a query I've addressed once or twice already.
While absolute distance on a sphere requires trig calculations, most of the interesting parts of the planet are in a zone where you can fake it reasonably well by using a "rectangular" frame. That is, between 2 limits of latitude and 2 limits of longitude, and that's a pair of simple "between" tests. You can use that as the coarse filter, and in many cases that's sufficient, or you can get by with doing the trig work on the filtered set using server logic.
For somewhat greater accuracy, you can assume a trapezoid instead of a rectangle, and that will complicate the query expression only slightly.
Of course, if you're locating polar bears, all bets are off.
Customer surveys are for companies who didn't pay proper attention to begin with.
Most of the time, it gives you the record you need. When your input location is close to halfway between the two nearest ZIP locations, the approximation may cause you to choose a ZIP location which isn't quite the closest.
This might well not matter -- the centre of a ZIP code is a rather arbitrary choice anyway -- but if it does then you should select the first few records and recalculate the exact distance for each of them in your Java code. You should be able to track down that formula on the web.
HQL based on a Java object called Location and another called CloseZip
Notice CloseZip is not mapped, it doesn't need to be
HQL
SELECT new CloseZip(location.zipCode, sqrt( square(:latitudeValue - location.latitude) + square(:longitudeValue - location.longitude)) AS distance)
FROM Location location
ORDER BY distance
I think you will have to concatenate the :latitudeValue and :longitudeValue in the Select part, I haven't tried putting bind named parameters in a Select portion. Maybe Hibernate will fill in those values.
0
