msg: {proj(<valid>)} is not a valid WMS argument. Please check this server URL

[A_Pirard]

Since Version 8677, this setting was OK in previous version.

msg: {proj(<valid>)} is not a valid WMS argument. Please check this server URL

wms[21]:​http://geoservices.wallonie.be/arcgis/services/TOPOGRAPHIE/PICC/MapServer/WmsServer?&SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png8&TRANSPARENT=TRUE&REQUEST=GetMap&STYLES=&SRS={proj(EPSG:4326,EPSG:31370,EPSG:3857,EPSG:102100)}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}&LAYERS=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,48,51,52,53,54,55

Message not copyable, gets out of the screen, URL copied from settings instead.

[wiktorn]

Indeed, I've dropped such {proj(EPSG:4326,EPSG:31370,EPSG:3857,EPSG:102100)} definitions, as I didn't find any evidence, that code was actually using this information to validate projections anyhow.

I also wonder, what's is the use case for this functionality. Because if you want to share the address within OSM community, it's probably the best, to include it in map presets, and there you can provide this information without a problem.

[A_Pirard]

Indeed, I've dropped such {proj(EPSG:4326,EPSG:31370,EPSG:3857,EPSG:102100)} definitions, as I didn't find any evidence, that code was actually using this information to validate projections anyhow.

Well, the normal way to remove capabilities is to deprecate them for a while first.
I have been suggested to use that &SRS syntax but I don't know at all how the whole thing works.
I have seen JOSM warn the user when he changes screen projection to one that a currently open layers doesn't support it or when opening a layer that the screen doesn't support. Can you show me in the documentation the explanation of how JOSM does that, how it knows the supported layer projections ? Does it learn the projections by reading the WMS capabilities?

I also wonder, what's is the use case for this functionality. Because if you want to share the address within OSM community, it's probably the best, to include it in map presets, and there you can provide this information without a problem.

Used as above, presumably. I suppose you should ask those who wrote that code and showed me to use it.
Map presets? Information? I suppose you mean Imagery>Preferences>Providers> ... osm.de/wiki/Maps
That page's documentation says "code:A projection name" and I don't understand how it works (what it does).
How does one "provide this information" in a private or non public setting otherwise than with defunct &SRS?
In any case, both &SRS and Maps methods are problematic because they do not reflect projections that the server could add later. Querying the capabilities is the only valid method in theory.

I thought that I had published such &SRS definitions but, after a careful check, it turns out that they are only private, phew! So, I'll close this ticket with "works for me" (us) and I'll stop worrying about projections in the future, but only after getting the answer to this question.

wiki/Help/Preferences/Map/Map projection says:

When you use rasterized background imagery then you need to set a projection supported by the service providing this imagery. JOSM is not able to change raster images. When image projection and current settings do not match, you get warned.

Beside not explaining (with a link) how JOSM knows "they don't", that documentation is not totally exact again.
JOSM works with many servers that support EPSG 4326 and not screen projection 3857. I was told, not by the doc, something like that it is because that reprojection is not too CPU intensive.
So, I have claimed in requesting server support, that 4326 should be implemented (I added 3857 only later).
But now I have just seen JOSM issue a message (that I could not copy again) warning against usage of 4326 because, if I recall well, some servers could implement it badly.
And I obviously fear to have talked nonsense in recommending 4326 and I wish that this documentation contained a link to where it would be explained why that basic projection and/or a plain mathematical reprojection function does not work on some servers, on which ones and how to check that.

Sorry to try to understand. Thank you.

[stoecker]

Replying to wiktorn:

Indeed, I've dropped such {proj(EPSG:4326,EPSG:31370,EPSG:3857,EPSG:102100)} definitions, as I didn't find any evidence, that code was actually using this information to validate projections anyhow.

I also wonder, what's is the use case for this functionality. Because if you want to share the address within OSM community, it's probably the best, to include it in map presets, and there you can provide this information without a problem.

That comes from the time before Maps presets provided that information. But I agree that the feature can be dropped. :-)

@A_Pirard:

This check only is needed to warn you about unsupported projections and for the silent 3857 into 4326 transformation, which is actually not really correct (only good for low resolutions) and only needed for servers not supporting 3857. Without the proj list you simply don't get a warning beforehand when you try access with an invalid projection, but instead you get no images.

What we do for 4326 and 3857 is that we silently press the 4326 images into the 3857 display field. Because 3857 has different scale factor depending on the latitude that's wrong, but for low zoom factors the scale change inside a single image is very small, so that's ok. If you display small zoom you see that effect, but luckily nobody draws at these zoom levels.

