WMS refuses to load with some of the projections that has no bounds defined

[Polarbear-j]

I typically use the projection "By Code EPSG" 25833 for working with my local WMS layers. With the changes on WMS late June 2015, the layers were not loaded anymore ("no tiles at this zoom level") while in that projection. Switching to Mercator got the WMS loaded (with the warning about inappropriate projection).

I turned out that I also had the plugin proj4j activated. Trying to use proj4j itself for lead to errors in one occasion EPSG 25833, but could not be reproduced.

The presence of proj4j alone, even with "By Code EPSG" selected, prevents the WMS from being loaded.
Disabling proj4j, WMS works.

Is there a need for proj4j anyway as we have "By Code EPSG"?

current rev 8607

[wiktorn]

Can you share the location and the WMS imagery that you use?

[anonymous]

Several WMS were affected, one example was Berlin, here the entry from my settings:

wms:http://fbinter.stadt-berlin.de/fb/wms/senstadt/k_luftbild2014?FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=0&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

[anonymous]

I noticed this too in josm-latest (revision 8607), whereby wms_endpoint:http://karta2.orebro.se/mywms1/Ovrigt.wms stopped working. This needs EPSG:3009 to work reliably. That projection is not available unless proj4j is installed it appears (it doesn't show up in "By Code (EPSG)" when I disable proj4j at least.

[Polarbear-j]

Yes when I have proj4j enabled, and using "By Code (EPSG)", it shows "EPSG: 25833" and "Proj4j: 25833 selected", and it knows 3009 as well.

When proj4j is disabled, "By Code (EPSG)" does no know your 3009, and for 25833 it shows: "EPSG: 25833" and "ETRS/UTM zone 33N, 10.0, -5.0 : 20,0, 85.0"

Just a guess, maybe there is an issue with the boundary definition in proj4j ? That might explain the "no tiles at this zoom level" issue ?

Apparently feeding more projections into the "By Code (EPSG)" database would fix the issue also...

[anonymous]

Right, I regularly use 3006 and 3009 (both are specific to Sweden), neither of which is known without proj4j. There is a bunch more that are specific to Sweden or specific areas in Sweden (which I currently do not use) but which also need proj4j.

[wiktorn]

It looks like proj4j doesn't report correctly world bounds and that prevents proper calculation of the tile size. As in #11701, I'll extend the list of supported projections in JOSM so proj4j will not be needed then.

@bastiK:
We will need then phase out proj4j plugin.

[bastiK]

Replying to wiktorn:

It looks like proj4j doesn't report correctly world bounds and that prevents proper calculation of the tile size.

How so? WMS has worked fine without world bounds so far.

As in #11701, I'll extend the list of supported projections in JOSM so proj4j will not be needed then.

It may be good to keep our current list and the unchanged "upstream" data in separate files. One reason is to make it easier for package-people from Linux distributions to remove the file and refer to the epsg file from the proj4 package.

@bastiK:
We will need then phase out proj4j plugin.

I'm not convinced, the proj4j plugin is un-fixable. Nevertheless, I would rather improve JOSM, so it is no longer needed.

[wiktorn]

It looks like I've nailed the problem, it more less is related to the fact, that converting bounds from EastNorth to LatLon and back to EastNorth might be non-symmetric (especially at the poles - converting X,Y EastNorth that gives LatLon -90,-90 will not convert to X,Y EastNorth, but to -X,Y).

[wiktorn]

In 8618/josm:

Fix calculation of World Bounds for WMS when no projection has no bounds defined, and bogus results are returned on boundaries.

Closes: #11697, #11701

[Don-vip]

Milestone renamed