Mapper: WMS (Web map service) support

[dg0yt]

puzzlepaint reported on Sourceforge [tickets:#84]:

Add support to use templates downloaded from web map services. Suggested by Haavard Tveite.

[dg0yt]

• labels: --> Templates, Web
• category: --> Feature_Request
• milestone: 1.0 --> 3.0

[dg0yt]

02JanDal posted on Sourceforge:

Here is a first patch implementing this. It's not very good yet, as it integrates into the existing template system you have to open a file (content doesn't matter) with the .asp extension (could be anything else). You then have to specify the server and some other properties.

Scaling is also not done yet.

This is the server I have been using to test: http://www2.demis.nl/mapserver/request.asp

If this is something that will eventually be merged I will continue working on it (don't have to open a dummy file and edit properties after initial load, saving/loading plus some other rough edges)

Attachments (on Sourceforge):

• 0001-Added-WMS-Web-Map-Service-template.patch (10301 bytes)

[dg0yt]

Jan, maybe you might do a fork of our git repository into a repository in your SF "user project" and use this for collecting your changes? This will give you full version control, and we don't need to keep track of to which revision the patches fit.

[dg0yt]

02JanDal posted on Sourceforge:

I have never made any more advanced usage of SF/git like that. I will have to look up how easy/hard it would be. (Mainly keeping my repo up to date and merging with the main stream again)

[dg0yt]

puzzlepaint posted on Sourceforge:

The patch itself looks good so far, as far as I can see from a short look at it. One nitpick however is to please respect our coding style (see the wiki), e.g. variables are named for example "server_edit" instead of "m_serverEdit".
I'd prefer to have it in a working state before merging it into mater, i.e. the downloaded image must be displayed in the correct position at least and it must be possible to save / load the template.

Maybe it is not so wrong to keep assigning the template with a file even for WMS templates, because this file can be used to cache the downloaded image. Then an internet connection is only neccessary when the template area is changed. Compared to embedding the image in the map file for caching it, this has the advantage that the map file can still be easily sent via e.g. email as the file size does not grow heavily.

But the way of creating the template should be changed. Instead of selecting a template file to open, there should be for example another action "Create template" with sub-actions for the template type to create (WMS, or even normal blank images for using them with the "draw on template" functionality). Then the user would select a file to save the template to, instead of opening one. There is still a currently permanently disabled button "Create..." in the template setup dock which was intended for exactly that.
Second, the template system must know that for this kind of template it is okay if the template file doesn't exist, otherwise it will be marked as missing when re-loading the map.

[dg0yt]

The cache will most likely be at directory, not a file. The menu item should be "Add template" with a submenu consisting of "File", "WMS", "OSM" etc.

(BTW, I just looked at JOSM. They use the term "Background". "Template" has a different meaning in JOSM.)

[dg0yt]

02JanDal posted on Sourceforge:

So, I have forked oomapper here:
https://sourceforge.net/u/jandalheimer/oorienteering/

I have worked more on the WMS fetching there, could you take a look and tell me what is left to be done before a merge?

It also includes creating of a blank template, this has not been tested much yet though.

Two things that will need more work are sizing and georeferencing. The first is only approximately right now, I would have to take a look at the proj library for that, and on the second I would need some guiding on how georeferencing works in code.

Jan

[dg0yt]

This fork seems to be a good tool for sharing your work at the moment. It is easy to browse your commits.

On the georeferencing: As I understand WMS, you will get georeferenced images ("tiles"). Thomas recently added support for image file georeferencing by world files. This could give you some hint how to align your tiles. (You might save the tile and generate a world files for testing.)

When the WMS does not use/support the geographic or projected CRS used by the OpenO map you will at least need to convert the coordinates (using proj).

To further reduce distortions, it might become necessary to convert the images. This could be handled by gdal. (gdalwarp is an executable for that purpose.) But this is really not needed at the moment.

[dg0yt]

02JanDal posted on Sourceforge:

I already looked at the world file parts, but that didn't really help me.

I've started to look at proj for the conversion, at least it seams like proj supports the EPSG:4326 projection used by most WMS servers.

I don't exactly get georeferenced tiles, I request one tile of a size and with the coordinate extent I want. Here is a nice explanation of how it works: http://www.demis.nl/home/pages/wms/docs/opengiswms.htm

[dg0yt]

Somebody posted on Sourceforge:

Before I continue looking at proj, is there any wrapper class or similar already used elsewhere?

[dg0yt]

Did you look at georeferencing.h/.cpp? This where it is used and wrapped. georeferencing_dialog.cpp is using that API.

[dg0yt]

02JanDal posted on Sourceforge:

Is it as easy as this?:

Georeferencing referencing;
referencing.setProjectedCRS("", "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs");
painter->drawImage(QRectF(referencing.toMapCoordF(LatLon(m_bb_rect.top(), m_bb_rect.left())).toQPointF(), m_image.size()), m_image);

I don't really know how to check if it is right.

[dg0yt]

puzzlepaint posted on Sourceforge:

No, it's not as easy. The georeferencing stuff relates two or three coordinate systems to each other, but in your code you specify only one. In addition, you'd need to transform at least two corners of the image to map coordinates to get correct positioning (ideally every pixel would be transformed individually).

Maybe the best solution would be to reuse ImageTemplate's positioning code, for example by calculating a "world file" for the image.

[dg0yt]

02JanDal posted on Sourceforge:

I've actually thought about making use of the TemplateImage code. I don't want to use it directly, as you may want to change parameters for the WMS map, but I will take a look at the TemplateImage code.

Are these world files some standard?

[dg0yt]

Am 06.11.2012 07:08, schrieb Jan Dalheimer:

Are these world files some standard?

Did you google for "world file"?

Kai.

[dg0yt]

02JanDal posted on Sourceforge:

Ups, didn't think about that...

Ok, before I continue working on WMS templates:
Should I merge WMS and normal image templates? The pros of that would be less code, the cons would be harder to update an already downloaded map.
What do you think?

If doing that: I can't find any reference to saving of world files. Is the data saved in the map file?

Jan

[dg0yt]

No, don't merge WMS and image. Image is working and well understood. I'm not sure if we really understand how complex the WMS implementation can get, how different it will look like, and when it will be ready. If we find similar code, we can refactor later.

[dg0yt]

02JanDal posted on Sourceforge:

I don't think it will be so complex, but ok.

I think it's wrong to go the intermediate step via a world file, as I then would have to take the code to reads the world file, and add that to the WMS template.

I read through the template_image.cpp file, and found lines like this:
MapCoordF top_left = map->getGeoreferencing().toMapCoordF(georef.data(), MapCoordF(-0.5, -0.5), &ok);

From that I created this code:
Georeferencing referencing;
referencing.setProjectedCRS("", "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs");
MapCoordF topleft_mapcoords = referencing.toMapCoordF(LatLon(m_bb_rect.top(), m_bb_rect.left()));
MapCoordF mapcoord = map->getGeoreferencing().toMapCoordF(&referencing, topleft_mapcoords);
painter->drawImage(QRectF(mapcoord.toQPointF(), m_image.size()), m_image);

I think that might be more like it.

Jan

[dg0yt]

The code example doesn't get it right. The GeoReferencing relates three coordinate systems for a georeferenced map:

1. The Geographic CRS uses latitude and longitude (decimal degrees) relative to the datum WGS84. This is fixed in our GeoReferencing implemenentation at the moment.
2. To put the world's surface on a plane, a projection and a cartesian coordinate system is used. This is what the the projected CRS is about. UTM serves a global standard here, but with regard to local base maps or aerial imagery, you might prefer another projected CRS. The projected CRS for the map is set (and cannot easily be changed) in map->getGeoreferencing().
3. The map is a section of that plane, using yet another coordinate system measured in units of paper size.

While conversion between 2 and 3 is simple (scale, reference point, rotation),
the conversion between geographic and projected coordinates is complex - and delegated to proj. If you want to convert geographic coordinates to map coordinates then you can can simply use the map's GeoReferencing to get from LatLon to MapCoordF.

When you ask for a flat image from a WMS, it will use some projection. If this projection is not the same projection which is used by map, you would have to reproject the image (as gdalwarp does). A simple transformation derived from the image corners will put many pixel in the wrong place.

Even for geographic coordinates, you need to pay attention to the datum. Local data may use geographic coordinates based on another datum (such as "Potsdam" in Germany).

The georeferencing dialog help page has some links which I found useful to learn about this topic.

[dg0yt]

02JanDal posted on Sourceforge:

Ok, seams like I took a topic a bit to high for me...

Quote: If you want to convert geographic coordinates to map coordinates then you can can simply use the map's GeoReferencing to get from LatLon to MapCoordF.

Does this mean I can use the function toMapCoordF(LatLon....... from the class Georeferencing from the object in the map object? Probably not, right?

All WMS services seam to support EPSG:4326, and from what I found out, the following is the proj string for it:
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

Does it happen that this is exactly like the projection used for the map? A long shoot, but might save a lot of work.

[dg0yt]

puzzlepaint posted on Sourceforge:

You actually _can_ use the map's georeferencing object like you wrote.

It doesn't seem like all WMS servers would be strictly required to support EPSG:4326. Quote from the standard:

"A WMS must support at least one CRS, and maps from multiple servers may be overlaid only if all the selected servers have at least one CRS in common. This International Standard does not mandate support for any particular Layer CRS(s). Instead, it only defines how CRSs are identified and discusses several optional Layer CRSs, in this clause and in Annex B. Map providers may support the CRSs that are most useful and appropriate to their geographic locale or information community. To maximize interoperability among servers, providers should also support geographic coordinates by geocentric coordinate systems such as “CRS:84” (see 6.7.3.2), “EPSG:4326” (see 6.7.3.3) or other ITRF-based systems."

I don't know how the situation is in practice however.

[dg0yt]

02JanDal posted on Sourceforge:

I can?! Sounds nice, I'm going to try later today.

I have used 4-5 servers for testing up till now, and they all supported EPSG:4326, and none other.

[dg0yt]

02JanDal posted on Sourceforge:

So is this all that is needed:
MapCoordF mapcoord = map->getGeoreferencing().toMapCoordF(LatLon(m_bb_rect.top(), m_bb_rect.left());

If yet, taking that for four corners and using that to transform the image should be rather easy.

[dg0yt]

The GeoReferencing class is indeed to make converting coordinates simple. You may select any of the three coordinate systems for the pointer position display.

I really recommend studying the pages linked in the GeoReferencing dialog help page.

The best strategy would be to ask the WMS for the same projected CRS that the map uses.

EPSG:4326 is not really a projected CRS suitable for mapping, but the standard geographic CRS (latitude and longitude) with WGS84 datum and ellipsoid. In that regard it is not really surprising that this CRS is widely supported by WMS.

If you simply interprete latitude and longitude as cartesian coordinates, distances are wrong (depending on direction), and shapes will be distorted. Cf. http://openlayers-buch.de/beispiele/chapter-07/compare_4326_31467.html. If you transform the corner points then the corner points will be right but most other points will still be wrong. Maybe the mistake is not significant for an orienteering map but I cannot tell. The smaller the tiles, the better.

[dg0yt]

02JanDal posted on Sourceforge:

I'm going to read through the links you recommended on Sunday afternoon (in plane then).

As most WMS seam to exclusively support EPSG:4326, it will probably limit the amount of servers that can be used if we would choose to not support it.

If transforming the corner points, the rest of the image would be sheared. Except if Mapper will be used for really large maps (probably not) I think normal shearing will be good enough.

[dg0yt]

02JanDal posted on Sourceforge:

I've started reading now, but not very fast, as I have had a bigger maths test today.

I also did some trial and error testing, with one OCAD template of an area and then loading a WMS map for the same area. It seamed that how ever I did it the OCAD template always ended up to the north west of where it should be, or the WMS map to the south east, depending on how you see it. I also tested with several maps, but it always was the same.

I know this is a bit lazy of me, but could you you (Kai), who already has a lot of experience with this create me the code to go from one coordinate in EPSG:4326 projection the a map coordinate?
That would be really nice.

Jan

[dg0yt]

havatv posted on Sourceforge:

Images returned through WMS do not have to have any georeferencing information attached. The WMS request specifies the exact (real world) extent and the size in pixels of the image (if you like, you can generate at "world" file from that). The image returned may not even have square pixels in "real world" units (it is the responsibility of the client to supply correct widths / heights).

Here in Norway, government WMSs (topographical maps, geological map, orthophotos, ...) offer all the officially supported projected coordinate systems, and some more (often unprojected WGS1984 - EPSG:4326).
So, if I was to use a WMS, I would request the images in the coordinate reference system that I use for my orienteering map (e.g. Euref 1989/WGS1984, UTM 32N - EPSG:32632/EPSG:25832).

Personally, I would not like to have the WMS images stored as "templates". A separate cache would probably be OK, but normally I would prefer to just use the WMS image as a background and then "throw it away" and request another image when I pan or zoom.

[dg0yt]

havatv posted on Sourceforge:

Regarding my previous message - I just saw the first of the three pages of discussion before I posted...

[bagage]

What would be the current status for this issue? Do you @dg0yt plan to work on it and/or have you any guidance about how to do it?

[dg0yt]

My suggestion is to base WMS support on GDAL (cf. http://www.gdal.org/frmt_wms.html). However, getting a single image from a WMS might be fairly simple even without GDAL if you don't have to fiddle with different projections. Note that the proliferation of HTTPS-only services adds even more requirements to such efforts (cf. #814).

This is nothing I'm planning work to on very soon. Apart from higher-priority issues, there is a lot of code which needs a review and refactoring before I want to add new complex features.

[bagage]

Well, using GDAL might be overkill but I think it makes sense. Thanks for the pointers.
But do you know WMS servers what we could use in Mapper?

Because actually with legal restrictions I don't know any WMS server that could suit our need, eg. Google does not allow use of its data for mapmaking, OpenStreetMap is ODBL license (while orienteering maps usually aren't), I doubt Bing allows it… so do you know any one that would allow us without law infringement?

[dg0yt]

There are regions and countries which have open geo data. Otherwise the principle is as with any other kind of template / base map one would use: The mapper (i.e. the user, not the software) has to find out the legal terms and to acquire the required permissions.

[Symbian9]

@dg0yt, Did you have a look onto Marble sourcecode?

• https://marble.kde.org/
  
  
  
  • https://github.com/KDE/marble
  
  

About WMS in Marble

• https://api.kde.org/stable/kdeedu-apidocs/marble/html/classMarble_1_1WmsServerLayout.html
• https://userbase.kde.org/Marble/WizardMap
• https://techbase.kde.org/Marble/CustomMaps

[bilbo2]

In many countries there are local WMS services provided by a government organization.
In many countries stuff made by government is considered "public work" or "official work" and effectively is in public domain. So, it can be used to draw maps, without even need to ask for special permission!

Quality varies, sometimes it is good enough to draw some rudimentary map straight from it.

In Czech Republic there is at least one such source usable (UHUL ortofoto), while not perfect (black and white, 17 years old, 2meters/pixel), it is usable to draw roads, tracks, buildings, forest outlines, etc ... so when you start mapping details on the spot, you do not start with just a blank piece of paper.

Openstreetmap project is/was dealing with quite a lot of WMS sources they can use, some of them have special permission just for OSM, but some of them are also usable as base for orienteering maps.

So, this would definitely be useful.

[Symbian9]

The mapper (i.e. the user, not the software) has to find out the legal terms and to acquire the required permissions.

OpenAerialMap could be used as copyright-free for derivative (tracing) works

• https://map.openaerialmap.org/
• https://github.com/hotosm/OpenAerialMap

As all imagery provided by OpenAerialMap licensed under CC-BY 4.0 license it's possible use it without any "copyright" or "copyleft" limitations on resulted map.

• http://openaerialmap.org/legal/
• https://creativecommons.org/licenses/by/4.0/

Merkaartor & QGIS (both Qt-based apps and under GNU GPL) already has such feature, so, maybe looking in each sources would be usefull for solve time and not reinvent
bicycle

• http://github.com/openorienteering/merkaartor
  
  
  
  • https://github.com/koying/Merkaartor/blob/master/share/WmsServersList.xml
  
  
• http://github.com/qgis/qgis
  
  
  
  • https://github.com/hotosm/oam-qgis-plugin
  
  

REFERENCE

• https://maps.cga.harvard.edu/qgis/wkshop/wms.php
• https://trac.openstreetmap.org/ticket/758
• http://wiki.openstreetmap.org/wiki/Tiles_and_tiling/Setting_up_WMS_or_TMS

P.S.: @dg0yt, sorry me for creating duplicated issue.

[valdisj]

Any plans to add WMS as options to use in Templates?

[dg0yt]

@valdisj Sure it is planned. This is what this ticket is about.

At the moment we just add GDAL raster format support. Adding WMS support will be much more complex than that. (Coordinate transformations? Tiling? Caching? Resolution? Network access? ...)

OTOH I wouldn't be surprised if it would already work if you provide a proper XML description file.

[valdisj]

Hi,

I’m just not so advanced to try this. For example this one:
http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:ZemeLKS http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:ZemeLKS
http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:LIDARHeight2m http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:LIDARHeight2m

Valdis

On 24 Feb 2020, at 15:08, Kai Pastor [e-mail] wrote:

@valdisj https://github.com/valdisj Sure it is planned. This is what this ticket is about.

At the moment we just add GDAL raster format support. Adding WMS support will be much more complex than that. (Coordinate transformations? Tiling? Caching? Resolution? Network access? ...)

OTOH I wouldn't be surprised if it would already work if you provide a proper XML description file https://gdal.org/drivers/raster/wms.html#xml-description-file.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/OpenOrienteering/mapper/issues/84?email_source=notifications&email_token=ABHRZJSKHTZJP4CNZYFCQG3REPBGFA5CNFSM4C3CI7DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMXXCPQ#issuecomment-590311742, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHRZJWCHDHC4VPZOV76KP3REPBGFANCNFSM4C3CI7DA.

[Symbian9]

OTOH I wouldn't be surprised if it would already work if you provide a proper XML description file.

WOW! Is there any ready-to-use XML description example file? Would be happy to test it

[lpechacek]

WOW! Is there any ready-to-use XML description example file? Would be happy to test it

xmltest.xml:

<GDAL_WMS>
  <Service name="WMS">
    <Version>1.3.0</Version>
    <ServerUrl>http://lvmgeoserver.lvm.lv/geoserver/ows?SERVICE=WMS</ServerUrl>
    <Layers>public:OrtoIR_LKS</Layers>
    <CRS>EPSG:102440</CRS>
    <ImageFormat>image/png</ImageFormat>
    <Transparent>FALSE</Transparent>
    <BBoxOrder>xyXY</BBoxOrder>
  </Service>
  <DataWindow>
    <UpperLeftX>507402.7311805383652</UpperLeftX>
    <UpperLeftY>6310646.206678840332</UpperLeftY>
    <LowerRightX>508610.4866644098074</LowerRightX>
    <LowerRightY>6311648.871608846821</LowerRightY>
    <SizeX>636</SizeX>
    <SizeY>528</SizeY>
  </DataWindow>
</GDAL_WMS>

Command line (Linux):

gdal_translate --debug on xmltest.xml output.png

If all goes well, the resulting file (output.png) contains IR aerial map of a railway station and a neighboring park. Happy testing! :)

[dg0yt]

Well, I never get very far. EPSG:102440 is the first deal-breaker....

~
gdalinfo 'http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:ZemeLKS'
~

gives a number of alternative subdataset, image formats, CRS. Picking e.g. Topo50, I can run

~
gdal_translate 'WMS:http://lvmgeoserver.lvm.lv/geoserver/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=public%3ATopo50&CRS=CRS:84&BBOX=20.60160022997893,55.59797427064026,28.668545873438855,58.189668901560495' -of WMS wms.xml
~

I cannot use that wms.xml file in Mapper directly, but need to create a VRT file for raster data:

~
gdalbuildvrt wms.raster.vrt wms.xml
~

But when I try to add this in Mapper, i still get 0x0 pixels. For the record, there is more alternative data (that is: overviews) to be discovered from wms.xml or the vrt file via

~
gdalinfo wms.xml
~

[valdisj]

I do not know, if it helps, but Latvia (and this source), is in EPSG 3059

On 24 Feb 2020, at 21:58, Kai Pastor [e-mail] wrote:


Well, I never get very far. EPSG:102440 is the first deal-breaker....

gdalinfo 'http://lvmgeoserver.lvm.lv/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&layer=public:ZemeLKS'
gives a number of alternative subdataset, image formats, CRS. Picking e.g. Topo50, I can run

gdal_translate 'WMS:http://lvmgeoserver.lvm.lv/geoserver/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=public%3ATopo50&CRS=CRS:84&BBOX=20.60160022997893,55.59797427064026,28.668545873438855,58.189668901560495' -of WMS wms.xml
I cannot use that wms.xml file in Mapper directly, but need to create a VRT file for raster data:

gdalbuildvrt wms.raster.vrt wms.xml
But when I try to add this in Mapper, i still get 0x0 pixels. For the record, there is more alternative data (that is: overviews) to be discovered from wms.xml or the vrt file via

gdalinfo wms.xml
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Symbian9]

I do not know, if it helps, but Latvia (and this source), is in EPSG 3059

If replace EPSG:102440 with EPSG:3059 in this example — it returns just blank image.

FTR, With EPSG:102440 it returns as IR aerial map of a railway station and a neighboring park. And here is screenshot of resulted image & how it (output.png+output.png.aux.xml) imported into Mapper as «Georeferenced (PNG)» template.

@lpechacek Are you sure about upper/lower X/Y in your example?

...
  <DataWindow>
    <UpperLeftX>507402.7311805383652</UpperLeftX>
    <UpperLeftY>6310646.206678840332</UpperLeftY>
    <LowerRightX>508610.4866644098074</LowerRightX>
    <LowerRightY>6311648.871608846821</LowerRightY>
    <SizeX>636</SizeX>
    <SizeY>528</SizeY>
  </DataWindow>
</GDAL_WMS>

As for me, each lower value should be switched to related upper value, and wise versa.

...
  <DataWindow>
    <UpperLeftX>508610.4866644098074</UpperLeftX>
    <UpperLeftY>6311648.871608846821</UpperLeftY>
    <LowerRightX>507402.7311805383652</LowerRightX>
    <LowerRightY>6310646.206678840332</LowerRightY>
    <SizeX>636</SizeX>
    <SizeY>528</SizeY>
  </DataWindow>
</GDAL_WMS>

[valdisj]

Wow, thats some progress. Thats actually Riga city center.
The WMS service (right side of the page) points to the public information for Latvian Forest management company
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fwww.lvmgeo.lv%2Fdati

[lpechacek]

If replace EPSG:102440 with EPSG:3059 in this example — it returns just blank image.

Thanks for looking into it. At first, I didn't notice that only QGIS and the WMS server understand EPSG:102440. It seems to be missing from PROJ.4 database. For successful image retrieval, also the image coordinates need to be translated.

@lpechacek Are you sure about upper/lower X/Y in your example?

Yes. While hand-editing the file, I swapped the upper and lower bounds. I hope, below is now a correct example for EPSG:3059. In any case, Kai's way of building the WMS description with gdal_translate than my text-editor approach.

<GDAL_WMS>
  <Service name="WMS">
    <Version>1.3.0</Version>
    <ServerUrl>http://lvmgeoserver.lvm.lv/geoserver/ows?SERVICE=WMS</ServerUrl>
    <Layers>public:OrtoIR_LKS</Layers>
    <CRS>EPSG:3059</CRS>
    <ImageFormat>image/png</ImageFormat>
    <Transparent>FALSE</Transparent>
    <BBoxOrder>xyXY</BBoxOrder>
  </Service>
  <DataWindow>
    <UpperLeftX>310646.206678840332</UpperLeftX>
    <UpperLeftY>508610.4866644098074</UpperLeftY>
    <LowerRightX>311648.871608846821</LowerRightX>
    <LowerRightY>507402.7311805383652</LowerRightY>
    <SizeX>636</SizeX>
    <SizeY>528</SizeY>
  </DataWindow>
</GDAL_WMS>

For some reason it works only with gdal_translate. Opening the file in QGIS or Mapper yields no result. I'm not enough into GDAL to tell why is that.

[dg0yt]

For the record, the deal break with the naive approach is that the WMS driver reports incredible image dimensions. Of cource we are not meant to allocate several petabyte of RAM. The data must be accessed block-wise.