History page approximates bbox parameter

[1ec5]

I have a bookmark for the changeset history of the area I watch. It uses the bbox parameter to specify an area that is rather vertical, covering a good chunk of western Ohio and part of northern Kentucky. Support for the bbox parameter was restored in d95361b, but now the bbox -85.3,38.65,-83.3,40.4 appears to be approximated as 8/39.531/-84.300. (There is no redirect; the results just happen to reflect that viewport.) So now the same bookmark pulls in changes from Louisville, Columbus, Indianapolis, and other cities well outside my area of interest.

To be clear, I’m not talking about worldwide changesets that happen to intersect with the bbox. I’m talking about changes like 19326040 that do not intersect at all.

The history page should return results for exactly the bbox that was passed into it. If that would add too much complexity, there should at least be some way of getting the history for an arbitrary area. Not everyone is interested in an area with the same aspect ratio as their computer screen. :-)

[tomhughes]

I'm not sure this is really fixable, because the history view now updates to show the changesets in the current view as you move the map, so it can't only show part of the view, and if your requested bbox has a different aspect ratio to the browser window there will always be a difference.

The RSS feed is probably more useful for monitoring changes anyway, and that will return data only for the requested bounding box.

[seav]

An alternative to the RSS feed is to append "&list=1" to your bookmark. That shows a plain list (without a map unfortunately) of only the changesets that intersect your bbox.

[tomhughes]

Please be aware that using the list=1 parameter is making use of an internal implementation detail which we do not guarantee will continue to exist in the future. This should not be documented in the wiki or otherwise promoted.

[seav]

we do not guarantee will continue to exist in the future

@tomhughes, basically, like every other URL on the OSM website that is not part of the official OSM API. I'm quite sure that removing the "browse/" part of the URLs in the redesign would have broken some tools that are not equipped to handle HTTP redirects.

So, OK, I agree that we should not promote undocumented URLs but people should be free to use them if they find it useful with the caveat that there are no guarantees.

[tomhughes]

No, not like every other URL at all. The particular parameter you are talking about exists purely so that the server can tell whether the page load is an XHR call being made to load the sidebar, or an attempt to load the full page and as such is an implementation detail.

Obviously checking your facts would destroy your argument, but since you couldn't be bothered perhaps I can help by enlightening you as to the situation regarding the /browse prefix:

bericote [~] % lwp-request -PSd http://www.openstreetmap.org/browse/way/9999999 
GET http://www.openstreetmap.org/browse/way/9999999
301 Moved Permanently
GET http://www.openstreetmap.org/way/9999999
200 OK

So as you can see, we made sure to redirect those URLs to the new location.

[seav]

@tomhughes, I did mention about HTTP redirects, if you had bothered to comprehend my comment.

And it was exactly by investigating the XHR call that I discovered the list=1 parameter. I noticed that you can load the list of changesets by itself with list=1, otherwise it would be interpreted as a full page view.

There's no reliable way to instruct the web server that you wanted a list fragment or a full-page-with-map when viewing some list of changesets because HTTP is stateless, so you needed to have different URLs and that's why the list=1 parameter was added. While the list=1 parameter is not guaranteed, I'm quite sure that you would always need a different URL to make that distinction and this different URL is always discoverable by examining the JavaScript.

[tomhughes]

So your point about /browse is that we should assume that clients making HTTP requests are not in fact valid implementations of the HTTP specification? That way lies complete madness I feel...

As to list= my point is simply that I don't want in a year or two from now to be having the box= argument that we're having on trac right now because people have been encouraged to use an unsupported implementation detail and we have made a change which either makes it no longer available.