[GRASS-user] Any freely available topographical maps for (South-) Germany ?

Hamish · June 13, 2008, 11:45am

[r.in.wms]

Hamish wrote:

no geotiff support. set format= to one of the above.

I tried in a WGS84 lat/lon loc:

g.region n=50:30N s=47:15N w=9E e=13:45E res=0:00:30
r.in.wms mapserver="$SERVER" layer=TK50
out=TK50_Bavaria format=png -g

it seemed to work, but I only got a blank map. Maybe you
will have better luck. Using "-g" I got a
"(c) Bayerische ..." in the image, without "-g" I didn't. shrug.

Richard wrote:

I've never been able to decide whether "blank raster syndrome" in
r.in.wms is at the client or the server. In some cases, I guess it's
the server because things rectify themselves if you come back tomorrow.

In this case I'm pretty sure it's the server. As above, in at least one set of blank images I see the (c) watermark which comes through ok. Also with r.in.wms you can look in the $LOCATION/wms_downloads/ dir and see the raw download images before any client processing. all blank.

In other cases, adjusting the region parameters - zoom in to a smaller
area, and use a finer resolution - fixes the problem.

I took your suggestion and tried zooming in some. Success!
I would note that earlier when I was getting the blank image I did check the bounds layer's capabilities to make sure I was not exceeding the bounding box. So it seems to be matter of scale, not bounding box.

# LL/WGS84 location
SERVER="http://www.geodaten.bayern.de/ogc/getogc.cgi?"

g.region n=49:17N s=48:33N w=10:54:30E e=11:32:30E res=0:00:02
r.in.wms mapserver="$SERVER" layer=UK500 out=UK500_Bavaria.3 format=tiff

then you get a map of roads, place names, cities, etc.
(format=tiff looks more detailed than 8bit png, but png is way more efficient for empty files. shrug)

#zooming in more, DOP layer (2m aerial photo) looks good:
g.region n=49:12:02N s=49:04:20N w=11:03:26E e=11:11:42E res=0:00:01
r.in.wms mapserver="$SERVER" layer=DOP out=DOP_Bavaria format=tiff

# and zooming even further the TK50 layer finally works
# TK50 is a similar feature map to UK500, including contours
g.region n=49:10:06N s=49:07:34N w=11:06:27E e=11:08:54E res=0:00:00.25
r.in.wms mapserver="$SERVER" layer=TK50 out=TK50_Bavaria format=tiff

So yes, zooming helps.
The DOP layer draped over SRTM data would look very nice.

Hamish

ps- I have just added an option in SVN to store the capabilities file when using the -l flag.

Wolfgang · June 13, 2008, 2:55pm

Hamish schrieb:

[r.in.wms]

Hamish wrote:

no geotiff support. set format= to one of the above.

I tried in a WGS84 lat/lon loc:

g.region n=50:30N s=47:15N w=9E e=13:45E res=0:00:30
r.in.wms mapserver="$SERVER" layer=TK50
out=TK50_Bavaria format=png -g

it seemed to work, but I only got a blank map. Maybe you
will have better luck. Using "-g" I got a
"(c) Bayerische ..." in the image, without "-g" I didn't. shrug.

Richard wrote:

I've never been able to decide whether "blank raster syndrome" in
r.in.wms is at the client or the server. In some cases, I guess it's
the server because things rectify themselves if you come back tomorrow.

In this case I'm pretty sure it's the server. As above, in at least one set of blank images I see the (c) watermark which comes through ok. Also with r.in.wms you can look in the $LOCATION/wms_downloads/ dir and see the raw download images before any client processing. all blank.

In other cases, adjusting the region parameters - zoom in to a smaller
area, and use a finer resolution - fixes the problem.

I took your suggestion and tried zooming in some. Success!
I would note that earlier when I was getting the blank image I did check the bounds layer's capabilities to make sure I was not exceeding the bounding box. So it seems to be matter of scale, not bounding box.

# LL/WGS84 location
SERVER="http://www.geodaten.bayern.de/ogc/getogc.cgi?"

