You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: Ed Avis [Submitted to the original trac issue database at 7.41pm, Friday, 30th October 2009]
Currently to fetch data with /api/map you specify a bounding box with two longitudes and two latitudes. It would be easier for some uses to give a centre point plus the width and height in metres of the area to be fetched, e.g.
Of course clients can calculate these for themselves, to reasonable accuracy, using a couple of constants and a cosine. So this wouldn't make the API any more powerful, just a bit more convenient for some uses.
Further, it would be useful to fetch the same map area as a particular slippy map display, as
This would compute the width and height based on the zoom level, location, and screen size given.
Again, clients can compute this with a few lines of code provided they have a lookup of what
the zoom factors are, but it would be a useful builtin. If screen_width and screen_height are
omitted, some default such as 800x600 could be assumed.
The text was updated successfully, but these errors were encountered:
Author: tom[at]compton.nu [Added to the original trac issue at 1.05pm, Sunday, 1st November 2009]
Can you elaborate on what sort of uses this would help with?
Incidentally, screen_width and screen_height are clearly the wrong names unless you're going to tell us what percentage of the width and height of the screen are being used to display the map. It would be better just to name them width and height (or map_width and map_height or something).
Of course strictly speaking you would also need to tell us what projection you're using ;-)
Author: Ed Avis [Added to the original trac issue at 3.08pm, Sunday, 1st November 2009]
I was thinking of when you want to quickly use the API to look at the XML for a particular map area. The slippy map interface uses (lat, lon, zoom) rather than a bounding box and this triple is sometimes used as a kind of OSM bookmark - e.g. in Merkaartor you can paste in a link to the slippy map to choose the area to download. Merkaartor has its own code to turn that into a bbox.
As for the pixel width and height, perhaps viewport_width and viewport_height would be better names.
Author: tom[at]compton.nu [Added to the original trac issue at 3.44pm, Sunday, 1st November 2009]
So you don't actually have a concrete use for this? It just seemed like a good idea so you thought you ask somebody to spend time implementing it in case somebody later decided they would like to use it...
Author: Ed Avis [Added to the original trac issue at 4.15pm, Sunday, 1st November 2009]
Yes, this is just a feature request. The concrete use is as I mentioned, and is something I wrote code for, but thought it might make sense to have implemented in the API instead.
Author: mmd [Added to the original trac issue at 5.55pm, Tuesday, 19th May 2020]
This has never been requested again in the last 9 years. Closing because requirement is too niche.
If you're looking for objects around a center point with a given radius, you can use Overpass API around: filter instead.
Reporter: Ed Avis
[Submitted to the original trac issue database at 7.41pm, Friday, 30th October 2009]
Currently to fetch data with /api/map you specify a bounding box with two longitudes and two latitudes. It would be easier for some uses to give a centre point plus the width and height in metres of the area to be fetched, e.g.
This would calculate the bounding box for you and return the same results as
Of course clients can calculate these for themselves, to reasonable accuracy, using a couple of constants and a cosine. So this wouldn't make the API any more powerful, just a bit more convenient for some uses.
Further, it would be useful to fetch the same map area as a particular slippy map display, as
This would compute the width and height based on the zoom level, location, and screen size given.
Again, clients can compute this with a few lines of code provided they have a lookup of what
the zoom factors are, but it would be a useful builtin. If screen_width and screen_height are
omitted, some default such as 800x600 could be assumed.
The text was updated successfully, but these errors were encountered: