Re: [GRASS-user] GIS Manager, d.vect, and missing labels
On 14/01/09 02:51, Matt wrote: I've installed the MS-Windows version 6.3.0 on a Vista machine along with the NC datafiles. Page 170 of Neteler and Mitasova gives the example d.vect -c census_wake2000 disp=shape,attr attrcol=FIPSSTCO siz=5 lcol=black. It seems to me there are at least 3 ways to do this, and I can only get one of them to work. Any suggestions on why approaches 2 and 3 below don't work (at least for me)? 1) If I click the Add command layer icon of GIS Manager and type the example, it seems to execute properly. 2) If instead I click the Add vector layer icon of GIS Manager and try to fill in/select the proper commands, I can't get the labels to appear. Major settings are: Vector map: census_wake2...@permanent Display: Shapes Points Lines Boundaries Areas [...] Why do the labels not appear on the map? You also have to display centroids as attributes (and thus labels) are linked to centroids. Lastly 3) Typing the example into the bottom window of GIS.m and press ing the run button, the color map appears in the Map Display 1 window, but there are no labels, I find it surprising that you can actually display the map that way. I don't think that should be possible. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Why v.extract produces columns of type CHARACTER?
Nikos Alexandris wrote: The columns produces by v.extract are of type CHARACTER and v.dissolve does not like this. It's an old issue. Can someone explain why it becomes CHARACTER since grass' type for strings is varchar? Regards, Nikos Sorry, wrong question - false alarm. Actually, the *real* question I have asked in the past but never really got a reply is: why sqlitebrowser reports the columns as varchar while db.describe reports (in grass-shell) the same columns to be of type CHARACTER? GRASS' DBMI doesn't distinguish CHARACTER from CHARACTER VARYING (aka VARCHAR); the constant DB_SQL_TYPE_CHARACTER is used for both (although there is also DB_SQL_TYPE_TEXT for TEXT). Also, SQLite doesn't really have column types; it assigns types to individual values rather than to columns. Columns may have a type of SQLITE_INTEGER, SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB or SQLITE_NULL, but it doesn't actually require that the values' types conform to the type. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Why v.extract produces columns of type CHARACTER?
On Wed, Jan 14, 2009 at 5:02 PM, Glynn Clements gl...@gclements.plus.com wrote: Nikos Alexandris wrote: The columns produces by v.extract are of type CHARACTER and v.dissolve does not like this. It's an old issue. Can someone explain why it becomes CHARACTER since grass' type for strings is varchar? Regards, Nikos Sorry, wrong question - false alarm. Actually, the *real* question I have asked in the past but never really got a reply is: why sqlitebrowser reports the columns as varchar while db.describe reports (in grass-shell) the same columns to be of type CHARACTER? GRASS' DBMI doesn't distinguish CHARACTER from CHARACTER VARYING (aka VARCHAR); the constant DB_SQL_TYPE_CHARACTER is used for both (although there is also DB_SQL_TYPE_TEXT for TEXT). Also, SQLite doesn't really have column types; it assigns types to individual values rather than to columns. Columns may have a type of SQLITE_INTEGER, SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB or SQLITE_NULL, but it doesn't actually require that the values' types conform to the type. A bit off-topic. Does this mean I can actually edit vector data attributes as text even if the column is an INTEGER? I'm using Sqlite database browser for editing. A bit dangerous for me. Any other way to add checks/controls for editing mistakes? -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] r3.in.ascii - Difficulties understanfing format
Nikos, Thanks very much for the 101 on rasters in Grass, helped me out big time. No worries on the length of the answer, the more the better ;) Tom -Original Message- From: Nikos Alexandris [mailto:nikos.alexand...@felis.uni-freiburg.de] Sent: dinsdag 13 januari 2009 16:50 To: t...@vdputte.nl Cc: grass-user Subject: Re: [GRASS-user] r3.in.ascii - Difficulties understanfing format Tom, my apologies for writing something long, and repeat within the text some times things already mentioned or known. I did so on purpose -- just to practice and see if I understand the concept myself. Ah, please keep in your posts Cc to the grass-user mailing list. Others will definitely benefit from our mistakes or the correct examples we discuss. On Tue, 2009-01-13 at 15:13 +0100, t...@vdputte.nl wrote: Hi Nikos, Thanks for the quick response! So what I gather from your answer is that the region-definitions are set seperately (I'm guessing in the mapset?) and that you can only display data that falls within the boundaries of this region? Correct. Just to make the big picture clear: Location = One coordinate system Many mapsets with separate region settings for each. In addition, an important and very useful characteristic of GRASS' raster modules (r.*) is that they operate *only* within the defined region. The my problem transforms a bit,in the sense that I want to display a 3D array/raster. Ultimately, this needs to be georeferenced, but for testing purposes I just want to display this raster in Nviz. So how can I create a general Mapset in which I can display a 3D raster with a resolution of 1 (e.g North-South, E-W and T-B all 3 - 0 with a raster of 3x3x3) If you have non-georeferenced spatial data you can create a generic XY location and set the region to match the extent of your imported (in the xy location) raster no-matter how big/small it is. [see [1][2] and search on the mailing list [3] for how to create an xy location -- it's a standard question when one starts to explore data with grass] # set region g.region rast=YourRaster -p # or: g.region rast=YourRaster -pa ## read g.region help for more It should, I think, obtain automatically the required rows columns parameters which should correspond to the columns rows of your raster. If not just grab the resolution of your raster somehow (e.g. gdalinfo YourRaster) and set them manually. I think that south north should match columns rows. east west are irrelevant and, I think, you can set the latter to 0. Hmmm... talking about 3D I think the correct term is voxels, and hence you can set the vertical resolution to 1 as well. But you can experiment with whatever you think you need... The important, in order to *see* your data is here the (x=)columns, (y=)rows and (z=)levels. Now, the *how* they will appear will be affected by the defined x,y,z resolution. Since the units in an XY location are pixels it's correct to set the resolution to 1. A few more notes concerning georeferenced maps/locations While the resolution of the georeferenced map itself is as is (let's say you have the CORINE land cover of some European country, the raster version of 250m pixel size), and refers to the units used by the defined coordinate system, the resolution you define with g.region will affect the output of most raster processing modules. # corine_250m # match region-extent to the corine_250m map g.region rast=corine_250 res=500 -pa # produce a 500m corine map r.mapcalc corine_500m=corine_250m # so simple ;-) I hope you understand my problem. Thanks, Tom [...] I hope I helped you with my bla-bla. Cheers, Nikos --- [1] http://grass.itc.it/grass62/manuals/html62_user/helptext.html [2] http://n2.nabble.com/Re% 3A-GRASS-user--Help-with-reprojection-td2104056.html#a2107019 [3] http://n2.nabble.com/Grass---Users-f1837860.html Geen virus gevonden in het binnenkomende-bericht. Gecontroleerd door AVG - http://www.avg.com Versie: 8.0.176 / Virusdatabase: 270.10.6/1888 - datum van uitgifte: 12-1-2009 7:04 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Why v.extract produces columns of type CHARACTER?
On 14/01/09 10:19, maning sambale wrote: On Wed, Jan 14, 2009 at 5:02 PM, Glynn Clements gl...@gclements.plus.com wrote: Nikos Alexandris wrote: The columns produces by v.extract are of type CHARACTER and v.dissolve does not like this. It's an old issue. Can someone explain why it becomes CHARACTER since grass' type for strings is varchar? Regards, Nikos Sorry, wrong question - false alarm. Actually, the *real* question I have asked in the past but never really got a reply is: why sqlitebrowser reports the columns as varchar while db.describe reports (in grass-shell) the same columns to be of type CHARACTER? GRASS' DBMI doesn't distinguish CHARACTER from CHARACTER VARYING (aka VARCHAR); the constant DB_SQL_TYPE_CHARACTER is used for both (although there is also DB_SQL_TYPE_TEXT for TEXT). Also, SQLite doesn't really have column types; it assigns types to individual values rather than to columns. Columns may have a type of SQLITE_INTEGER, SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB or SQLITE_NULL, AFAIK, columns can have any type, even ones invented by you. I.e. create table test (key int, chartest ThisIsMyTextType); works in sqlite, where works means that sqlite just ignores the column type and automatically affects a type amongst the ones listed by Glynn to each value. but it doesn't actually require that the values' types conform to the type. A bit off-topic. Does this mean I can actually edit vector data attributes as text even if the column is an INTEGER? I'm using Sqlite database browser for editing. A bit dangerous for me. Yes. I find SQLite a bit dangerous because of that, especially since GRASS enforces types. Any other way to add checks/controls for editing mistakes? IMHO, the best way to deal with attributes in GRASS + SQLite is to do it via the built-in tools in GRASS, and not via the SQLiteBrowser or other tools as this can lead to incompatibilities and confusion. The new wxgui has a very nice interface for attribute and table management. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Why v.extract produces columns of type CHARACTER?
IMHO, the best way to deal with attributes in GRASS + SQLite is to do it via the built-in tools in GRASS, and not via the SQLiteBrowser or other tools as this can lead to incompatibilities and confusion. The new wxgui has a very nice interface for attribute and table management. Ahh! Thanks for the tip. I haven't really used GRASS GUI apart from the quick d.mon, d.vect, d.rast. I guess now is the time to tryout wxgui. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] DEM export to GeoTiff
Hello list,I have a problem with exporting a DEM to *tif.In a first step I import it via r.in.gdal and in a second step I export it with r.out.gdal and the file is not the same anymore. GDAL reduce the file to one pixel but a greater storage size.Even the settings (tags) changes total.Here are some extracts from gdalinfo:Before:Driver: GTiff/GeoTIFF Size is 108, 84 Coordinate System is: PROJCS[WGS 84 / UTM zone 45N, [...] Band 1 Block=64x64 Type=UInt16, ColorInterp=Gray Computed Min/Max=4349.000,5738.000 [EOF] After:Driver: GTiff/GeoTIFF Size is 1, 1 Coordinate System is: PROJCS[WGS 84 / UTM zone 45N, [...] Band 1 Block=1x1 Type=UInt16, ColorInterp=Palette Computed Min/Max=0.000,0.000 NoData Value=-32768 Metadata: COLOR_TABLE_RULES_COUNT=1 COLOR_TABLE_RULE_RGB_0=4.349000e+03 5.738000e+03 0 0 0 255 255 255 Color Table (RGB with 65536 entries) 0: 0,0,0,255 1: 0,0,0,255[and 65533 more lines ...] I mean it is a very simple process (import/export) but it don't work on my computer satisfactorily. So what I'm doing wrong?Kind regards,Stefan __ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM export to GeoTiff
On 14/01/09 16:49, Stefan Mietke wrote: Hello list, I have a problem with exporting a DEM to *tif. There's been quite a lot of discussion on the lists concerning r.out.gdal to GeoTiffs. See for example [1],[2] and the long thread in the relevant track ticket[3]. Several of the issues (notably the color table) have been addressed by recent changes which should be in the 6.4 release candidate. So you might want to try with that. In a first step I import it via r.in.gdal and in a second step I export it with r.out.gdal and the file is not the same anymore. GDAL reduce the file to one pixel but a greater storage size.. As mentioned in [1], block size only seems to be relevant for tiles. What exactly is the problem ? I mean, except for the fact that the files are not identical, what is going wrong for you ? Moritz [1] http://thread.gmane.org/gmane.comp.gis.gdal.devel/16395 [2] http://thread.gmane.org/gmane.comp.gis.grass.user/25084 [3] http://trac.osgeo.org/grass/ticket/73 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM export to GeoTiff
Thank you, for your quik response.The problem is, that the data is unusable after importing/exporting them ...There is only 1 pixel left of the original DEM and all elevation data are missing! __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GIS Manager, d.vect, and missing labels
I've installed the MS-Windows version 6.3.0 on a Vista machine along
with the NC datafiles. Page 170 of Neteler and Mitasova gives the
example
d.vect -c census_wake2000 disp=shape,attr attrcol=FIPSSTCO siz=5 lcol=black.
It seems to me there are at least 3 ways to do this, and I can only
get one of them to work. Any suggestions on why approaches 2 and 3
below don't work (at least for me)?
1) If I click the Add command layer icon of GIS Manager and type the
example, it seems to execute properly.
2) If instead I click the Add vector layer icon of GIS Manager and
try to fill in/select the proper commands, I can't get the labels to
appear. Major settings are:
Vector map: census_wake2...@permanent
Display: Shapes Points Lines Boundaries Areas
Point symbols: baskic/circle Size: 5
Draw lines: color=black width=1pixel
Fill areas= Random colors
Lable vectors checked, text color=black, text size=5
Label part to align with vector point: left, Justification: center
Layer for labels: 1 Attribute col for labels: FIPSSTCO
Clicking either the Display active layers icon or Redraw all
layers icon draws the colored map, BUT does not draw the labels.
Output in GIS.m is:
d.vect map=census_wake2...@permanent -c color=0:0:0 lcolor=0:0:0
fcolor=170:170:170 display=shape,attr type=point,line,boundary,area
icon=basic/circle size=5 layer=1 {att=FIPSSTCO} lsize=5 xref=left
yref=center llayer=1
Why do the labels not appear on the map?
Lastly
3) Typing the example into the bottom window of GIS.m and press ing
the run button, the color map appears in the Map Display 1 window, but
there are no labels,
What am I doing wrong?
Thanks,
Matt
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Matt
I had the same problem but stumbled upon the centroid solution. Have you had
any problems creating thematic (graduated point, line or colour) layers and
having them draw in the map display? I am also using WinGRASS 6.3 on Vista
and have not been able to make this work properly. The layer simply does not
draw when applying the thematic map layer. Let me know if you have had any
problem with this issue.
Regards,
Kenneth
--
View this message in context:
http://n2.nabble.com/GIS-Manager%2C-d.vect%2C-and-missing-labels-tp2154712p2160286.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GIS Manager, d.vect, and missing labels
Thanks - centroids did the trick. I don't know what else I did to make me think approach 3 worked. You of course are correct, it doesn't work. How do you know which commands will work from the lower window of GIS.m, and which commands will not work from that window? On Wed, Jan 14, 2009 at 3:49 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 14/01/09 02:51, Matt wrote: I've installed the MS-Windows version 6.3.0 on a Vista machine along with the NC datafiles. Page 170 of Neteler and Mitasova gives the example d.vect -c census_wake2000 disp=shape,attr attrcol=FIPSSTCO siz=5 lcol=black. It seems to me there are at least 3 ways to do this, and I can only get one of them to work. Any suggestions on why approaches 2 and 3 below don't work (at least for me)? 1) If I click the Add command layer icon of GIS Manager and type the example, it seems to execute properly. 2) If instead I click the Add vector layer icon of GIS Manager and try to fill in/select the proper commands, I can't get the labels to appear. Major settings are: Vector map: census_wake2...@permanent Display: Shapes Points Lines Boundaries Areas [...] Why do the labels not appear on the map? You also have to display centroids as attributes (and thus labels) are linked to centroids. Lastly 3) Typing the example into the bottom window of GIS.m and press ing the run button, the color map appears in the Map Display 1 window, but there are no labels, I find it surprising that you can actually display the map that way. I don't think that should be possible. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A list= option for v.overlay?
On Thu, 2009-01-15 at 10:16 +1100, Richard Chirgwin wrote: [...] Unfortunately, even the following Segfaults. # step 1: split in separate vector maps all samples, e.g. boxes of 40.000m x 40.000m for x in `v.category box_4 option=print | sort -nu | grep -v /`; do v.extract in=box_4 list=$x out=box_sample_4_$x; done # step 2: intersection of each separate box_sample with corine for x in `g.mlist type=vect pat=box_sample*`; do v.overlay ainput=corine binput=$x operator=and out=corine_box_sample_$x; done The result after several minutes of processing is Segmentation fault :-( So, the only way is to do this job per smaller CORINE-blocks? Nikos, You might try inserting a v.build between steps 1 and 2. It will slow down the process, but I found in a similar 'bulk overlay' exercise that this improved the stability of the process. Richard Thanks for the extra hint :-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Buffer overflow v.in.ogr on GRASS 6.4 RC2
On Wed, 2009-01-14 at 23:24 +0100, wout bijkerk wrote: I just checked something that came to my mind pondering the problem NIkos encountered (see thread Problem importing/viewing a ~160MB shapefile): When I import a polygonshape without making an attribute table (-t option), then the shape gets imported without a problem. But as soon as I import the same shape with the default of making the attribute table, then v.in.ogr gives a buffer overflow. Which is exactly the same problem Nikos had importing a big shape. Any ideas? Greetings, Wout Hi Wout! I want to make clear that the buffer overflow was caused due to the use of, I suppose, incompatible libraries ([1] taken from [2]). Using a newer gdal version fixed this. I never really tried the -t option. But I feel I have to (re-)state the problem I was facing: the import process was NOT failing, nor self-killed by the system. It was running and, I guess, it was just taking *too* long and this is why *I* killed/was killing the process. I never really let it go as much as possible to see what happens. As Hamish suggests (first reply on my post back then), it will probably reach its destination if I'll let it run all the way. In my case, it is about a coastline dataset with 9764427 vertices. Kind regards, Nikos [1] copy-pasted from [2] --- Attemp 1 # using gdal 1.5.3, grass6_devel # import shapefile v.in.ogr dsn=... out=... # buffer overflow error (or segfault --- I can't recall). Attemp 2 # using gdal-1.6.0beta2, grass6_devel # importing the usual way v.in.ogr dsn=coastlines.shp out=coastlines_longtime -ew --o Projection of input dataset and current location appear to match Layer: coastlines WARNING: Column name changed: 'AREA' - 'area' WARNING: Column name changed: 'PERIMETER' - 'perimeter' [...] [2] http://n2.nabble.com/Problem-importing-viewing-a-~160MB-shapefile-tt1886478.html#a1886480 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display thematic vector map - WinGRASS 6.3 (Vista)
Ken, You are not alone. I tried the thematic vector example on page 171 of Neteler Mitasova and also encountered the You must open a display monitor message. I'm running 6.3.0-4 on Vista. Matt On Tue, Jan 6, 2009 at 12:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/01/09 17:51, Michael Barton wrote: Thanks for the correction. WinGRASS supports PNG output, not a monitor. d.vect.thematic was rewritten to use direct rendering through PNG, so it should work on Windows. This was done in 6.4, so it is not available in winGRASS, yet, which is based on 6.3. Just replacing the script doesn't work, either as it use the fs= parameter of v.db.connect which wasn't introduced until 6.4. So, another strident call for the a 6.4 winGRASS. Moritz ___ 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] GIS Manager, d.vect, and missing labels
Matt wrote: 3) Typing the example into the bottom window of GIS.m and press ing the run button, the color map appears in the Map Display 1 window, but there are no labels, I find it surprising that you can actually display the map that way. I don't think that should be possible. I don't know what else I did to make me think approach 3 worked. You of course are correct, it doesn't work. How do you know which commands will work from the lower window of GIS.m, and which commands will not work from that window? Display (d.*) commands will work insofar as they will generate an image file, but they won't cause the resulting image to be displayed in the GUI. However, as you can't set environment variables from the command window, you won't be able to control where the image file is created, its format, size, etc. If you want to view the output from a specific display command in the GUI, create a command layer (the gear icon). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display thematic vector map - WinGRASS 6.3 (Vista)
I'm pretty sure that this is a Vista issue, though one that has been solved in 6.4. Michael On Jan 14, 2009, at 7:33 PM, Matt wrote: Ken, You are not alone. I tried the thematic vector example on page 171 of Neteler Mitasova and also encountered the You must open a display monitor message. I'm running 6.3.0-4 on Vista. Matt On Tue, Jan 6, 2009 at 12:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/01/09 17:51, Michael Barton wrote: Thanks for the correction. WinGRASS supports PNG output, not a monitor. d.vect.thematic was rewritten to use direct rendering through PNG, so it should work on Windows. This was done in 6.4, so it is not available in winGRASS, yet, which is based on 6.3. Just replacing the script doesn't work, either as it use the fs= parameter of v.db.connect which wasn't introduced until 6.4. So, another strident call for the a 6.4 winGRASS. Moritz ___ 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
