[GRASS-de] d.zoom / v.in.shape / r.in.gdal

[Ingo Wichmann]

Otto Dassau schrieb:
> oder erstmal ein v.support auf deine Vektorkarte machen. (Aufbau der
> Topologie)...

Hab sicherheitshalber mal sowohl v.support als auch r.support 
aufgerufen. Wirkt Wunder! Kaum macht man's richtig, funktionierts.

>>Die Rasterdaten werden in einer Qualität angezeigt, das man schon
>>Fantasie braucht um das Orginal daraus zu erkennen. In gimp sehen die
>>TIFFs noch gut aus.
> 
> Da gibt es eigentlich nur 2 Moeglichkeiten. 
> 
> a) Die momentane "resolution" deiner mapset ist zu gering, 
GRASS:~/dpa/grassdata > g.region -p
...
nsres:      0.1
ewres:      0.1

GRASS:~/dpa/grassdata > r.info map=461201GS
...
|   Type of Map:  raster              Number of Categories: 1 
       |   Data Type:    CELL 
              |   Rows:         6299 
                     |   Columns:      6299 
                            |   Total Cells:  39677401 
                                   |        Projection: UTM (zone 32) 
                                          |            N: 5696000.15875 
    S: 5694000.22625   Res: 0.3175               |            E: 
3409999.77375    W: 3407999.84125   Res: 0.3175               |   Range 
of data:    min =  0 max = 1

Irgendwo hab ich mal Meter als Einheit eingestellt. Also sollte die 
Auflösung nach meinem Verständnis bei 0,1 m = 10 cm liegen. Sollte also 
ausreichen, einen Gullideckel zu erkennen. Das Orginal ist die Deutsche 
Grundkarte, also 1:5000.

> b) oder die original Aufloesung deiner importierten Karte ist zu gering. 

gimp sagt: 6299 x 6299 Pixel, genau wie oben r.info.

> Das kannst du pruefen mit:  g.region rast=karte -p
> 
> Dann zeigt dir GRASS, welche Aufloesung die Karte in GRASS besitzt. 
> 
> 
>>r.in.gdal -oe in=../shape_files_is/461201GS.TIF out=461201GS
> 
> mit dem flag -o wird nicht die Karten sondern die Projektion 
> der Location benutzt (auch momentane Aufloesung) 
> -> vielleicht lieber weglassen, wenn die Aufloesung der 
> Ausgangskarte ok ist.

Das habe ich vorher auch gemacht. Dabei gibts folgende Fehlermeldung:

GRASS:~/dpa/grassdata > r.in.gdal -e in=../shape_files_is/461201GS.TIF 
out=461201GS-2
ERROR: Projection of dataset does not appear to match current location.
        cellhd.proj = 0 (unreferenced)
        You can use the -o flag to r.in.gdal to override this check.

Jetzt habe ich es mal mit
GRASS:~/dpa/grassdata > r.in.gdal in=../shape_files_is/461201GS.TIF 
out=461201GS-2 location=test
probiert, damit es nicht an der LOCATION liegen kann. Das Ergebnis ist 
das selbe :-(

>>Und dann noch: Was ist mit den übrigen Dateien strasse.avl, strasse.sbx
>>und strasse.sbn? Kann ich die mit irgendwas einlesen?
>  wurden. Sie sind aber nicht notwendig, und koennen theotetisch auch
> geloescht
>  werden, um das Shape nach GRASS zu importieren - so weit ich weiss....

O.K.

>>So, nach soviel Fragerei noch was positives: das Einlesen der
>>Vektordaten klappt sehr gut. Dadurch, daß die einzelnen Shapes
>>durchnummieriert sind kann ich mir von einem Skript auch mehrere
>>Attribute zu einer angeklickten Linie anzeigen lassen. Das hilft mir
>>schon sehr gut bei der Orientierung in den Daten.
> 
> Das verstehe ich nicht, :-(

Äh, war wohl etwas aus dem Zusammenhang gerissen...
Grass 5.0 kann ja immer nur ein Attribut pro Linie speichern. In den 
shape-Files hängen aber mehrere Attribute an einer Linie. Um die 
anzeigen zu können habe ich als Attribut die ShapeID gespeichert. Um den 
Aufruf von d.what.vect herum habe ich ein Perlskript geschrieben, daß 
die ShapeID aus der Ausgabe von d.what.vect einliest und die 
entsprechenden weiteren Attribute ausgibt. Daraus kann ich schon mal 
sehen, welche Linie zu welchem Straßennamen gehört usw.

Viele Grüße,

Ingo