3

I need to calculate a bounding box for osm query. I get coordinates of center of the area (WGS84) and radius (meters). How can I do it?

I though about using some kind of projection, calculating projected box coordinates and then convert it back. Is it good idea? If so, which projection will suit the best to this task? I've read that miller's projection is a poor idea and it's better to use state plane projection. But on the other hand in my case bounding box doesn't need to be accurate. The most important for me is to calculate those coordinates quickly.

I would be grateful if you could show me some code example that do conversions essential for calculating bounding box.

I wanted to make this works on whole planet, but if there are better approximations I can assume that it should work in eastern Europe Latitude: 48.342 - 55.279 Longitude: 13.645 - 25.071

|improve this question
  • Can you expand your question to include anything that can constrain the problem? In particular, what the areas are (e.g. is it always within a particular lat/long range - "somewhere in the USA"), and the min and max values for the range. The key to fast approximations is appropriate assumptions, but we can't make reasonable assumptions without detail. – BradHards Dec 18 '13 at 8:35
5

(My original answer forgot about your position and radius being in different units!)

Assuming accuracy is unimportant, then if your centre is (X, Y) and your radius is R, the bounding box corners are simply (X-R, Y-R) and (X+R, Y+R).

Considering the different units:

Assuming accuracy is unimportant, then if

  • your centre is (X, Y), where Y is latitude, X is longitude, in degrees
  • your original search radius is r, and
  • the earth radius is R, in the same units as r

Then the bounding box corners are simply (X - dX, Y - dY) and (X + dX, Y + dY) where

dY = 360 * r / R, the "search radius", as difference in latitude,

dX = dY * cos (rad (Y)), the "search radius", as difference in longitude.

|improve this answer
  • 1
    (Assuming that the units of X,Y and R are the same) – BradHards Dec 18 '13 at 0:43
  • 1
    The change in units is what I was asking for. I get WGS84 coordinates and radius in meters, so I can't calculate its like you mention. – Wojciech Reszelewski Dec 18 '13 at 8:31
  • @WojciechReszelewski Somehow i didn't notice your very first statement! My answer is now edited for lat-long coords and linear search radius -- a little more involved :-) – Martin F Dec 18 '13 at 18:54
  • Just made another correction! X-Y were labelled wrong way around, sorry. – Martin F Dec 20 '13 at 3:09
  • I made a simple program that implements this algorithm in go. Review appreciated. gist.github.com/rynop/1f695feb343d7113ed16c82893fac1d9 – rynop Jul 16 at 20:00
1

If you do wish to do a lot of accurate and fast planar cogo (coordinate geometry) calculations, then transforming your geographic coordinates (you have WGS84 coordinates) using a conformal map projection first would be a good idea.

As you say, Miller's projection is poor (it is not conformal) and "state plane" projections (they are conformal) are good candidates. However, "state plane" is really just an American term for the accepted standard conformal projection for a particular US state. So, it's better to think about any appropriate conformal projection -- the most common being UTM -- for your area of interest.

And remember a universal truth about projections: the further away one gets from the "central" point or line for that projection, the greater is the geometric distortion.

|improve this answer
  • Could you elaborate on why you recommend conformal projections for this kind of work? (In principle, the projection to minimize the errors in these distance calculations will always be non-conformal.) – whuber♦ Aug 22 '14 at 14:43
  • @whuber: I was commenting on general planar cogo calcs. I think surveyors use conformal projections due to their properties of always preserving angles and, while distance is distorted, its distortion at any given point is the same in all directions. I don't know of any formal explanation as to why those properties suit cogo, but it does seem intuitive -- cogo involving angles and distances. Could be an interesting, separate question! – Martin F Aug 23 '14 at 3:14
  • @whuber: The problem with distance-preserving projections is that they only work (preserve scale) in one direction, such as N-S in a cylindrical equidistance projection, or, in all directions but from only one point, such as in an azimuthal equidistance projection. – Martin F Aug 23 '14 at 3:20
0

Having radius in kilometers and given that in one latitude degree there is always 111.11 km, one may use following:

dY = r / 111.11;
dX = dY / cos(rad(Y));

I would think that this should be the same as in Martin's answer, but apparently 1/(360/R) == 17.6972 (for kilometers) so it looks wrong. I was using the suggested formula for years without any issues.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.