[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
• minimum time for which imagery tiles can be cached (workaround misconfigured tile servers which set short expiry dates, such as aerial imageries that we could keep in cache for months)

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.

[wiktorn]

Replying to Don-vip:

I commented to the PR. Code is very clean, I didn't test it yet.

Please do. I fear that I might have missed some corner cases.

I'd say we can give it a try once 18.04 is released.

Sounds like a plan.

I made the remark only once but there are several public methods in different classes that must include a javadoc.

I've just updated branch with commits with javadocs and other fixes.