Reprojection error

[Polarbear-j]

I get the tile-offsets as shown in the attachment when particular imagery layers are reprojected.

How to reproduce:
Set Mercator/EPSG:3857, load Berlin 2011.

Tiles are shifted, retrieved as epsg 4326:

2017-11-20 11:17:56.652 INFO: GET http://fbinter.stadt-berlin.de/fb/wms/senstadt/k_luftbild2011_20?FORMAT=image/png&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=0&STYLES=&SRS=EPSG:4326&WIDTH=512&HEIGHT=512&BBOX=13.3717263,52.4665849,13.3730996,52.4679582 -> 200

When I switch JOSM to epsg:25833, it retrieves the images again in native projection and displays them fine.

I had tried to clear the cache for this layer, but behaviour remains.

Set Mercator/EPSG:3857, load Berlin 2013, which does not show the problem:
However JOSM retrieves Epsg 25832:

2017-11-20 11:23:21.729 INFO: GET http://fbinter.stadt-berlin.de/fb/wms/senstadt/k_luftbild2013?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=0&STYLES=&SRS=EPSG:25832&WIDTH=512&HEIGHT=512&BBOX=796920.1153236,5821941.6414557,796996.5523486,5822018.0784807 -> 200

Well, it might be the case that the fault comes from the server when delivering epsg 4326. If that is the case, I'd need a method to nail the imagery layer to be retrieved in their native format (e.g. always 25833)

Identification: JOSM/1.5 (13064 en) Mac OS X 10.11.6
OS Build number: Mac OS X 10.11.6 (15G1611)
Memory Usage: 2284 MB / 3641 MB (1088 MB allocated, but free)
Java version: 1.8.0_131-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 69733312 2048x1280, Display 725111823 1680x1050

[bastiK]

Cannot reproduce the problem. The entry for Berlin 2011 lists EPSG:25833, EPSG:25832 and EPSG:3068 as supported projections, so it should not try to fetch tiles in epsg 4326. (And it does not in my test.)

The question is, how do you load this imagery? Is it a custom entry or taken from the official list?

[Polarbear-j]

Ok there we are. It comes from a custom entry, which however was identical to the listed entry (I had png originally, but that is unrelated).

The point is that the listed entry restricts projections, while I have no such setting in the image prefs for the my custom entry. I do not even see those settings for the listed entry.

 <code>EPSG:25833</code><code>EPSG:25832</code><code>EPSG:3068</code>
 <!-- there are some more supported projections but those are not conformal and should therefore not used by Joe Average -->

For some reason, josm uses the last from the getcapabilities:

<SRS>EPSG:3068</SRS>
<SRS>EPSG:25833</SRS>
<SRS>EPSG:25832</SRS>
<SRS>EPSG:4258</SRS>
<SRS>EPSG:4326</SRS>

In "Add imagery URL", I do not see, nor can I restrict, the projections offered by the service. Probably we need a method to add those?
Secondly, the question is why reprojecting EPSG:4326 fails. How would we find out if it fails on the service provider or in JOSM?

Logs:

custom:
2017-11-20 15:53:37.089 INFO: Reprojecting layer 0 fbinter.stadt-berlin.de: Luftbilder 2011 (Orthophotos) from EPSG:4326 to EPSG:3857. For best image quality and performance, switch to one of the supported projections: EPSG:4326, EPSG:25832, EPSG:4258, EPSG:25833, EPSG:3068
listed:
2017-11-20 16:05:32.904 INFO: Reprojecting layer Berlin aerial photograph 2011 from EPSG:25833 to EPSG:3857. For best image quality and performance, switch to one of the supported projections: EPSG:25833, EPSG:25832, EPSG:3068

[stoecker]

Replying to Polarbear-j:

In "Add imagery URL", I do not see, nor can I restrict, the projections offered by the service.

Yes. Because this is an easy to use interface and not an "we fix all the trouble of the world" one. For this we have the default entries which are verified and properly checked (most of the time).

Probably we need a method to add those?

You can create an private maps XML file and add this as data source.

Secondly, the question is why reprojecting EPSG:4326 fails. How would we find out if it fails on the service provider or in JOSM?

Very likely the server sends broken EPSG:4326 data. That happens sometimes. That may also be the reason why these projections are left out in the official XML file.

[Polarbear-j]

agreed, thanks.