How to create a private maps file: Use the current maps file as base and create a new file with your entries. There are plenty of examples for all types of servers. Then add the address of that file to "imagery.layers.sites" in expert options. When storing the file somewhere on a server, you even can share private entries with others. :-)

[wiktorn]

Replying to A_Pirard:

Well, the normal way to remove capabilities is to deprecate them for a while first.
I have been suggested to use that &SRS syntax but I don't know at all how the whole thing works.
I have seen JOSM warn the user when he changes screen projection to one that a currently open layers doesn't support it or when opening a layer that the screen doesn't support. Can you show me in the documentation the explanation of how JOSM does that, how it knows the supported layer projections ? Does it learn the projections by reading the WMS capabilities?

There are two sources of knowledge about which projections server supports. One is from:
https://josm.openstreetmap.de/wiki/Maps

And the other - is when you use wms_endpoint (if you point to getCapabilities document and click to choose the layers at start).

If you provide wms:[...] link to someone, then JOSM will not know which projections do server supports.

The &SRS={proj} syntax is to provide WMS server with the information about what kind of projection JOSM expects from server, so the server can scale properly the images.

Used as above, presumably. I suppose you should ask those who wrote that code and showed me to use it.
Map presets? Information? I suppose you mean Imagery>Preferences>Providers> ... osm.de/wiki/Maps

I meant this page:
https://josm.openstreetmap.de/wiki/Maps

That page's documentation says "code:A projection name" and I don't understand how it works (what it does).

In WMS service specification on this page, you should specify with code all the projections, that the server provides. This will prevent reprojection to EPSG:4326 if user has selected unsupported projection and will prevent from showing the warning, that user is using projection unsupported by server.

How does one "provide this information" in a private or non public setting otherwise than with defunct &SRS?

It's not possible. It was kind of possible to provide this information earlier, but as this was not used at all, you actually didn't affect the behavior of JOSM with this information.

In any case, both &SRS and Maps methods are problematic because they do not reflect projections that the server could add later. Querying the capabilities is the only valid method in theory.

I thought that I had published such &SRS definitions but, after a careful check, it turns out that they are only private, phew! So, I'll close this ticket with "works for me" (us) and I'll stop worrying about projections in the future, but only after getting the answer to this question.

wiki/Help/Preferences/Map/Map projection says:

When you use rasterized background imagery then you need to set a projection supported by the service providing this imagery. JOSM is not able to change raster images. When image projection and current settings do not match, you get warned.

Beside not explaining (with a link) how JOSM knows "they don't", that documentation is not totally exact again.
JOSM works with many servers that support EPSG 4326 and not screen projection 3857. I was told, not by the doc, something like that it is because that reprojection is not too CPU intensive.
So, I have claimed in requesting server support, that 4326 should be implemented (I added 3857 only later).
But now I have just seen JOSM issue a message (that I could not copy again) warning against usage of 4326 because, if I recall well, some servers could implement it badly.

What I want to implement soon, is to provide additional setting in map presets, that this server is known to support 3857 -> 4326 reprojectinos, so this warning will be shown only on these, that do not implement this, or those, added by hand.

And I obviously fear to have talked nonsense in recommending 4326 and I wish that this documentation contained a link to where it would be explained why that basic projection and/or a plain mathematical reprojection function does not work on some servers, on which ones and how to check that.

I haven't found any way, to identify, which server will work properly with our 3857 -> 4326 reprojection and which not. Mainly - the problem is, that some servers do not support rescaling images to different DPI in X axis than in Y axis. WMS specification says only:

In the case where the aspect ratio of the BBOX and the ratio width/height are
different, the WMS '''shall''' stretch the returned map so that the resulting pixels could themselves be rendered in the
aspect ratio of the BBOX. In other words, it shall be possible using this definition to request a map for a device
whose output pixels are themselves non-square, or to stretch a map into an image area of a different aspect ratio. 

Mind the bold "shall". They should. But there is no sign, that they don't support. Only result is - bad imagery. So I think, that the only way to know is through experimentation.

[stoecker]

Replying to wiktorn:

What I want to implement soon, is to provide additional setting in map presets, that this server is known to support 3857 -> 4326 reprojectinos, so this warning will be shown only on these, that do not implement this, or those, added by hand.

And I obviously fear to have talked nonsense in recommending 4326 and I wish that this documentation contained a link to where it would be explained why that basic projection and/or a plain mathematical reprojection function does not work on some servers, on which ones and how to check that.

