[PATCH needs rework] New download selector: area around given node

[brycenesbitt]

I submit this new feature for consideration:

A new input method for the "Download from OSM" dialog box. Given an OSM element ID number,
it finds the center point and loads small additional area on each side.
Very handy if you've found a problem element in an XML or database dump.

This is similar to the existing "load areas around places" input method.

[brycenesbitt]

Patch: new download option "area around given node ID"

[bastiK]

Can you add a normal patch?

[brycenesbitt]

Patch: new download option "area around given node ID"

[bastiK]

This is some kind of shortcut, right? We already have File > Download object, so you could download the node in question and the download dialog would then change to the current view in the main window.

The single text field in the centre of the new tab looks kind of lonely, if you know what I mean. Maybe there are similar features, that could be combined? E.g. if you download a changeset, the API returns bounds in the xml.

[brycenesbitt]

Yes: if this tab is added it makes sense to expand it:
Way/Node/Changeset/Relation.
Plus a control for the radius (e.g. "300 meters") of the download area.

I must admit, for a long time I never even noticed the "File->Download object..." menu item.
Thus it seemed to make sense to have download "by ID number" in the same Download dialog as everything else.

[stoecker]

Can't you simply add it to the "Coordinates" download like:

Get "xxx" meters around "way/node/relation" with id "yyy".

The three fields allow to choose the settings then and a click to "Get area" gets the necessary information and the fills the coordinate values of the dialog?

[brycenesbitt]

Expanded version. Still needs work: turns out to be tricker than anticipated. Ways returned from the OSM API 0.6 don't include a bounding box. One apparently needs to load every single node and calculate the extents. It may make this entire proposed feature unworkable.

[bastiK]

Better use the existing infrastructure, e.g. OsmServerObjectReader and so on. Have a look at DownloadPrimitiveAction, especially how it looked before the recent changes. It is generally a bad idea to do network IO in event dispatch thread, because the GUI may freeze, when the connection is slow.

[brycenesbitt]

I'm thinking it is best to abandon this patch.

Maybe DownloadPrimitiveAction could move into the Download Dialog... but
it really does something quite different (e.g. load an object, where
the Download Dialog in the end defines a square region).

[bastiK]

I think it is unlikely that anyone else will continue the patch, so you can close the ticket. IMHO, the idea is not all bad, but sometimes the implementation is more complicated than you expect...