Invert logic of epsg4326to3857Supported

[stoecker]

I still don't understand the logic of this option. WMS requests don't have a reason to be squared, so why is this option necessary? Which WMS does react wrong to non-squarred requests.

Instead of forcing addition of this option to any WMS which does not support 3857 directly I'd prefer if we reverse the default logic of it and set it only for the broken servers.

[wiktorn]

The problem lies within WMS spec, that for non-square requests:

(...) 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.

(page 35)

Please note - "shall", not "must". It means that not all implementations of WMS service must support non-square requests.

I have seen one service in Poland (run by National Heritage Board in Poland) running on Intergraph server, and one AFAIR in Belgium, that did not support such situation. But only indication of "broken" server, is that it returns gibberish images, not an error response (as one could expect).

If we would like to change our approach from "whitelisting", as it is now, i.e. we mark all that we know, that work properly, to "blacklisting", we mark only broken ones - we can drop this setting, and use only <projections> and just not list EPSG:3857 in them.

But such approach will not work for those services, that user will enter themselves into JOSM and may result in bug reports, that some WMS service doesn't display correctly.

[stoecker]

Ok, I now understand this.

If we would like to change our approach from "whitelisting", as it is now, i.e. we mark all that we know, that work properly, to "blacklisting", we mark only broken ones - we can drop this setting, and use only <projections> and just not list EPSG:3857 in them.

Why 3857? I thought that's about the 4326 as 3857? If 3857 is supported everything is fine, isn't it?

We did that approach before that option as well. Only add working projections.

But such approach will not work for those services, that user will enter themselves into JOSM and may result in bug reports, that some WMS service doesn't display correctly.

That's ok - there is a reason why we maintain the maps list with extended options and don't offer that many options in the JOSM internal interface - this is only meant as the necessary interface, not as the preferred interface.

The need to add that option everywhere is actually very disturbing.

[bastiK]

Replying to wiktorn:

The problem lies within WMS spec, that for non-square requests:

(...) 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.

(page 35)

Please note - "shall", not "must". It means that not all implementations of WMS service must support non-square requests.

In the context of this specification "shall" is a mandatory requirement, i.e. just a nicer way to say "must".

If we would like to change our approach from "whitelisting", as it is now, i.e. we mark all that we know, that work properly, to "blacklisting", we mark only broken ones - we can drop this setting, and use only <projections> and just not list EPSG:3857 in them.

But such approach will not work for those services, that user will enter themselves into JOSM and may result in bug reports, that some WMS service doesn't display correctly.

IMO, <projections> should only include the projections explicitly supported by the server. So if the server doesn't support EPSG:3857, it shouldn't be added to the list - no matter if it fails for non-square requests or not.

Then we need to tell JOSM, if it can do the 4326 workaround (default: yes). A blacklist parameter could prevent this for broken servers.

[Don-vip]

is this ticket still relevant now that we have warping with #7427?

[bastiK]

No, it's obsoleted.