g.region n=49:17N s=48:33N w=10:54:30E e=11:32:30E res=0:00:02
r.in.wms mapserver="$SERVER" layer=UK500 out=UK500_Bavaria.3 format=tiff

then you get a map of roads, place names, cities, etc.
(format=tiff looks more detailed than 8bit png, but png is way more efficient for empty files. shrug)

#zooming in more, DOP layer (2m aerial photo) looks good:
g.region n=49:12:02N s=49:04:20N w=11:03:26E e=11:11:42E res=0:00:01
r.in.wms mapserver="$SERVER" layer=DOP out=DOP_Bavaria format=tiff

# and zooming even further the TK50 layer finally works
# TK50 is a similar feature map to UK500, including contours
g.region n=49:10:06N s=49:07:34N w=11:06:27E e=11:08:54E res=0:00:00.25
r.in.wms mapserver="$SERVER" layer=TK50 out=TK50_Bavaria format=tiff

So yes, zooming helps.
The DOP layer draped over SRTM data would look very nice.

Yes the server provides only white images when less then 2 meter / pixel resolution. I used a own written script which downloads the images with some overlap to get rid of the copy right notice.

At least for the alps you can get elevation data with 1 arcsec from http://www.viewfinderpanoramas.org/dem3.html#hgt

There was also some time ago a library to convert the data from the "Top50" CDs that you can purchase for low money, but that is offline again ;-( http://libmpr.origo.ethz.ch .

Hamish · June 14, 2008, 2:01am

WolfgangZ wrote:

Yes the server provides only white images when less then 2
meter / pixel resolution.

the DOP photo layer worked for me even at 2 arcsec resolution and appropriate region. the topo maps seemed more insistent at being at a sane resolution for the given data.

I used a own written script which downloads the
images with some overlap to get rid of the copy right notice.

using r.in.wms's default http POST method instead of the -g flag's GET method returned images without the (c) plastered on every tile.

There was also some time ago a library to convert the data
from the "Top50" CDs that you can purchase for low money,
but that is offline again ;-( http://libmpr.origo.ethz.ch .

maybe the wayback machine helps?
http://web.archive.org/web/*/http://libmpr.origo.ethz.ch

(but it's offline too right now

Hamish

Nikos_Alexandris1 · June 14, 2008, 9:11am

On Fri, 2008-06-13 at 19:01 -0700, Hamish wrote:

WolfgangZ wrote:
> Yes the server provides only white images when less then 2
> meter / pixel resolution.

the DOP photo layer worked for me even at 2 arcsec resolution and appropriate region. the topo maps seemed more insistent at being at a sane resolution for the given data.

> I used a own written script which downloads the
> images with some overlap to get rid of the copy right notice.

using r.in.wms's default http POST method instead of the -g flag's GET method returned images without the (c) plastered on every tile.

> There was also some time ago a library to convert the data
> from the "Top50" CDs that you can purchase for low money,
> but that is offline again ;-( http://libmpr.origo.ethz.ch .

maybe the wayback machine helps?
http://web.archive.org/web/*/http://libmpr.origo.ethz.ch

(but it's offline too right now

Hamish

Great!!! Thanks to all

Nikos_Alexandris1 · June 14, 2008, 11:34am

[ I assume this has to again with variables, paths and similar in which
I still don't understand fully. Isn't there a way to set this by default
when installing GRASS (or gdaltools)? ]

Under Ubuntu64bit I get some trouble with r.in.gdal (actually gdalwarp):

r.in.wms mapserver="$SERVER" layer=UK500 out=UK500_Bavaria.3 format=tiff
Calculating tiles
Requesting 1 tiles.
Downloading tiles
Tile already downloaded
All tiles downloaded successfully
Creating output file that is 572P x 662L.
Processing input
file /home/nik/grassdb/rlp_fgaps/wms_download/UK500_Bavaria.3__0.tiff.
Using band 4 of source image as alpha.
Using band 4 of destination image as alpha.
0...10...20...30...40...50...60...70...80...90...100 - done.
*** glibc detected *** gdalwarp: double free or corruption (!prev):
0x0000000000611a10 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f0c0a3f308a]
/lib/libc.so.6(cfree+0x8c)[0x7f0c0a3f6c1c]
/usr/lib/libgdal1.5.0.so.1(_ZN17GDALDriverManagerD0Ev
+0x49)[0x7f0c0b121cc9]
gdalwarp[0x403441]
/lib/libc.so.6(__libc_start_main+0xf4)[0x7f0c0a39d1c4]
gdalwarp(GDALTermProgress+0xa1)[0x402a39]
======= Memory map: ========
00400000-00407000 r-xp 00000000 08:06
1710513 /usr/bin/gdalwarp
00606000-00607000 rw-p 00006000 08:06
1710513 /usr/bin/gdalwarp
00607000-00698000 rw-p 00607000 00:00 0
[heap]
7f0bf8000000-7f0bf8021000 rw-p 7f0bf8000000 00:00 0
7f0bf8021000-7f0bfc000000 ---p 7f0bf8021000 00:00 0
7f0bff8ff000-7f0bffce8000 r-xp 00000000 08:06
1778199 /usr/lib/libxerces-c.so.27.0
7f0bffce8000-7f0bffee7000 ---p 003e9000 08:06
1778199 /usr/lib/libxerces-c.so.27.0
7f0bffee7000-7f0bfff2b000 rw-p 003e8000 08:06
1778199 /usr/lib/libxerces-c.so.27.0
7f0bfff2b000-7f0bfff2c000 rw-p 7f0bfff2b000 00:00 0
7f0bfff2c000-7f0bfffe3000 r-xp 00000000 08:06
1778128 /usr/lib/libfftw3.so.3.1.2
7f0bfffe3000-7f0c001e3000 ---p 000b7000 08:06
1778128 /usr/lib/libfftw3.so.3.1.2
7f0c001e3000-7f0c001e9000 rw-p 000b7000 08:06
1778128 /usr/lib/libfftw3.so.3.1.2
7f0c001e9000-7f0c00220000 r-xp 00000000 08:06
863332 /lib/libncurses.so.5.6
7f0c00220000-7f0c0041f000 ---p 00037000 08:06
863332 /lib/libncurses.so.5.6
7f0c0041f000-7f0c00424000 rw-p 00036000 08:06
863332 /lib/libncurses.so.5.6
7f0c00424000-7f0c0087d000 r-xp 00000000 08:06
1779769 /usr/lib/libgdal1.4.0.so.1.11.4
7f0c0087d000-7f0c00a7c000 ---p 00459000 08:06
1779769 /usr/lib/libgdal1.4.0.so.1.11.4
7f0c00a7c000-7f0c00ae7000 rw-p 00458000 08:06
1779769 /usr/lib/libgdal1.4.0.so.1.11.4
7f0c00ae7000-7f0c00b2c000 rw-p 7f0c00ae7000 00:00 0
7f0c00b2c000-7f0c00b2d000 r-xp 00000000 08:06
427966 /usr/local/grass-6.3.1svn/lib/libgrass_linkm.6.3.1svn.so
7f0c00b2d000-7f0c00d2d000 ---p 00001000 08:06
427966 /usr/local/grass-6.3.1svn/lib/libgrass_linkm.6.3.1svn.so
7f0c00d2d000-7f0c00d2e000 rw-p 00001000 08:06
427966 /usr/local/grass-6.3.1svn/lib/libgrass_linkm.6.3.1svn.so
7f0c00d2e000-7f0c00d34000 r-xp 00000000 08:06
427993 /usr/local/grass-6.3.1svn/lib/libgrass_rtree.6.3.1svn.so
7f0c00d34000-7f0c00f34000 ---p 00006000 08:06
427993 /usr/local/grass-6.3.1svn/lib/libgrass_rtree.6.3.1svn.so
7f0c00f34000-7f0c00f35000 rw-p 00006000 08:06
427993 /usr/local/grass-6.3.1svn/lib/libgrass_rtree.6.3.1svn.so
7f0c00f35000-7f0c00f4c000 r-xp 00000000 08:06
427988 /usr/local/grass-6.3.1svn/lib/libgrass_dig2.6.3.1svn.so
7f0c00f4c000-7f0c0114c000 ---p 00017000 08:06
427988 /usr/local/grass-6.3.1svn/lib/libgrass_dig2.6.3.1svn.so
7f0c0114c000-7f0c0114d000 rw-p 00017000 08:06
427988 /usr/local/grass-6.3.1svn/lib/libgrass_dig2.6.3.1svn.so
7f0c0114d000-7f0c0116d000 r-xp 00000000 08:06
427943 /usr/local/grass-6.3.1svn/lib/libgrass_dgl.6.3.1svn.so
7f0c0116d000-7f0c0136d000 ---p 00020000 08:06
427943 /usr/local/grass-6.3.1svn/lib/libgrass_dgl.6.3.1svn.so
7f0c0136d000-7f0c0136e000 rw-p 00020000 08:06
427943 /usr/local/grass-6.3.1svn/lib/libgrass_dgl.6.3.1svn.so
7f0c0136e000-7f0c01379000 r-xp 00000000 08:06
427952 /usr/local/grass-6.3.1svn/lib/libgrass_dbmiclient.6.3.1svn.so
7f0c01379000-7f0c01578000 ---p 0000b000 08:06
427952 /usr/local/grass-6.3.1svn/lib/libgrass_dbmiclient.6.3.1svn.so
7f0c01578000-7f0c01579000 rw-p 0000a000 08:06
427952 /usr/local/grass-6.3.1svn/lib/libgrass_dbmiclient.6.3.1svn.so
7f0c01579000-7f0c0158c000 r-xp 00000000 08:06
428010 /usr/local/grass-6.3.1svn/lib/libgrass_dbmibase.6.3.1svn.so
7f0c0158c000-7f0c0178c000 ---p 00013000 08:06
428010 /usr/local/grass-6.3.1svn/lib/libgrass_dbmibase.6.3.1svn.so
7f0c0178c000-7f0c0178d000 rw-p 00013000 08:06
428010 /usr/local/grass-6.3.1svn/lib/libgrass_dbmibase.6.3.1svn.so
7f0c0178d000-7f0c017cc000 r-xp 00000000 08:06
428028 /usr/local/grass-6.3.1svn/lib/libgrass_vect.6.3.1svn.so
7f0c017cc000-7f0c019cc000 ---p 0003f000 08:06
428028 /usr/local/grass-6.3.1svn/lib/libgrass_vect.6.3.1svn.so
7f0c019cc000-7f0c019ce000 rw-p 0003f000 08:06
428028 /usr/local/grass-6.3.1svn/lib/libgrass_vect.6.3.1svn.so
7f0c019ce000-7f0c019d7000 r-xp 00000000 08:06
428024 /usr/local/grass-6.3.1svn/lib/libgrass_gproj.6.3.1svn.so
7f0c019d7000-7f0c01bd7000 ---p 00009000 08:06
428024 /usr/local/grass-6.3.1svn/lib/libgrass_gproj.6.3.1svn.so
7f0c01bd7000-7f0c01bd8000 rw-p 00009000 08:06
428024 /usr/local/grass-6.3.1svn/lib/libgrass_gproj.6.3.1svn.so
7f0c01bd8000-7f0c01be1000 r-xp 00000000 08:06
427949 /usr/local/grass-6.3.1svn/lib/libgrass_datetime.6.3.1svn.so
7f0c01be1000-7f0c01de1000 ---p 00009000 08:06
427949 /usr/local/grass-6.3.1svn/lib/libgrass_datetime.6.3.1svn.so
7f0c01de1000-7f0c01de2000 rw-p 00009000 08:06
427949 /usr/local/grass-6.3.1svn/lib/libgrass_datetime.6.3.1svn.so
7f0c01de2000-7f0c01e48000 r-xp 00000000 08:06
427997 /usr/local/grass-6.3.1svn/lib/libgrass_gis.6.3.1svn.so
7f0c01e48000-7f0c02047000 ---p 00066000 08:06
427997 /usr/local/grass-6.3.1svn/lib/libgrass_gis.6.3.1svn.so
7f0c02047000-7f0c0204a000 rw-p 00065000 08:06
427997 /usr/local/grass-6.3.1svn/lib/libgrass_gis.6.3.1svn.so
7f0c0204a000-7f0c0204f000 rw-p 7f0c0204a000 00:00 0
7f0c0204f000-7f0c02057000 r-xp 00000000 08:06
428036 /usr/local/grass-6.3.1svn/lib/libgrass_gmath.6.3.1svn.so
7f0c02057000-7f0c02256000 ---p 00008000 08:06
428036 /usr/local/grass-6.3.1svn/lib/libgrass_gmath.6.3.1svn.so
7f0c02256000-7f0c02257000 rw-p 00007000 08:06
428036 /usr/local/grass-6.3.1svn/lib/libgrass_gmath.6.3.1svn.so
7f0c02257000-7f0c0225c000 r-xp 00000000 08:06
428026 /usr/local/grass-6.3.1svn/lib/libgrass_vask.6.3.1svn.so
7f0c0225c000-7f0c0245b000 ---p 00005000 08:06
428026 /usr/local/grass-6.3.1svn/lib/libgrass_vask.6.3.1svn.so
7f0c0245b000-7f0c0245c000 rw-p 00004000 08:06
428026 /usr/local/grass-6.3.1svn/lib/libgrass_vask.6.3.1svn.so
7f0c0245c000-7f0c0245d000 rw-p 7f0c0245c000 00:00 0
7f0c0245d000-7f0c0246c000 r-xp 00000000 08:06
428035 /usr/local/grass-6.3.1svn/lib/libgrass_I.6.3.1svn.so
7f0c0246c000-7f0c0266b000 ---p 0000f000 08:06
428035 /usr/local/grass-6.3.1svn/lib/libgrass_I.6.3.1svn.so
7f0c0266b000-7f0c0266c000 rw-p 0000e000 08:06
428035 /usr/local/grass-6.3.1svn/lib/libgrass_I.6.3.1svn.so
7f0c0266c000-7f0c02674000 r-xp 00000000 08:06
2105908 /usr/lib/gdalplugins/gdal_GRASS.so
7f0c02674000-7f0c02874000 ---p 00008000 08:06
2105908 /usr/lib/gdalplugins/gdal_GRASS.so
7f0c02874000-7f0c02875000 rw-p 00008000 08:06
2105908 /usr/lib/gdalplugins/gdal_GRASS.so
7f0c02875000-7f0c02878000 r-xp 00000000 08:06
863301 /lib/libgpg-error.so.0.3.0
7f0c02878000-7f0c02a77000 ---p 00003000 08:06
863301 /lib/libgpg-error.so.0.3.0
7f0c02a77000-7f0c02a78000 rw-p 00002000 08:06
863301 /lib/libgpg-error.so.0.3.0
7f0c02a78000-7f0c02ac4000 r-xp 00000000 08:06
863545 /lib/libgcrypt.so.11.2.3
7f0c02ac4000-7f0c02cc3000 ---p 0004c000 08:06
863545 /lib/libgcrypt.so.11.2.3
7f0c02cc3000-7f0c02cc6000 rw-p 0004b000 08:06
863545 /lib/libgcrypt.so.11.2.3
7f0c02cc6000-7f0c02cd6000 r-xp 00000000 08:06
1776946 /usr/lib/libtasn1.so.3.0.12
7f0c02cd6000-7f0c02ed5000 ---p 00010000 08:06
1776946 /usr/lib/libtasn1.so.3.0.12
7f0c02ed5000-7f0c02ed6000 rw-p 0000f000 08:06
1776946 /usr/lib/libtasn1.so.3.0.12
7f0c02ed6000-7f0c02eee000 r-xp 00000000 08:06
1777046 /usAborted
ERROR: r.in.gdalwarp: gdalwarp failure.
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset
ERROR: Raster map <UK500_Bavaria.3> not found in current mapset

Hamish · June 15, 2008, 8:14am

Nikos Alexandris wrote:

[ I assume this has to again with variables, paths and
similar in which I still don't understand fully. Isn't there a
way to set this by default when installing GRASS (or gdaltools)? ]

I am not sure what you mean to set?
Did you compile/install gdal by hand or from distributed binary packages?

Under Ubuntu64bit I get some trouble with r.in.gdal
(actually gdalwarp):

r.in.wms mapserver="$SERVER" layer=UK500
out=UK500_Bavaria.3 format=tiff
Calculating tiles
Requesting 1 tiles.
Downloading tiles
Tile already downloaded
All tiles downloaded successfully
Creating output file that is 572P x 662L.
Processing input
file
/home/nik/grassdb/rlp_fgaps/wms_download/UK500_Bavaria.3__0.tiff.
Using band 4 of source image as alpha.
Using band 4 of destination image as alpha.
0...10...20...30...40...50...60...70...80...90...100 -
done.
*** glibc detected *** gdalwarp: double free or corruption
(!prev):
0x0000000000611a10 ***

this is a memory handling error in gdalwarp.
what version of GDAL?

you could try using gdalwarp by itself on the command line with the saved input file /home/nik/grassdb/rlp_fgaps/wms_download/UK500_Bavaria.3__0.tiff
and see how it goes? If that still fails, file a gdal bug.

======= Backtrace: =========
/lib/libc.so.6[0x7f0c0a3f308a]
/lib/libc.so.6(cfree+0x8c)[0x7f0c0a3f6c1c]
/usr/lib/libgdal1.5.0.so.1(_ZN17GDALDriverManagerD0Ev
+0x49)[0x7f0c0b121cc9]
gdalwarp[0x403441]
/lib/libc.so.6(__libc_start_main+0xf4)[0x7f0c0a39d1c4]
gdalwarp(GDALTermProgress+0xa1)[0x402a39]

(don't know)

ERROR: r.in.gdalwarp: gdalwarp failure.
ERROR: Raster map <UK500_Bavaria.3> not found in
current mapset

[...]

currently in r.in.wms I don't know how to test to see if r.in.gdalwarp failed (it is called with eval), and so the r.in.wms script continues on as if it always works.

Hamish

marisn · June 15, 2008, 9:27am

IIRC i had similar problem on Gentoo long time a go.
Nikos, first - check for two various GDAL installations (i.e. have You
single gdal installation or two);
Second - recompile GDAL and GRASS.

Maris.

Nikos_Alexandris1 · June 15, 2008, 3:07pm

On Sun, 2008-06-15 at 12:27 +0300, Maris Nartiss wrote:

IIRC i had similar problem on Gentoo long time a go.
Nikos, first - check for two various GDAL installations (i.e. have You
single gdal installation or two);
Second - recompile GDAL and GRASS.

Maris.

Hamish and Maris,

thank you for your concern.

I had 2 versions installed: one from Jachym's repo and another one from
FWTools. I removed yesterday everything and recompiled in the proper
order, added the proper lines in /etc/ld.so.conf (and some other detail
which I stole from Dylan's notes upon compilation).

It works now fine. Excuse me for the mail-traffic.

---

Jachym, does the gdalinfo (and other gdal-tools) work fine for you under
Ubuntu 64-bit? I always get a segfault error.

Thank you,

Nikos

Jachym_Cepicky · June 23, 2008, 10:48am

hi, sorry for beeing so still - I had something else to solve

anyway: I do not know, I'll check during next days

maybe you already found the solution?

j

2008/6/15 Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>:

On Sun, 2008-06-15 at 12:27 +0300, Maris Nartiss wrote:

IIRC i had similar problem on Gentoo long time a go.
Nikos, first - check for two various GDAL installations (i.e. have You
single gdal installation or two);
Second - recompile GDAL and GRASS.

Maris.

Hamish and Maris,

thank you for your concern.

I had 2 versions installed: one from Jachym's repo and another one from
FWTools. I removed yesterday everything and recompiled in the proper
order, added the proper lines in /etc/ld.so.conf (and some other detail
which I stole from Dylan's notes upon compilation).

It works now fine. Excuse me for the mail-traffic.

---

Jachym, does the gdalinfo (and other gdal-tools) work fine for you under
Ubuntu 64-bit? I always get a segfault error.

Thank you,

Nikos

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub