[PATCH] Imagery definitions refactor

[wiktorn]

Attached patch extends imagery definitions with:

• ability to define default layers for WMS_ENDPOINT and WMTS
• ability to set custom headers from GUI
• ability to set imagery as properly georeferenced

Apart from that, with this patch comes new WMS GetCapabilities parser based on SAX.

There are also easily separated fixes for CachedFile that I came across when developing this changes:

• cache validity check
• too long paths on Windows

The long vision is to move all (or all except some crippled imagery providers that do not provide GetCapabilities service) WMS imagery definitions to WMS_ENDPOINT type.

Features yet to be developed:

• add edit option in ImageryProvidersPanel which will open prefilled GUI as when adding
• add context menu in Layers window to change layer if we use WMS_ENDPOINT / WMTS
• imagery boundary generator from Nominatim / relation geomatry
• add "copy as maps entry" which would allow to easily add new entry in josm.openstreetmap.de/maps based on user imageries
• add "copy as string" which would allow easy share of entries within community

As this is bigger change that is hard to split, any testers are welcome.

For easier review - I've created pull request on my GitHub:
​https://github.com/wiktorn/josm/pull/1

You may comment there or here.

See: #15981, #7953, #16224, #15940

[stoecker]

The long vision is to move all (or all except some crippled imagery providers that do not provide GetCapabilities service) WMS imagery definitions to WMS_ENDPOINT type.

It would be very fine when these two are exchangeable, so we could do this, but I don't see that we really should do this...

ability to set custom headers from GUI
ability to set imagery as properly georeferenced

I hope these are expert settings?

add "copy as maps entry" which would allow to easily add new entry in josm.openstreetmap.de/maps based on user imageries

There also should be a more simple way to create boundaries. I still find it rather complex with the plugin. A nice solution would be to select a relation or way and say "My image boundary". It's then stripped to the geometry, checked for consistency, shown to verify and accepted. That would be fine 😊

add "copy as string" which would allow easy share of entries within community

With boundaries I think you can forget this 😏, without an URI like format would be a good idea, so it can be easily detected and parsed at different places (E.g. Drag and Drop on main window).

Question: Long code changes I did not really look at, but why do you change a regression test file?

[Don-vip]

I commented to the PR. Code is very clean, I didn't test it yet. I'd say we can give it a try once 18.04 is released. I made the remark only once but there are several public methods in different classes that must include a javadoc.

[wiktorn]

Replying to stoecker:

It would be very fine when these two are exchangeable, so we could do this, but I don't see that we really should do this...

I'm not sure that I understand what you have in mind here. We have wms and wms_endpoint for some time already. I do not plan to phase out support of wms type.

ability to set custom headers from GUI
ability to set imagery as properly georeferenced

I hope these are expert settings?

They are now. Added some commits to address this.

add "copy as maps entry" which would allow to easily add new entry in josm.openstreetmap.de/maps based on user imageries

There also should be a more simple way to create boundaries. I still find it rather complex with the plugin. A nice solution would be to select a relation or way and say "My image boundary". It's then stripped to the geometry, checked for consistency, shown to verify and accepted. That would be fine 😊

I guess we can use Nominatim to search for relation, fetch its geometry, and in the end - simplify geometry to reduce its size.

add "copy as string" which would allow easy share of entries within community

With boundaries I think you can forget this 😏, without an URI like format would be a good idea, so it can be easily detected and parsed at different places (E.g. Drag and Drop on main window).

Question: Long code changes I did not really look at, but why do you change a regression test file?

I moved regression file from one place to the other so folder structure is compatibile with MockServer. With this move I also converted line endings from DOS to UNIX.