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: pinkduck[at]dsl.pipex.com [Submitted to the original trac issue database at 1.59pm, Friday, 14th August 2009]
The history page is next to useless at seeing what has changed in my area. It is frequently populated by (big) changesets from places such as Russia and Poland, when I'm looking at a 4km square region in a small English city, thousands of miles away.
It seems as though relations, or the bounds tags, of uploads are being used for hit testing. Relations should be excluded, as these are just aggregation of map data, mostly unchanged. Only changesets featuring edits that affect nodes in the viewport I'm looking at should be returned, nothing more.
Now I appreciate that performing hit testing on node lat/lng values to return an aggregated set of changesets might be rather slow. Perhaps rather than a single bounds including all changed content, the server/client could create one or more bounds regions for associated clusters of nodes? With backdated generation for previous changesets.
I note that JOSM has recently added an option to update edits as individual changesets rather than a group, but it would be best for the server/client to make such aggregation decisions optimally than relying on user knowledge and attentiveness.
Another intermediate possibility would be to add the option of excluding 'big' changesets from the history view, unless say the bounds of a changeset were fully encompased by the viewport.
The text was updated successfully, but these errors were encountered:
Reporter: pinkduck[at]dsl.pipex.com
[Submitted to the original trac issue database at 1.59pm, Friday, 14th August 2009]
The history page is next to useless at seeing what has changed in my area. It is frequently populated by (big) changesets from places such as Russia and Poland, when I'm looking at a 4km square region in a small English city, thousands of miles away.
It seems as though relations, or the bounds tags, of uploads are being used for hit testing. Relations should be excluded, as these are just aggregation of map data, mostly unchanged. Only changesets featuring edits that affect nodes in the viewport I'm looking at should be returned, nothing more.
Case in point:
Area: 0.9877,52.5247 to 1.5775,52.7331
http://www.openstreetmap.org/history?bbox=0.9877%2C52.5247%2C1.5775%2C52.7331
Returns first changeset match as: http://www.openstreetmap.org/browse/changeset/2141280
Not a single changed node in that can be found in my viewport area
Now I appreciate that performing hit testing on node lat/lng values to return an aggregated set of changesets might be rather slow. Perhaps rather than a single bounds including all changed content, the server/client could create one or more bounds regions for associated clusters of nodes? With backdated generation for previous changesets.
I note that JOSM has recently added an option to update edits as individual changesets rather than a group, but it would be best for the server/client to make such aggregation decisions optimally than relying on user knowledge and attentiveness.
Another intermediate possibility would be to add the option of excluding 'big' changesets from the history view, unless say the bounds of a changeset were fully encompased by the viewport.
The text was updated successfully, but these errors were encountered: