WMS Sync Bot #1031
WMS Sync Bot #1031
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
@grischard @don-vip I suspect that the bot should not have updated "sources/europe/lv/lv_orthophoto_cycle6_2016-2018.geojson", I will look into this. The last time I checked this wms server does not follow the axis ordering of wms 1.3.0 for epsg:4326. I will look into this. |
|
I found the issue, there should be a editor-layer-index/scripts/sync_wms.py Lines 731 to 737 in 750ad4a This issue is that some WMS server do not support the differnt axis ordering dependent on the CRS of WMS 1.3.0. Unfortunately, there are both variants present (server where 1.3.0 returns the correct extent and not 1.1.1 and vice versa). The good thing is that based on my experience I expect only a small amount of servers that are affected by this. The intended behavior was to trust that in the existing configuration the server works correctly for EPGS:4326 and only to upgrade if the upgraded version returns the same image. Currently, I think it would be better to determine the correct working WMS version based on the source. E.g. we can compare the EPSG:3857 against the EPSG:4326 image. Additionally, the EPSG:4326 image can be compared to a WMS 1.3.0/EPSG:4326 image with reversed axis ordering as well as a WMS<1.3.0/EPSG:4326 image. I think this should be enough to determine the best WMS version, but I need probably some days until I have time to implement this. |
That's the problem with dealing with worldwide servers, you cannot trust all of them :) |
|
"Trust" is probably the wrong word. The script should not break something that is not already broken and in the best case repair if something is broken. Actually, there is nothing wrong with WMS 1.3.0 for "sources/europe/lv/lv_orthophoto_cycle6_2016-2018.geojson", but there is a bug in iD: openstreetmap/iD#8322 As the script by default tests with EPSG:4326 and does nothing when the test image returns an empty image (which is very likely the case when a WMS server does not support the axis ordering of WMS 1.3.0), it seems as there were no sources updated. However, there seem to be sources that were added that have troubles with EPSG:4326. #1034 logs some information about these sources: The following sources have different image hashes for EPSG:3857 and EPSG:4326 images. I need to go over them manually to identify if there is actually something wrong or the differences are just from reprojection / other quirks Furthermore, some |
github-actions
bot
force-pushed
the
create-pull-request/patch
branch
from
073717b to
4bbb975
Compare
They all seem to be ok. It looks as the maps are differently rendered depending on the projections and the DEM seem to have different shading. |
github-actions
bot
force-pushed
the
create-pull-request/patch
branch
from
4bbb975 to
cbc224d
Compare
|
All The WMS server of sources/europe/ch/Stadt_Zurich_Orthophoto2013_wms.geojson does not follow the axis ordering of WMS 1.3.0, but unfortunately it seems to be a buggy QGIS server where WMS 1.1.1 seems to be broken: qgis/QGIS#41051 |
Update url and available_projections of WMS sources using scripts/sync_wms.py. Sources are tested with scripts/check.py before PR is created. Delete .github/workflows/sync_wms.yml to stop.