Plugin Request: Easy tracing of areas from aerial images

[Bernhard Hiller <bhil@…>]

Hi there,
I’d like to suggest the development of a new plugin.

Purpose:
Easy tracing of areas from aerial images.

Simplified use case:
In JOSM, the user has selected some aerial images as background, that layer is visible. The user sees an area which he wants to trace. He clicks somewhere in it, the active plugin automatically draws the boundary of that area. It adds the last user defined tag(s) to the way, and also automatically the appropriate source tag. Then the user clicks into another area to be traced. The node originally generated by JOSM is removed.

Examples of areas to be traced in such manner:
Lakes, fish ponds, buildings.

Further points to consider:
Installation and configuration:
For a wide-spread use of the plugin, its installation must be simple, and its configuration must be typically automatic.

Interaction with the WMS plugin:
It must be able to automatically detect the type of aerial images. With the WMS plugin being used for showing the images, some communication with the WMS plugin is required.
It is appropriate for the plugin NOT to get the images directly from their original location, but to use the cached data of the WMS plugin. Do not forget users with low internet bandwidth.

Activation/Deactivation:
Since the left mouse click is normally used for adding a node in JOSM, an easy switch between the "normal" mode and this plugin mode is required. This could be achieved with an icon in the toolbar of JOSM, showing the present state of the plugin, and changing it when clicking on it.
A short cut key combination may be additionally provided, but when tracing the mouse is the appropriate tool in the user’s hand.

Tags for the automatically traced way:
The user can configure one (optionally: several) tags to be automatically added to the way which has been traced automatically. Examples: "building=yes", "natural=water". A menu or toolbar icon must be provided to reach this configuration.
The configured tag is used upto the next configuration change.
A source tag is always provided, e.g. "source=Bing"

No fully automatic tracing:
This plugin expects a semi-automated way of work. A human user is a master of seeing objects from images, far better than any present software. And he is capable of seeing that two fish ponds next to each other are both fish ponds even when one of them is bluish while the other grew green with algae. Red or blue roofs of houses can be distinguished from the area around, and the human user recognizes both of them as the roofs of buildings.

Some hints to the programmers:
We should expect the user to click somewhere into the object he wants get traced, a few pixels away from its boundary. The object has a color different from its surroundings, and though the color is not exactly the same for each pixel of the object, it is quite similar. It should be a good guess to assume that the object can be traced with the color shades identified within those few pixels around the point of the mouse click.
In case the object to be traced extends beyond the visible area of the screen (e.g. estuary mouth of a river), the object is assumed to end where the visible area ends.
Rather than extending an object into infiniteness, return early a failure message.
Expect the zoom level of the image to be adequate, it is not necessary (or even not adequate) to load images at a higher zoom level. If for some reason the plugin thinks that a different zoom would be better, it should show such a message to the user.

[akks]

At first we need function in core to get bitmap fragment from screen/cache (in Imagery part?) Now there are only functions in WMSLayer and TMSLayer for getting single tiles. Joining, shifting - all should be coded...

This should be the base for all possible raster-based plugins (now LakeWalker and ext_tools+scanaerial are downloading tiles themself).
It is really needed, but should be implemented in connection with existing and planned TMS/WMS features - any realisation will be temporal (and ugly) if the authors themself will not participate.

And this is only the first step... So there is really a LOT of work.
I thought about it (like many other people, I think), but have no time (not least than full working week or two) to implement it.

Maybe there is someone who can start this great and honorable work?

[stoecker]

You know lakewalker plugin?

[akks]

Replying to stoecker:

You know lakewalker plugin?

As for me, lakewalker was great for that historic period) It has rather good code base.

Lakewalker is hardcoded to use Landsat server that seems not to work. It also uses 'water'-specific tags. Now it needs at least following modifications (as it seems to me):

1) Server configuration - ideally, using main WMS/TMS layers (we need only getTile and getPixel that exist in TMSLayer/WMSLayer in other form).
Specific WMS like Ladnsat IR1-IR3 can also retain.

2) Tags specification - not only water mode.

3) Some algorithm changes to work with high-res imagery (IRS alowed in Russia, BING) (some configurable averaging/edge decection to recognize forests/so on).

At first we need (1), of course. It needs good understanding of TMS/WMS core part (and maybe even some changes in it to unite TMS and WMS), so
your help is essential.

(2) and (3) can be improved step-by-step by not so experienced developers (like me).

LakeWalker20 can become very popular (or too popular, I afraid :) ).

[Bernhard Hiller <bhil@…>]

Replying to stoecker:

You know lakewalker plugin?

Apart from the points mentioned by akks in reply to your suggestion, it is also the style of inter-active semi-automated tracing which is an important difference. After some initial configuration, LakeWalker starts doing everything automatically, and then the user can edit the finds.

But for LakeWalker, things are predefined by their color. If it worked with high-resolution images, LakeWalker would mix up blue lakes, riverbanks, swimming pools, fish ponds, blue roofs, etc. That's why I suggested a different type of process: the human user can spot a blue/red/grey/etc. roof, and define that there's a building. He clicks into it, and then the new plugin does the rest for him. And the next item of the same type does not need to have the same color.

This difference between my suggested work flow and the implemeted work flow holds also true for Fuzzer (I guess so from its description), and Fuzzer is far too complicated to install and configure for a "common" user.

But of course: thanks for your suggestion!

[anonymous]

Replying to akks:

The last time I programmed a simple application in Java is some 10 years ago, nowadays I use .NET and mainly C#. With the many code changes in the plugins required, that does not look like a good chance for me to get into Java programming again...

A few thoughts on the implementation:

The tiles are presently cached in a temporary folder (on my German XP, it is "C:\Dokumente und Einstellungen\Bernie\Lokale Einstellungen\Temp\JMapViewerTiles_Bernie"), with subfolders for each type (e.g. "Bing Aerial Maps"). I haven't yet looked at the naming convention of the tiles, the folder does not properly open up in Windows explorer with more than half a million (!) files in it... By the way, would be nice if I could configure a different location for that cache.

The main window of JOSM shows the position, and it knows the zoom for osm (e.g. "​http://www.openstreetmap.org/?lat=7.7013&lon=99.2257&zoom=12" in the Jump-to-position-dialog). With those values, the tile number can be calculated, and then be retrieved from the cache folder. Otherwise, just calculate the present position for some zoom levels, and take the tile at maximum zoom level available.
And calculating the pixel-position inside a tile is also not so complicated.
True, tile sizes differ between Bing and Landsat, which means more duplicated code.

Of course, that would be a single tile only. But JOSM knows the lat-lon-values of the bottom left and top right corners of the visible area also, doesn't it? That would allow for the remaining tiles to be retrieved from the cache (ok, that might be a little larger than the visible area due to clipping).

The items traced would consist of ways with nodes having lat-lon-values, not pixel-values. Hence I do not expect a further calculation in the plugin to be required.

True, this is an ugly suggestion. If the WMS plugin changes the cache folder, it won't work any more.