Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
It appears so. I'm going to look at the posts and see if I can get mine to work. Thanks, Mark On Tue, Nov 3, 2009 at 7:38 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Nov 3, 2009 at 1:32 PM, M S msei...@gmail.com wrote: I just installed from ubuntugis, and the package is grass_6.4.0~rc5-3~karmic1_amd64.deb, which I presume to be 64bit. I have problems compiling addons (using ubuntugis). Perhaps you are hit by this one: http://trac.osgeo.org/grass/ticket/620 Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
Markus, Based on http://lists.osgeo.org/pipermail/grass-user/2009-August/052074.html, is there a checklist of variables I can go through in the Platform.make file to change variable values to /usr/lib/grass64 ? Thanks, Mark On Tue, Nov 3, 2009 at 7:38 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Nov 3, 2009 at 1:32 PM, M S msei...@gmail.com wrote: I just installed from ubuntugis, and the package is grass_6.4.0~rc5-3~karmic1_amd64.deb, which I presume to be 64bit. I have problems compiling addons (using ubuntugis). Perhaps you are hit by this one: http://trac.osgeo.org/grass/ticket/620 Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Stranges things after importing a shapefile
NOTICE: This is a second mail, sent because I didn't pay attention to the size limit of this mailing list. I replaced the attached image by imagehack links. Hi all, While still working on my huge map of Europe, I've noticed many differences between the original shapefile and the grass vector layer created after import. To visualize the problem, I took two Screenshots: -First one is from gqis 1.01, showing the raw shapefile: http://img214.imageshack.us/img214/4884/qgis.png -Second one from grass 6.4RC5, showing the imported vector layer: http://img4.imageshack.us/img4/8462/grassgis.png Notice how many areas seem broken in the grass layer, and how entire parts of large rivers (take the rhine, for an example) are missing. The initial shapefile was patched together (from a few hundred nasa swbd tiles) using Markus Neteler's script (Thanks again Markus !), and seem to produce good results, at least in Qgis. The import command I used was: v.in.ogr -z -o dsn=/DATA/swbd/shp/tiles/coastlines.shp output=coastlines I somehow had to override the projection, because grass doesn't seem to recognize the projection of the shapefile - although both are of the same WSG84 LAT/LON proj. My question is: what went wrong ? Perhaps there is an import step I'm missing, since once the 'clean' command finishes, I get an awful lot of areas without a centroid; I don't know. But it would be nice, for sure, if grass could just translate the shapefile, as it is, and allow me to export a *complete* vector map to inkscape. Thanks for your help, Felix ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stranges things after importing a shapefile
Felix Schalck wrote: While still working on my huge map of Europe, I've noticed many differences between the original shapefile and the grass vector layer created after import. This (probably) means that grass (i.e. v.clean) did its job and corrected topological errors in the shapefile (?). To visualize the problem, I took two Screenshots: -First one is from gqis 1.01, showing the raw shapefile: http://img214.imageshack.us/img214/4884/qgis.png -Second one from grass 6.4RC5, showing the imported vector layer: http://img4.imageshack.us/img4/8462/grassgis.png Notice how many areas seem broken in the grass layer, and how entire parts of large rivers (take the rhine, for an example) are missing. Not so easy to see the differences. Maybe you could (next time) highlight them somehow. The initial shapefile was patched together (from a few hundred nasa swbd tiles) using Markus Neteler's script (Thanks again Markus !), and seem to produce good results, at least in Qgis. The import command I used was: v.in.ogr -z -o dsn=/DATA/swbd/shp/tiles/coastlines.shp output=coastlines I somehow had to override the projection, because grass doesn't seem to recognize the projection of the shapefile - although both are of the same WSG84 LAT/LON proj. My question is: what went wrong ? Maybe nothing went wrong ;-). Check the original shape(s) there where you can locate differences. Are there open polygons for example? Perhaps there is an import step I'm missing, since once the 'clean' command finishes, I get an awful lot of areas without a centroid; I don't know. But it would be nice, for sure, if grass could just translate the shapefile, as it is, and allow me to export a *complete* vector map to inkscape. If its only for visualisation purposes, I think you can avoid v.clean. Use: v.in.ogr with the flag -c Do not clean polygons (not recommended). Or maybe v.external? Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stranges things after importing a shapefile
Hi, I guess the broken areas in the grass topology have dangles inside. (zoom a broken area) use v.clean: -remove small areas and angles -delete dangles Hope it helps, Achim Νίκος Αλεξανδρής schrieb: Felix Schalck wrote: While still working on my huge map of Europe, I've noticed many differences between the original shapefile and the grass vector layer created after import. This (probably) means that grass (i.e. v.clean) did its job and corrected topological errors in the shapefile (?). To visualize the problem, I took two Screenshots: -First one is from gqis 1.01, showing the raw shapefile: http://img214.imageshack.us/img214/4884/qgis.png -Second one from grass 6.4RC5, showing the imported vector layer: http://img4.imageshack.us/img4/8462/grassgis.png Notice how many areas seem broken in the grass layer, and how entire parts of large rivers (take the rhine, for an example) are missing. Not so easy to see the differences. Maybe you could (next time) highlight them somehow. The initial shapefile was patched together (from a few hundred nasa swbd tiles) using Markus Neteler's script (Thanks again Markus !), and seem to produce good results, at least in Qgis. The import command I used was: v.in.ogr -z -o dsn=/DATA/swbd/shp/tiles/coastlines.shp output=coastlines I somehow had to override the projection, because grass doesn't seem to recognize the projection of the shapefile - although both are of the same WSG84 LAT/LON proj. My question is: what went wrong ? Maybe nothing went wrong ;-). Check the original shape(s) there where you can locate differences. Are there open polygons for example? Perhaps there is an import step I'm missing, since once the 'clean' command finishes, I get an awful lot of areas without a centroid; I don't know. But it would be nice, for sure, if grass could just translate the shapefile, as it is, and allow me to export a *complete* vector map to inkscape. If its only for visualisation purposes, I think you can avoid v.clean. Use: v.in.ogr with the flag -c Do not clean polygons (not recommended). Or maybe v.external? Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stranges things after importing a shapefile
Ok: you are right, the pictures I uploaded are not very useful; so I made another 4 screenshots, to show my problem: First Image: Rhine river, and swiss lakes in qgis (displaying the raw shapefile): http://img690.imageshack.us/img690/1144/swbdrhineqgis.png Second Image: (Approximately) Same region, after importation as GRASS vector, using v.in.ogr: http://img690.imageshack.us/img690/3850/swbdrhinegrass.png The middle-rhine just vanished over the process ! Also, notice that no lake is recognized as closed area (although zooming in shows no apparent dangles), and doesn't color. This is annoying, since I would mean a manual rework all lakes to show them properly in the final map. Third image: Zoom at the middl-Rhine, with Qgis: http://img442.imageshack.us/img442/1650/swbdrhineqgis2.png Forth image: (Approximately) Same region, after importation as GRASS vector: http://img266.imageshack.us/img266/6029/swbdrhinegrass2.png Obvious question: what happened to the river ? As explined, the shapefile are meant to serve as vector layer on my final topographic map; thus I'm using grass as middle-step, between qgis shapefile and inkscape. Im very interested in nikos' import-without-clean option: would this work out for me (eg: would it be possible to export the non-cleaned grass vector layer to svg) ? Thanks for your help, Felix ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stranges things after importing a shapefile
On Tue, 2009-11-10 at 17:50 +0100, Felix Schalck wrote: Ok: you are right, the pictures I uploaded are not very useful; so I made another 4 screenshots, to show my problem: First Image: Rhine river, and swiss lakes in qgis (displaying the raw shapefile): http://img690.imageshack.us/img690/1144/swbdrhineqgis.png Second Image: (Approximately) Same region, after importation as GRASS vector, using v.in.ogr: http://img690.imageshack.us/img690/3850/swbdrhinegrass.png The middle-rhine just vanished over the process ! Also, notice that no lake is recognized as closed area (although zooming in shows no apparent dangles), and doesn't color. This is annoying, since I would mean a manual rework all lakes to show them properly in the final map. Third image: Zoom at the middl-Rhine, with Qgis: http://img442.imageshack.us/img442/1650/swbdrhineqgis2.png Forth image: (Approximately) Same region, after importation as GRASS vector: http://img266.imageshack.us/img266/6029/swbdrhinegrass2.png Obvious question: what happened to the river ? Right, very clear. The problem is known. I might be missing something but, in general, I think my previous answer, and Achims suggestion, covers it. As explined, the shapefile are meant to serve as vector layer on my final topographic map; thus I'm using grass as middle-step, between qgis shapefile and inkscape. Im very interested in nikos' import-without-clean option: would this work out for me (eg: would it be possible to export the non-cleaned grass vector layer to svg) ? Yes (for a nice map but you won't be good for using this for analysis). Go ahead and try ;-) Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stranges things after importing a shapefile
It Works ! I used v.in.ogr -c command and now it looks pretty good: http://img25.imageshack.us/img25/6802/swbdgrass3.png Thanks you very much, Nikos. Now I got another problem: export to inkscape produce a way-to-big file, which I can't rework with my current system config (AMD64, 3Gb ram). Is it possible to do the job in grass, and produce a good-looking anti-aliased raster river layer, which I could simply layer over the topographic layer ? Is this doable with v.to.rast ? Thanks again for your help, Felix 2009/11/10 Νίκος Αλεξανδρής nikos.alexand...@felis.uni-freiburg.de: On Tue, 2009-11-10 at 17:50 +0100, Felix Schalck wrote: Ok: you are right, the pictures I uploaded are not very useful; so I made another 4 screenshots, to show my problem: First Image: Rhine river, and swiss lakes in qgis (displaying the raw shapefile): http://img690.imageshack.us/img690/1144/swbdrhineqgis.png Second Image: (Approximately) Same region, after importation as GRASS vector, using v.in.ogr: http://img690.imageshack.us/img690/3850/swbdrhinegrass.png The middle-rhine just vanished over the process ! Also, notice that no lake is recognized as closed area (although zooming in shows no apparent dangles), and doesn't color. This is annoying, since I would mean a manual rework all lakes to show them properly in the final map. Third image: Zoom at the middl-Rhine, with Qgis: http://img442.imageshack.us/img442/1650/swbdrhineqgis2.png Forth image: (Approximately) Same region, after importation as GRASS vector: http://img266.imageshack.us/img266/6029/swbdrhinegrass2.png Obvious question: what happened to the river ? Right, very clear. The problem is known. I might be missing something but, in general, I think my previous answer, and Achims suggestion, covers it. As explined, the shapefile are meant to serve as vector layer on my final topographic map; thus I'm using grass as middle-step, between qgis shapefile and inkscape. Im very interested in nikos' import-without-clean option: would this work out for me (eg: would it be possible to export the non-cleaned grass vector layer to svg) ? Yes (for a nice map but you won't be good for using this for analysis). Go ahead and try ;-) Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
Mark, On Tue, Nov 10, 2009 at 2:24 PM, M S msei...@gmail.com wrote: Markus, Based on http://lists.osgeo.org/pipermail/grass-user/2009-August/052074.html, is there a checklist of variables I can go through in the Platform.make file to change variable values to /usr/lib/grass64 ? Since I have no ubuntu I can only suggest to try (and to report back which didn't appear to happen in August). Sorry for no better answer (I still hope that a Makefile guru takes a look and fixes the missing pieces) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing addon problem for regular users (ubuntu newbies)
I'll try some things and report findings. With some guidance from a 'make guru', I'm would think this could be resolved. Thanks, Mark On Tue, Nov 10, 2009 at 3:33 PM, Markus Neteler nete...@osgeo.org wrote: Mark, On Tue, Nov 10, 2009 at 2:24 PM, M S msei...@gmail.com wrote: Markus, Based on http://lists.osgeo.org/pipermail/grass-user/2009-August/052074.html, is there a checklist of variables I can go through in the Platform.make file to change variable values to /usr/lib/grass64 ? Since I have no ubuntu I can only suggest to try (and to report back which didn't appear to happen in August). Sorry for no better answer (I still hope that a Makefile guru takes a look and fixes the missing pieces) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.terraflow
Hi Markus, I tried to apply the patch of r.terraflow. I do not know if I did it fine, what I did was to change the original include/iostream/ami_sort_impl.h file with the modifications in the .diff file. If this was fine, below is the output of r.terraflow which to me seems to give a different error as before. === GRASS 6.4.0RC5 (WGS84_UTM33):~ r.terraflow elevation=dem_tagliato filled=flood direction=flow swatershed=sink accumulation=accumulation tci=tci d8cut=infinity memory=1600 STREAM_DIR=/tmp stats=stats.out STREAM temporary files in /tmp (THESE INTERMEDIATE STREAMS WILL NOT BE DELETED IN CASE OF ABNORMAL TERMINATION OF THE PROGRAM. TO SAVE SPACE PLEASE DELETE THESE FILES MANUALLY!) MFD flow direction D8CUT=99986991104.00 Memory size: 1.56G (1677721600) bytes Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode. total elements=67071935, nodata elements=61864898 largest temporary files: FILL: 3.50G (3756028360) [67071935 elements, 56B each] FLOW: 397.27M (416562960) [5207037 elements, 80B each] Will need at least 7.00G (7512056720) space available in /tmp -- COMPUTING FLOW DIRECTIONS classifying nodata (inner boundary) EMPQUEUEADAPTIVE: starting in-memory pqueue EMPQUEUEADAPTIVE: available memory: 1597.93MB EMPQUEUEADAPTIVE: desired memory: 1597.93MB sz_stream: 270388 buf_arity: 200 mm_overhead: 8665728 mm_avail: 1675549602. EMPQUEUEADAPTIVE: memory overhead set to 8.26428MB EMPQUEUEADAPTIVE: pqsize set to 208360484 assigning preliminary directions finding flat areas (plateaus and depressions) EMPQUEUEADAPTIVE: starting in-memory pqueue EMPQUEUEADAPTIVE: available memory: 1597.41MB EMPQUEUEADAPTIVE: desired memory: 1597.41MB sz_stream: 270388 buf_arity: 200 mm_overhead: 8665728 mm_avail: 1675008754. EMPQUEUEADAPTIVE: memory overhead set to 8.26428MB EMPQUEUEADAPTIVE: pqsize set to 208292878 assigning directions on plateaus generating watersheds and watershed graph AMI_STREAM::write_item failed. /tmp/STREAM_HHSoQw: File too large r.terraflow: /usr/local/svn/grass/grass640_rc5/dist.i686-pc-linux-gnu/include/grass/iostream/ami_stream.h:560: AMI_err AMI_STREAMT::write_item(const T) [with T = compressedWaterWindowType]: Assertion `0' failed. Abortito GRASS 6.4.0RC5 (WGS84_UTM33):~ === Francesco Markus Neteler wrote: On Mon, Nov 9, 2009 at 1:24 PM, Francesco Mirabella mirab...@unipg.it wrote: Hi all, I am trying to get flow directions out of a dem (10m resolution). I have tried r.terraflow which gives me the error below: Can anyone tell me if I am doing something wrong and how can I solve this? many thanks Francesco -- GRASS 6.4.0RC5 (WGS84_UTM33):~ r.terraflow elevation=copia.dem filled=flood direction=flow swatershed=sink accumulation=accumulation tci=tci d8cut=infinity memory=300 STREAM_DIR=/tmp stats=stats.out STREAM temporary files in /tmp (THESE INTERMEDIATE STREAMS WILL NOT BE DELETED IN CASE OF ABNORMAL TERMINATION OF THE PROGRAM. TO SAVE SPACE PLEASE DELETE THESE FILES MANUALLY!) file stats.out exists - renaming. MFD flow direction D8CUT=99986991104.00 Memory size: 300.00M (314572800) bytes Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode. total elements=67071935, nodata elements=8624611 largest temporary files: FILL: 3.50G (3756028360) [67071935 elements, 56B each] FLOW: 4.35G (4675785920) [58447324 elements, 80B each] Will need at least 8.71G (9351571840) space available in /tmp -- COMPUTING FLOW DIRECTIONS classifying nodata (inner boundary) EMPQUEUEADAPTIVE: starting in-memory pqueue EMPQUEUEADAPTIVE: available memory: 297.929MB EMPQUEUEADAPTIVE: desired memory: 297.929MB sz_stream: 270388 buf_arity: 200 mm_overhead: 8665728 mm_avail: 312400802. EMPQUEUEADAPTIVE: memory overhead set to 8.26428MB EMPQUEUEADAPTIVE: pqsize set to 37966884 assigning preliminary directions finding flat areas (plateaus and depressions) file=/tmp/STREAM_rSqNkF:cannot read!: Bad address r.terraflow: /usr/local/svn/grass/grass640_rc5/dist.i686-pc-linux-gnu/include/grass/iostream/ami_sort_impl.h:91: size_t makeRun_Block(AMI_STREAMT*, T*, unsigned int, Compare*) [with T = plateauType, Compare = ijCmpPlateauType]: Assertion `err == AMI_ERROR_NO_ERROR || err == AMI_ERROR_END_OF_STREAM' failed. Abortito This is a known bug: http://trac.osgeo.org/grass/ticket/775 with a patch (r.terraflow.diff) to test. Perhaps you could try it and report back directly in the ticket? thanks Markus -- ** Francesco Mirabella, Geologia Strutturale e Geofisica Universita' di Perugia, Dipartimento di Scienze della Terra, Piazza Universita' 1, 06100
Re: [GRASS-user] r.terraflow
Hi Francesco, On Tue, Nov 10, 2009 at 12:34 PM, Francesco Mirabella mirab...@unipg.it wrote: Hi Markus, I tried to apply the patch of r.terraflow. I do not know if I did it fine, what I did was to change the original include/iostream/ami_sort_impl.h file with the modifications in the .diff file. such changes can be applied automatically: cd where/the/code/is/ patch -p0 difffile Sometimes it also needs to be applied from the main GRASS source code directory (just check if the path is in the diff file or not). If this was fine, below is the output of r.terraflow which to me seems to give a different error as before. === GRASS 6.4.0RC5 (WGS84_UTM33):~ r.terraflow elevation=dem_tagliato filled=flood direction=flow swatershed=sink accumulation=accumulation tci=tci d8cut=infinity memory=1600 STREAM_DIR=/tmp stats=stats.out STREAM temporary files in /tmp (THESE INTERMEDIATE STREAMS WILL NOT BE DELETED IN CASE OF ABNORMAL TERMINATION OF THE PROGRAM. TO SAVE SPACE PLEASE DELETE THESE FILES MANUALLY!) MFD flow direction D8CUT=99986991104.00 Memory size: 1.56G (1677721600) bytes Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode. total elements=67071935, nodata elements=61864898 largest temporary files: FILL: 3.50G (3756028360) [67071935 elements, 56B each] - are you on a 64 box? If on 32bit, did you compile GRASS with large file support? There will be the 2GB limit if not. FLOW: 397.27M (416562960) [5207037 elements, 80B each] Will need at least 7.00G (7512056720) space available in /tmp - space is there in /tmp/? -- COMPUTING FLOW DIRECTIONS ... generating watersheds and watershed graph AMI_STREAM::write_item failed. /tmp/STREAM_HHSoQw: File too large - /tmp full or 2GB file limit hit? Please check if you configured GRASS with --enable-largefile before compilation. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] importing HDF sea ice grid with unusual projection
On Thu, Nov 5, 2009 at 7:27 PM, Seb splu...@gmail.com wrote: Hi, I'm in the process of importing sea ice concentration data from: ftp://ftp-projects.zmaw.de/seaice/AMSR-E_ASI_IceConc I have chosen to use their HDF product because their Geotiff uses a WGS84 datum that results in up to 500 m error at the borders, according to their info files at the root of each subdirectory. The grids are not georeferenced, but they use the same grid that NSIDC does with the specifications given here: http://nsidc.org/data/docs/daac/nsidc0002_ssmi_seaice.gd.html Fortunately, there's an EPSG code (3411, for the northern hemisphere) for that projection. gdalinfo on the HDF file: ---cut here---start-- $ gdalinfo asi-n6250-20020619-v5i.hdf Driver: HDF4Image/HDF4 Dataset Files: asi-n6250-20020619-v5i.hdf Size is 1216, 1792 Coordinate System is `' Metadata: valid_range=0, 1 long_name=ASI Ice Concentration, 20020619, res: 6.25000, AMSR-E, ASI Version: 5.5i, missing data interpolated. Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 1792.0) Upper Right ( 1216.0, 0.0) Lower Right ( 1216.0, 1792.0) Center ( 608.0, 896.0) Band 1 Block=1216x82 Type=Float32, ColorInterp=Gray ---cut here---end Converting to GTiff for importing into GRASS, using the EPSG code and bounds in the NSIDC's info: ---cut here---start-- $ gdal_translate -of GTiff -a_srs EPSG:3411 -a_ullr -380 560 380 -560 asi-n6250-20020619-v5i.hdf asi-n6250-20020619-v5i.tif Warning 6: A dataset opened by GDALOpenShared should have the same filename (asi-n6250-20020619-v5i.hdf) and description (HDF4_SDS:UNKNOWN:asi-n6250-20020619-v5i.hdf:0) Input file size is 1216, 1792 0...10...20...30...40...50...60...70...80...90...100 - done. $ gdalinfo asi-n6250-20020619-v5i.tif Driver: GTiff/GeoTIFF Files: asi-n6250-20020619-v5i.tif Size is 1216, 1792 Coordinate System is: PROJCS[NSIDC Sea Ice Polar Stereographic North, GEOGCS[Unspecified datum based upon the Hughes 1980 ellipsoid, DATUM[Not_specified_based_on_Hughes_1980_ellipsoid, SPHEROID[Hughes 1980,6378273,298.279411123061, AUTHORITY[EPSG,7058]], AUTHORITY[EPSG,6054]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4054]], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,3411]] Origin = (-380.000,560.000) Pixel Size = (6250.000,-6250.000) Metadata: AREA_OR_POINT=Area valid_range=0, 1 long_name=ASI Ice Concentration, 20020619, res: 6.25000, AMSR-E, ASI Version: 5.5i, missing data interpolated. Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-380.000, 560.000) Lower Left (-380.000,-560.000) Upper Right ( 380.000, 560.000) Lower Right ( 380.000,-560.000) Center ( 0.000, 0.000) Band 1 Block=1216x1 Type=Float32, ColorInterp=Gray ---cut here---end So far so good, but when importing into a GRASS location: ---cut here---start-- r.in.gdal in=/home/sluque/tmp/asi-n6250-20020619-v5i.tif out=test location=Test WARNING: No projection name! Projection parameters likely to be meaningless. WARNING: Datum Not_specified_based_on_Hughes_1980_ellipsoid not recognised by GRASS and no parameters found Location Test created 100% r.in.gdal complete. Raster map test created. ---cut here---end What is missing here? I've also tried using the proj4 strings offered for that EPSG, but the results are the same. Any tips would be appreciated. I don't have much to add but also had problems to import some NSIDC maps. Perhaps this is relevant? http://trac.osgeo.org/gdal/ticket/2584 In general it is more a question for the GDAL folks since GRASS uses GDAL for import. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