I haven't found any way, to identify, which server will work properly with our 3857 -> 4326 reprojection and which not. Mainly - the problem is, that some servers do not support rescaling images to different DPI in X axis than in Y axis. WMS specification says only:

I don't understand what you mean here. We request EPSG:3857 when supported by the server. We request EPSG:4326 instead when not and simply use the display code to pass the image into the requested picture area. There is no reprojection and also nothing the server needs to do.

Only issue know to me is that some servers announce EPSG:3857, but don't really support it. For these we simply removed the EPSG:3857 from the list of supported projections.

[wiktorn]

Replying to stoecker:

Replying to wiktorn:

I haven't found any way, to identify, which server will work properly with our 3857 -> 4326 reprojection and which not. Mainly - the problem is, that some servers do not support rescaling images to different DPI in X axis than in Y axis. WMS specification says only:

I don't understand what you mean here. We request EPSG:3857 when supported by the server. We request EPSG:4326 instead when not and simply use the display code to pass the image into the requested picture area. There is no reprojection and also nothing the server needs to do.

If server supports EPSG:3857 and user selects projection EPSG:3857, then we request an image from server:

• 512x512, bbox:s,w,n,e of such s,w,n,e that pixels are "square" according to EPSG:3857

If server doesn't support EPSG:4326 and user selects projection EPSG:3856, then:

• we generate 512x512, bbox:s,w,n,e of such s,w,n,e that pixels are "square" according to EPSG:3857
• we ask the server for an image of 512x512, bbox: s',w',n',e' where coordinates are converted to EPSG:4326. So server gets request for image, where pixels are not square

What we can do, is change the size of image to such, that it gives square pixels using this bbox and later - rescale this image in JOSM.

An example of such server is:
​http://mapy.zabytek.gov.pl/INSPIRE_IMD/service.svc/get

This shows coverage (sometimes building outlines) of immovable monuments in Poland. If you use it while using EPSG:3857 in JOSM, server returns invalid images.

Only issue know to me is that some servers announce EPSG:3857, but don't really support it. For these we simply removed the EPSG:3857 from the list of supported projections.

I wasn't aware of such servers :-) Good to know, there are such

[stoecker]

Can you attach an example what looks wrong for your example server? Essentially you propose a "don't trick" option to prevent EPSG:4326 calls?

As said it's a bloody workaround anyway. You see that when you zoom out to country or continent display. The nearer the poles your are the worst the distortion is. Can be 100km or so.

[A_Pirard]

As I said, I set the status to worksforme, which does not prevent more discussions between you.
My bottom line will be that much of what was written here and there should be in the documentation.
The least being a link where appropriate to the page explaining projections.
I know from experience that competent contributors DO NOT understand projections, less JOSM idiosyncrasies.
And in clear terms so that, for example, "map projection" is well understood as screen's map and not server's map.
Be aware of what the reader doesn't know. I'm sorry I have too little time for that.

[wiktorn]

Replying to stoecker:

Can you attach an example what looks wrong for your example server? Essentially you propose a "don't trick" option to prevent EPSG:4326 calls?

EPSG:3857	EPSG:4326

As you can see, in 3857 church position is totally misaligned with it's real position as well - it is shown twice.

This is this area:
​https://www.openstreetmap.org/#map=18/50.569378/22.061595

What I propose is to change WIDTH and HEIGHT parameters in WMS query, so in query we will ask for square pixels, but then in Java - rescale them back to non-square pixels.

As said it's a bloody workaround anyway. You see that when you zoom out to country or continent display. The nearer the poles your are the worst the distortion is. Can be 100km or so.

Indeed, but I see quite a lot of people working in this workaround mode. This worries me a bit and I'm not sure what to do with this...

[A_Pirard]

How to create a private maps file: Use the current maps file as base and create a new file with your entries. There are plenty of examples for all types of servers. Then add the address of that file to "imagery.layers.sites" in expert options. When storing the file somewhere on a server, you even can share private entries with others. :-)

Thanks for the very nice tip, but I copied https://josm.openstreetmap.de/wiki/Maps/Belgium to ​http://www.papou.byethost9.com/maps/myimagery/Wallonia, with and without ... , and when I add that URL where you say, nothing appears, as if the file did not exist.
I made and attached an imagery.log of what happens when the preset files are refreshed.
Missing mapsX file is intentional to better see what happens.
What should I do?

[wiktorn]

Can you also provide value of your imagery.layers.sites setting and a log, when you do not have mapsX file?

[stoecker]

