Open ckoppelman opened 10 years ago
@lonvia since the current bounding box applied to Alaska is next to useless (http://open.mapquestapi.com/nominatim/v1/search.php?format=json&addressdetails=0&limit=1&q=alaska) then is it not fair to assume that changing it to something more useful couldn't really hurt?
Maybe with west set as something like -184
as @ckoppelman suggests which would still have the west as a smaller number than east.
Are there no other bounding boxes in the Nominatim dataset already that cross the date line?
Are all others constrained within -180 and 180?
The bounding box for USA is similarly useless (http://open.mapquestapi.com/nominatim/v1/search.php?format=json&addressdetails=0&limit=1&q=United+States+of+America).
@lonvia I've just found the data that Flickr uses:
Alaska: https://www.flickr.com/places/info/2347560 USA: https://www.flickr.com/places/info/23424977
and those bounding box values stay on the correct side of -180.
Could similar values not be used for the OSM/Nominatim data?
@amnesia7 Those are similar to the values I used in my application, but they are invalid for many real use cases. Alaska is much longer than that and does cross the 180º line.
Would it not be at least an interim solution for the bounding box to go up to the date line even if not going past it so it's closer to being correct than the useless one in use at present? Would this also generate a better bounding box for usa as a result because that is possibly affected by the alaska bounding box as well?
@amnesia7 The problem with that is that islands in Alaska have their own bounding boxes, which must fall inside Alaska's (and the US's)
@ckoppelman I can understand that my suggestion wasn't for a complete resolution to the issue but just an interim to get it a bit closer to what it should be whilst more consideration goes on.
Hi, When trying USA nominatim query the bounding box returned spans for the whole globe, is there a workaround wherein a near perfect value of bounding box for such nodes which doesn't break the fitbound functionality can be hardcoded temporarily in DB itself ? Or the only way is to replace it in the response obtained ? Thanks.
I got the same kind of problem with New Zealand... New Zealand: ['-52.8213687', '-29.0303303', '-179.059153', '179.3643594']
When I request the bounding box for Alaska, United States (
place_id
="98124269"
,osm_id
="1116270"
), I get["51.0228691101074", "71.6048278808594", "-180", "180"]
, which, though certainly understandable (and understandable why), is pretty useless. I've had a manual hack to change it to["51.0228691101074", "71.6048278808594", "-129.9795", "-179.1506"]
(chopping off the Aleutian Islands), but I was wondering if there was a more systemic solution (like[...,"-129.9795", "-184"]
or something).