[Patch] wms imagery should probe for WMS Version or allow to set it

[flohoff]

The WMS URL:

​https://geoportal.kreis-guetersloh.de/WMS/ALKIS_Basis_public/guest?

only allows requests with VERSION=1.3 - All Requests with VERSION=1.1.1 fail with some error.

The Workaround is to extend the url with a VERSION=1.3 ->
​https://geoportal.kreis-guetersloh.de/WMS/ALKIS_Basis_public/guest?VERSION=1.3

JOSM then extends the URL further with its own VERSION:
​https://geoportal.kreis-guetersloh.de/WMS/ALKIS_Basis_public/guest?VERSION=1.3&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetCapabilities

Interestingly it works - it seems the WMS Server does not parse the full url but only
up the first VERSION identifier. Still i'd expect other WMS Server to fail.

Please -

a) Either probe for the Version e.g. trying the getcapabilities with 1.1.1 and 1.3 if Version 1.1.1 fails,
this is what qgis does, or

b) let the user choose the version with a Kind of drop down, or

c) dont append another VERSION= parameter if the user already added a VERSION to the baseurl.

I'd suggest a) and c) - So if the user supplies a VERSION use it. It he/she/it doesnt probe for
a VERSION.

Flo

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-07-06 22:51:51 +0200 (Wed, 06 Jul 2016)
Build-Date:2016-07-07 01:34:43
Revision:10520
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10520 en) Linux Debian GNU/Linux 8.5 (jessie)
Memory Usage: 535 MB / 1820 MB (382 MB allocated, but free)
Java version: 1.8.0_92-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Dataset consistency test: No problems found

Plugins:
- Mapillary (32396)
- Tracer2 (32309)
- apache-commons (32309)
- apache-http (32309)
- buildings_tools (32309)
- continuosDownload (53)
- gson (32309)
- jogl (1.0.46)
- kendzi3d (1.0.190.1)
- kendzi3d-resources (0.0.1)
- log4j (32309)
- mapdust (32329)
- reverter (32309)
- terracer (32309)
- utilsplugin2 (32333)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lit&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Modified&zip=1

Last errors/warnings:
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS.data
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_BLOCK.key
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_BLOCK.data
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_INDEX.key
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_INDEX.data
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_INDEX_v2.key
- W: Unable to delete file <josm.pref>/cache/tiles/WMTS_INDEX_v2.data

[bastiK]

I thought this was working at some time, is it a regression?

[simon04]

Replying to bastiK:

I thought this was working at some time, is it a regression?

Whenever GetCapabilities is present in the user specified WMS URL, it uses exactly the specified URL, otherwise VERSION=1.1.1&SERVICE=WMS&REQUEST=GetCapabilities is requested
→ ​https://github.com/openstreetmap/josm/blob/a05f2a233d97248c4f3d622d3b77127719d43497/src/org/openstreetmap/josm/io/imagery/WMSImagery.java#L189

[wiktorn]

Just to let you know I'm working on a patch, that will allow us to move most of the layers to wms_endpoint and then - we will autodetect the WMS service version. Details are here:
​https://github.com/wiktorn/josm/compare/mirror...wiktorn:imagery_def_refactor

I've just took a short look on attached patch and it doesn't look conflicting so I guess we can go ahead with it as a temporary fix.

[simon04]

Milestone renamed

[Don-vip]

Milestone renamed

[Don-vip]

Replying to wiktorn:

Just to let you know I'm working on a patch, that will allow us to move most of the layers to wms_endpoint and then - we will autodetect the WMS service version.

Sounds nice, any news on this feature?

[wiktorn`]

Didn't had much time lately for JOSM. Once #6887 is fixed, I'll come back to this again.

[Don-vip]

Replying to wiktorn`:

Once #6887 is fixed, I'll come back to this again.

It's working now thanks to Simon :)