I cannot download your link with wget and in a browser it requires JavaScript. When it should work with JOSM there must not be any interactive stuff between or cookie checking or JavaScript or whatever. A request must simply return the XML without anything else.

[A_Pirard]

My imagery.layers.sites setting is now just ​http://www.papou.byethost9.com/maps/myimagery/Wallonia and here is a new log.
As expected, it's the same as the previous one without the leading "file does not exist".
I had invalidated the original name in a way to restore it easily and to have a clear view of what my server is producing.
Can't you reproduce?
This is on almost plain 8704 and Ubuntu 12.04

[stoecker]

wget http://www.papou.byethost9.com/maps/myimagery/Wallonia
converted 'http://www.papou.byethost9.com/maps/myimagery/Wallonia' (ANSI_X3.4-1968) -> 'http://www.papou.byethost9.com/maps/myimagery/Wallonia' (UTF-8)
--2015-09-30 14:38:17--  http://www.papou.byethost9.com/maps/myimagery/Wallonia
Resolving www.papou.byethost9.com (www.papou.byethost9.com)... 185.27.134.210
Connecting to www.papou.byethost9.com (www.papou.byethost9.com)|185.27.134.210|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2015-09-30 14:38:17 ERROR 403: Forbidden.

In in web-browser I get (I added the line breaks):

<html><body><script type="text/javascript" src="/aes.js" ></script>
<script>function toNumbers(d){var e=[];d.replace(/(..)/g,function(d){e.push(parseInt(d,16))});return e}
function toHex(){for(var d=[],d=1==arguments.length&&arguments[0].constructor==Array?arguments[0]:arguments,e="",
f=0;f<d.length;f++) e+=(16>d[f]?"0":"")+d[f].toString(16);return e.toLowerCase()}
var a=toNumbers("f655ba9d09a112d4968c63579db590b4"),b=toNumbers("98344c2eee86c3994890592585b49f80"),
c=toNumbers("16da29f3e942f9c751f4f50dc66c6eac");document.cookie="__test="
+toHex(slowAES.decrypt(c,2,a,b))+"; expires=Thu, 31-Dec-37 23:55:55 GMT; path=/";
location.href="http://www.papou.byethost9.com/maps/myimagery/Wallonia?ckattempt=1";</script>
<noscript>This site requires Javascript to work, please enable Javascript in your browser or use a browser
with Javascript support</noscript></body></html>

Whatever proxy or setup you have, it's no normal HTTP access.

After enabling Javascript and downloading and when verifying I also get this:

xmllint --schema http://josm.openstreetmap.de/maps-1.0 Wallonia.xml
Wallonia.xml:22: element country-code: Schemas validity error : Element '{http://josm.openstreetmap.de/maps-1.0}country-code': [facet 'enumeration'] The value 'WA' is not an element of the set {....}

also for lines 38,51,64,77

[A_Pirard]

Thanks for your answers !!!
Sorry I hadn't seen (received by e-mail?) your second message.
I safely renamed the file *.txt and I made some debugging. To make it short...
I needed this to download a correct asis file:
wget --header "User-Agent: Mozilla/5.0" --header "Cookie: test=05fe38b67efa51c1438bcb727a65a225" ​http://papou.byethost9.com/maps/myimagery/Wallonia.txt
Could JOSM tweak HTTP Headers to do that? But isn't test probably time dependent and to be refreshed?
So, I finally made ​http://wiki.openstreetmap.org/wiki/User:Papou/myimagery
with contents similar to https://josm.openstreetmap.de/wiki/Maps/Belgium
But wget ... will load HTML. And for /Maps/Belgium too! ... and for /Maps too!
And only /Maps works in JOSM config.
So, what's the actual recipe to follow your advice?
TIA

[stoecker]

It's strange, that you actually can't find a web-service, where you simply can deliver a page as it is. Seems these are the disadvantages of Web 2.0 :-)

If you remove everything except the XML in OSM wiki, then you can add "?action=raw" at the end of the page to get the file.

​http://wiki.openstreetmap.org/wiki/User:Papou/myimagery?action=raw

It normal that wget loads HTML, when you access the wiki pages :-) JOSM wiki has a script behind which, cleans, checks, joins and delivers the XML data which is entered in the WIKI pages.

[A_Pirard]

Thanks, it works now.

It's strange, that you actually can't find a web-service, where you simply can deliver a page as it is. Seems these are the disadvantages of Web 2.0 :-)

Finding a free Web server is not a problem. The problem is knowing what it does before one subscribes, beyond that it will only take 2 minutes and a bare list of features.