[GRASS-user] Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Dear friend, I am compiling and installing grass on windows. But getting error as follows. Runtime error! Program: C:\Osgeo4w\bin\python.exe R6034 An application has made an attempt to load the c runtime library incorrectly. Please help me how can i resolve the issues. regards. Sandip ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: two questions on setting a new layer for for a vector
On 22/11/11 08:44, G. Allegri wrote: I've solved my needs about the creation of a new layer, but I feel that the mechanism a bit counter-intuitive. A new layer can be created *only* through an intemediary vector v.category input=rivers output=rivers_tmp layer=2 g.remove vect=rivers g.rename vect=rivers_tmp,rivers Directly creating a new connection on a new layer produces the new layer, but the categories are not attached: v.db.connect map=rivers table=rivers_clone layer=2 and the vector *seems* to have a new layer, but it cannot be used. I see the same results if I create a new layer through the wxGUI (vector attributes window - new layer). A new layer is shown, but it cannot be used (eg cannot be displayed). I will open a ticket on this. Please note that this is not a bug, but apparently a misunderstanding of how the layer mechanism works. Layers are not a database connection tool. The closest I can get in terms of a short definition of layers is that they are a tool for thematically grouping objects in a vector map. For example, you can have a series of field boundaries in a map and none of them have a category value in layer 1 as layer 1 is 'fields' and the category values of fields (= polygons) are with the centroids. However, if some of these boundary lines are also hiking paths, you can give them category numbers in layer 2 and thus layer 2 becomes the thematic layer hiking paths. Another example would be weather stations for which you have a whole battery of measures every day and instead of putting them all into one attribute table, you wish to have one table per day. You could then create one layer per day and each station would then have to have a category number in each layer. Any layer can, but does not have to, be connected to an attribute table. For any element in the map which has a category number in that layer, the system will then look into the attribute table and search for this category number in the key column. If that category number is not present in that column, then there are no attributes for that element. So: - You create a link between a layer and a table, but if no element in the map has a category value in that layer, then your link is useless. In other words, a layer only makes sense when you actually give category values to elements in your map in that layer. - Layers can be useful without tables, and so one probably should see these two concepts (layers and database connections) as separate, though obviously linked. The fact that v.category creates a new map with the results of the manipulation of the category values is probably a welcome security. If you delete all your category values by accident (e.g. you forget to specify the type when you want to delete category values from boundaries, but not centroids), the fact that the result is a new map reduces the chances for catastrophe. If you a sure that you will never make a mistake, you can always script the two steps (no need for the g.remove): v.category input=rivers output=rivers_tmp layer=2 g.rename vect=rivers_tmp,rivers --o I agree that it would be helpful to have an opion in v.category to copy the values from one layer to another (i.e. something like option=copy layer=2 sourcelayer=1). Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Hello, after a quick google-search: It seems an Error related to the MSVCR80.DLL. AFAIK this .dll comes with the libtiff via the osgeo4w setup. Which version of libtiff do you have installed (check in the osgeo4w advanced setup)? But maybe some others have any other idea!? /Johannes Original-Nachricht Datum: Mon, 28 Nov 2011 15:49:14 +0530 Von: Sandip Maity sandip.stesa...@gmail.com An: grass-user@lists.osgeo.org Betreff: [GRASS-user] Runtime error! / Program: C:\\Osgeo4w\\bin\\python.exe Dear friend, I am compiling and installing grass on windows. But getting error as follows. Runtime error! Program: C:\Osgeo4w\bin\python.exe R6034 An application has made an attempt to load the c runtime library incorrectly. Please help me how can i resolve the issues. regards. Sandip -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Joining vectors by location
Hi Richard, What do you get if you run db.connect -p in the relevant mapset? Here's my output: GRASS 6.4.2RC2 (EPSG:3857 - Pseudo-Mercator):~ db.connect -p driver:pg database:host=localhost,dbname=isis_db_extern schema: group: Seems to be okay, right? In any case, the last spatial join try worked the way I wanted it to, completely in GRASS :) Best, Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Dear Johannes, I have installed libtiff 4.0.0dev-91 via osgeo4w setup. Please suggest the way. Regards. Sandip On Mon, Nov 28, 2011 at 4:42 PM, Johannes Radinger jradin...@gmx.at wrote: Hello, after a quick google-search: It seems an Error related to the MSVCR80.DLL. AFAIK this .dll comes with the libtiff via the osgeo4w setup. Which version of libtiff do you have installed (check in the osgeo4w advanced setup)? But maybe some others have any other idea!? /Johannes Original-Nachricht Datum: Mon, 28 Nov 2011 15:49:14 +0530 Von: Sandip Maity sandip.stesa...@gmail.com An: grass-user@lists.osgeo.org Betreff: [GRASS-user] Runtime error! / Program: C:\\Osgeo4w\\bin\\python.exe Dear friend, I am compiling and installing grass on windows. But getting error as follows. Runtime error! Program: C:\Osgeo4w\bin\python.exe R6034 An application has made an attempt to load the c runtime library incorrectly. Please help me how can i resolve the issues. regards. Sandip -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Runtime error! / Program: C:\Osgeo4w\bin\python.exe
I have installed libtiff 4.0.0dev-91 via osgeo4w setup. please choose libtiff 4.0.0dev-90 Helmut -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Runtime-error-Program-C-Osgeo4w-bin-python-exe-tp7038211p7038597.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
[GRASS-user] Problem with g.region in lat-lon projection
Hi, I am trying to set up a grid with a specified resolution using g.region. The information about the grid that came with the data that I want to plot is: X grid origin:0.2812500 Y grid origin:-89.81250 X grid size: 640 Y grid size: 480 X grid resolution:0.5625000 Y grid resolution:0.375 I set up the grid with the following command: GRASS 6.4.1 (global_ll_wgs84):~/NAME/G2011 g.region w=0.2812500 s=-89.81250 cols=640 rows=480 ewres=0.562500 nsres=0.375 I would expect this grid to cover the whole globe (e.g. 640*0.5625=360), but instead it just generates a thin strip, and the ewres is too small. GRASS 6.4.1 (global_ll_wgs84):~/NAME/G2011 g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 74N south: 89:48:45S west: 0:16:52.5E east: 24E nsres: 0:20:28.59375 ewres: 0:02:13.417969 rows: 480 cols: 640 cells: 307200 Where am I going wrong? John -- Dr John A Stevenson RSE/Scottish Government Personal Research Fellow (co-funded by Marie Curie Actions) School of GeoSciences The University of Edinburgh Grant Institute West Mains Road Edinburgh EH9 3JW Scotland PHONE: (+44) 131 650 7526 FAX: (+44) 131 668 3184 email: john.steven...@ed.ac.uk web: http://www.geos.ed.ac.uk/homes/jsteven5 blog: http://all-geo.org/volcan01010 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Proposed patch: v.category option to copy category values from one layer to another [was: Re: [GRASS-user] Re: two questions on setting a new layer for for a vector]
On 28/11/11 11:28, Moritz Lennert wrote: I agree that it would be helpful to have an opion in v.category to copy the values from one layer to another (i.e. something like option=copy layer=2 sourcelayer=1). I just filed an enhancement request with a proposed patch implementing this (http://trac.osgeo.org/grass/ticket/1498). The proposed implementation works as follows: v.category roadsmajor option=transfer layer=1,2 out=roadsmajor_with_2_layers It would be great if anyone could test it and if one of the devs could have a look at the patch and either apply it directly, or tell me that it's ok to do so. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Hi, Maybe that is causing the problem (as it did in my case!) Via the advanced setup you can you can choose 4.0.0dev-90. This works in my case. But you have to be careful then with the make (the one you installed manually) this can be updated and overwritten by the osgeo4w setup with the old version 3.7 again. In that case you have to set to libtiff 4.0.0dev-90 and after that you have to copy again the new GNU make files (v3.81) into the directory (as you already did according to the wiki) Maybe we have to make that clearer in the wiki or do changes in the osgeo4w setup to overcome the complicated and somehow interfering installation of make3.81 and libtiff 4.0.0dev-90. /Johannes Original-Nachricht Datum: Mon, 28 Nov 2011 17:54:07 +0530 Von: Sandip Maity sandip.stesa...@gmail.com An: Johannes Radinger jradin...@gmx.at CC: grass-user@lists.osgeo.org Betreff: Re: [GRASS-user] Runtime error! / Program: C:\\Osgeo4w\\bin\\python.exe Dear Johannes, I have installed libtiff 4.0.0dev-91 via osgeo4w setup. Please suggest the way. Regards. Sandip On Mon, Nov 28, 2011 at 4:42 PM, Johannes Radinger jradin...@gmx.at wrote: Hello, after a quick google-search: It seems an Error related to the MSVCR80.DLL. AFAIK this .dll comes with the libtiff via the osgeo4w setup. Which version of libtiff do you have installed (check in the osgeo4w advanced setup)? But maybe some others have any other idea!? /Johannes Original-Nachricht Datum: Mon, 28 Nov 2011 15:49:14 +0530 Von: Sandip Maity sandip.stesa...@gmail.com An: grass-user@lists.osgeo.org Betreff: [GRASS-user] Runtime error! / Program: C:\\Osgeo4w\\bin\\python.exe Dear friend, I am compiling and installing grass on windows. But getting error as follows. Runtime error! Program: C:\Osgeo4w\bin\python.exe R6034 An application has made an attempt to load the c runtime library incorrectly. Please help me how can i resolve the issues. regards. Sandip -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Original-Nachricht Datum: Mon, 28 Nov 2011 04:49:55 -0800 (PST) Von: Helmut Kudrnovsky hel...@web.de An: grass-user@lists.osgeo.org Betreff: [GRASS-user] Re: Runtime error! / Program: C:\\Osgeo4w\\bin\\python.exe I have installed libtiff 4.0.0dev-91 via osgeo4w setup. please choose libtiff 4.0.0dev-90 ohh saw that to late that you posted already the answer! Helmut -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Runtime-error-Program-C-Osgeo4w-bin-python-exe-tp7038211p7038597.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 -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with g.region in lat-lon projection
On 28/11/11 13:23, John A Stevenson wrote: Hi, I am trying to set up a grid with a specified resolution using g.region. The information about the grid that came with the data that I want to plot is: X grid origin: 0.2812500 Y grid origin: -89.81250 X grid size: 640 Y grid size: 480 X grid resolution: 0.5625000 Y grid resolution: 0.375 I set up the grid with the following command: GRASS 6.4.1 (global_ll_wgs84):~/NAME/G2011 g.region w=0.2812500 s=-89.81250 cols=640 rows=480 ewres=0.562500 nsres=0.375 I would expect this grid to cover the whole globe (e.g. 640*0.5625=360), but instead it just generates a thin strip, and the ewres is too small. If you have existing settings for e and n, it will keep those. You have to use g.region -d to reset to default values (assuming your default values are -180 - 180 -90 - 90). However, I think that g.region maxes out at 180E and 90N. When I use your settings, I get the following: GRASS 6.4.1 (LLWGS84):~ g.region -d w=0.2812500 s=-89.81250 cols=640 rows=480 ewres=0.562500 nsres=0.375 -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 89:48:45S west: 0:16:52.5E east: 180E nsres: 0:22:28.59375 ewres: 0:16:50.917969 rows: 480 cols: 640 cells: 307200 or by aligning to resolution: GRASS 6.4.1 (LLWGS84):~ g.region -d w=0.2812500 s=-89.81250 cols=640 rows=480 ewres=0.562500 nsres=0.375 -pa projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 90S west: 0 east: 180E nsres: 0:22:30 ewres: 0:16:52.5 rows: 480 cols: 640 cells: 307200 i.e. it adapts the resolution in order to get 640 columns between 0W and 180E. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems while running d.out.file
Hi Sorry to get back to this question again but I was not able to solve this. Ok 1- I have plotted my raster 2- I have added a command layer with this d.barscale bcolor=none at=0,90 3- If I use the Save display to graphic file functionality it works just fine. But If i try to set a smaller Width and Height: a) if I place barscale at 0,90 it gets cut b) If I place barscale at 0,0 it does not get cut but barscale gets over the image Is there any other suggestion on resizing PNG output without loosing image and barscale? Another question: when I launch a new Map Display window: Is it possible to define its size? Thanks Antonio Hamish wrote: Moritz wrote: I can confirm the issue (António, have you posted a bug report ?). The problem is not that the scalebar disappears, but that its location is not adapted to the changed resolution: see the http://geog-pc40.ulb.ac.be/grass/export_png/ for a series of examples. I'm not sure I fully understand the problem, but d.out.file has always worked well for me. the effect of making the width and height of the image is the same as dragging the xmonitor window bigger- the barscale and text is still the same size when viewed at 100% scale. when shrunk to fit on the screen in an image viewer it becomes tiny. You can make text and line widths bigger to compensate but really if you want things to scale well e.g. for a hi-res poster image, you should probably be using ps.map, not screen dumps of the Xmonitors, as the d.* modules were designed for. barscale and legend are placed as a percentage of the display frame, so at least their relative position should stay intact even if the frame gets bigger. if y'all think there's a bug please file a detailed ticket with the steps to reproduce using one of the standard datasets, and I'll look into it. Hamish __ Information from ESET NOD32 Antivirus, version of virus signature database 6639 (2017) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database (2028) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 6.5svn Build Errors
I've been running 6.5svn but haven't used it for several months so I decided to run 'svn up' and get the latest version (build 42410? from this Monday morning). After running 'make clean' and re-configuring I'm getting build errors for the first time. These errors all appear to be html docs: Generating HTML manual pages index (help system)... Generated HTML docs in ../dist.i686-pc-linux-gnu/docs/html/index.html -- Following modules are missing the 'description.html' file in src code: d.ask d.barscale d.colorlist d.colors d.colortable d.correlate d.erase d.extend d.extract d.font d.frame d.geodesic d.graph d.grid d.his d.histogram d.info d.labels d.legend d.linegraph d.m d.mapgraph d.measure d.menu d.mon d.monsize d.mvmon d.nviz d.out.file d.out.gpsdrive d.out.png d.path d.polar d.profile d.rast.arrow d.rast.edit d.rast d.rast.leg d.rast.num d.redraw d.resize d.rgb d.rhumbline d.save d.shadedmap d.slide.show d.split.frame d.split d.text d.thematic.area d.title d.vect.chart d.vect d.vect.thematic d.what.rast d.what.vect d.where d.zoom db.columns db.connect db.copy db.describe db.drivers db.dropcol db.droptable db.execute db.in.ogr db.login db.out.ogr db.select db.tables db.test g.access g.ask g.copy g.dirseps g.extension g.filename g.findetc g.findfile g.gisenv g.gui g.list g.manual g.mapset g.mapsets g.message g.mkfontcap g.mlist g.mremove g.pnmcomp g.proj g.region g.remove g.rename g.setproj g.tempfile g.transform g.version i.atcorr i.cca i.class i.cluster i.fft i.fusion.brovey i.gensig i.gensigset i.group i.his.rgb i.ifft i.image.mosaic i.in.spotvgt i.landsat.acca i.landsat.rgb i.landsat.toar i.maxlik i.modis.qc i.oif i.ortho.photo i.pca i.photo.2image i.photo.2target i.photo.camera i.photo.init i.photo.rectify i.points i.rectify i.rgb.his i.smap i.spectral i.target i.tasscap i.topo.corr i.vpoints i.zc m.cogo m.nviz.image m.proj ps.map r.average r.basins.fill r.bilinear r.bitpattern r.blend r.buffer r.carve r.category r.circle r.clump r.coin r.colors r.colors.out r.colors.stddev r.composite r.compress r.contour r.cost r.covar r.cross r.describe r.digit r.distance r.drain r.external r.fill.dir r.fillnulls r.flow r.grow.distance r.grow r.gwflow r.his r.horizon r.in.arc r.in.ascii r.in.aster r.in.bin r.in.gdal r.in.gridatb r.in.mat r.in.poly r.in.srtm r.in.wms r.in.xyz r.info r.kappa r.lake r.le.patch r.le.pixel r.le.setup r.le.trace r.li.cwed r.li.dominance r.li.edgedensity r.li.mpa r.li.mps r.li.padcv r.li.padrange r.li.padsd r.li.patchdensity r.li.patchnum r.li.pielou r.li.renyi r.li.richness r.li.setup r.li.shannon r.li.shape r.li.simpson r.los r.mapcalculator r.mask r.median r.mfilter.fp r.mfilter r.mode r.neighbors r.null r.out.arc r.out.ascii r.out.bin r.out.gdal r.out.gdal.sh r.out.gridatb r.out.mat r.out.mpeg r.out.png r.out.pov r.out.ppm r.out.ppm3 r.out.tiff r.out.vrml r.out.vtk r.out.xyz r.param.scale r.patch r.plane r.profile r.proj r.quant r.quantile r.random.cells r.random r.random.surface r.reclass.area r.reclass r.recode r.region r.regression.line r.report r.resamp.interp r.resamp.rst r.resamp.stats r.resample r.rescale.eq r.rescale r.ros r.series r.shaded.relief r.sim.sediment r.sim.water r.slope.aspect r.spread r.spreadpath r.statistics r.stats r.sum r.sun r.sunmask r.support r.support.stats r.surf.area r.surf.contour r.surf.fractal r.surf.gauss r.surf.idw r.surf.idw2 r.surf.random r.terraflow r.texture r.thin r.tileset r.timestamp r.to.rast3 r.to.rast3elev r.to.vect r.topidx r.topmodel r.transect r.univar r.univar.sh r.volume r.walk r.water.outlet r.watershed r.what.color r.what r3.cross.rast r3.gwflow r3.in.ascii r3.in.v5d r3.info r3.mapcalculator r3.mask r3.mkdspf r3.null r3.out.ascii r3.out.v5d r3.out.vtk r3.stats r3.timestamp r3.to.rast r3.univar v.buffer v.build.all v.build v.build.polylines v.category v.centroids v.class v.clean v.colors v.convert.all v.convert v.db.addcol v.db.addtable v.db.connect v.db.dropcol v.db.droptable v.db.join v.db.reconnect.all v.db.renamecol v.db.select v.db.univar v.db.update v.delaunay v.digit v.dissolve v.distance v.drape v.edit v.external v.extract v.extrude v.generalize v.hull v.in.ascii v.in.db v.in.dxf v.in.e00 v.in.garmin v.in.geonames v.in.gns v.in.gpsbabel v.in.lines v.in.mapgen v.in.ogr v.in.region v.in.sites.all v.in.sites v.in.wfs v.info v.kcv v.kernel v.krige.py v.label v.label.sa v.lidar.correction v.lidar.edgedetection v.lidar.growing v.lrs.create v.lrs.label v.lrs.segment v.lrs.where v.mkgrid v.neighbors v.net.alloc v.net.allpairs v.net.bridge v.net.centrality v.net.components v.net.connectivity v.net.distance v.net.flow v.net v.net.iso v.net.path v.net.salesman v.net.spanningtree v.net.steiner v.net.timetable v.net.visibility v.normal v.out.ascii v.out.dxf v.out.gpsbabel v.out.ogr v.out.pov v.out.svg v.out.vtk v.outlier v.overlay v.parallel v.parallel2 v.patch v.perturb v.proj v.qcount v.random v.rast.stats v.reclass v.report v.sample v.segment v.select v.split
Re: [GRASS-user] 6.5svn Build Errors
Rich wrote: I've been running 6.5svn but haven't used it for several months so I decided to run 'svn up' and get the latest version (build 42410? from this Monday morning). After running 'make clean' and re-configuring I'm getting build errors for the first time. please use 'make distclean' and re-run ./configure. When I change to ../g.parser and run 'make' I see errors related to the html docs: [...] No such file or directory at ../../tools/g.html2man/g.html2man line 271. (it was moved in the build,installed dirs, but ../../tools/g.html2man/g.html2man should still be valid from the module source dir.) It's the same for i.ask, i.find, and I assume the rest. I've just tried with a fresh 'svn up', it built ok for me. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems while running d.out.file
António wrote: Is there any other suggestion on resizing PNG output without loosing image and barscale? fundamentally if you want to have full cartographic control or want to make a high-res image suitable for e.g. a poster or a journal article, you're going to have to use ps.map. (now made easy with Anna's new cartographic composer) you can convert .eps or .ps to PNG if you need to with a number of tools, here is one way: pstoimg -aaliastext -antialias -depth 24 -scale 1.5 $IMAGE.ps d.barscale's height is hardcoded at a fixed number of pixels high in display/d.barscale/draw_scale.c as it was only designed to be shown on a computer monitor or projector at 100% scale. maybe 'd.barscale -l' does not look so bad when made (relatively) small? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 6.5svn Build Errors
On Mon, 28 Nov 2011, Hamish wrote: please use 'make distclean' and re-run ./configure. Hamish, This makes no difference. I'll clean out the directory, download the source anew and try again. More when I have it. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 6.5svn Build Errors [RESOLVED]
On Mon, 28 Nov 2011, Rich Shepard wrote: I'll clean out the directory, download the source anew and try again. More when I have it. Hamish, Yep. That fixed it. Apparently the 'svn up' left cruft from previous builds and gcc got caught looking in the wrong directory. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with g.region in lat-lon projection
John wrote: I am trying to set up a grid with a specified resolution using g.region. The information about the grid that came with the data that I want to plot is: X grid origin: 0.2812500 Y grid origin: -89.81250 X grid size: 640 Y grid size: 480 X grid resolution: 0.5625000 Y grid resolution: 0.375 I set up the grid with the following command: ... dumb question: does this work? r.info your_imported_map g.region rast=your_imported_map do you know if the original data used the cell- center registered or grid line-confluence registered convention? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
Martin: Unfortunately, reCAPTCHA might be a victim of its own success - as of 2011, some spammers appear to have figured out a way to bypass it, either through character recognition or by using humans. For that reason, it is not necessarily recommended. If they have humans working for them no turing test will suffice. (or, perhaps the advanced math one..) this is why I think it is good to keep the captcha for urls. They could have humans create the accounts and then spambots polute 100 pages once the account is created. i.e. make it as expensive for them as we can. Ben: I can confirm this. On another site that I manage, based on phpBB, I get unbelievable amounts of spambot requests to open accounts. Apparently, simple graphical captchas no longer hold them back. I think math captchas are a good idea. Plus, it's free brain exercise :) Part of the weakness of the ReCaptcha module is that ConfirmEdit doesn't include any penalty mechanism, so spam bots can simply keep trying to bypass the CAPTCHA until they get through. This is an issue that is strongly worth addressing in some way. I guess reCaptcha doesn't mind the spammers working for them, free labor! :-) ok, that's probably being way too cynical, this is ConfirmEdit's bug not reCaptcha's. [1] http://www.mediawiki.org/wiki/Confirmedit hmmm, can't hurt to put a sleep(3) on a fail, line 119? http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ReCaptcha.php?revision=104064view=markup and increment a counter, which if you fail ~10 times then replace the call to $editPage-showEditForm( array( $this, 'editCallback' ) ); with a message saying that we could not verify that you were human and your edit was unable to be submitted: make a copy of your work and try again later? or perhaps mix it up a bit: if the reCaptcha fails 3 times switch to the math captcha, if that fails 3 times failover to simpleCaptcha, if that fails three times have mediawiki ban the IP address for 24 hours. sort of a cascading fail2ban. shrug, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Runtime error! / Program: C:\Osgeo4w\bin\python.exe
Hi johannes and all,
According to your suggestion, I uninstall the libtiff- 4.0.0dev 91 and
install libtiff 90. Also I have update make directory according to your
direction.
Make -version showing 3.81.
But Still same error is coming.
Please reply sap.
Regards.
Sandip
On Mon, Nov 28, 2011 at 7:23 PM, Johannes Radinger jradin...@gmx.at wrote:
Hi,
Maybe that is causing the problem (as it did in my case!)
Via the advanced setup you can you can choose 4.0.0dev-90.
This works in my case. But you have to be careful then
with the make (the one you installed manually) this can be
updated and overwritten by the osgeo4w setup with the old version
3.7 again.
In that case you have to set to libtiff 4.0.0dev-90 and after that you
have to copy again the new GNU make files (v3.81) into the directory
(as you already did according to the wiki)
Maybe we have to make that clearer in the wiki or do changes in
the osgeo4w setup to overcome the complicated and somehow interfering
installation of make3.81 and libtiff 4.0.0dev-90.
/Johannes
Original-Nachricht
Datum: Mon, 28 Nov 2011 17:54:07 +0530
Von: Sandip Maity sandip.stesa...@gmail.com
An: Johannes Radinger jradin...@gmx.at
CC: grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] Runtime error! / Program:
C:\\Osgeo4w\\bin\\python.exe
Dear Johannes,
I have installed libtiff 4.0.0dev-91 via osgeo4w setup.
Please suggest the way.
Regards.
Sandip
On Mon, Nov 28, 2011 at 4:42 PM, Johannes Radinger jradin...@gmx.at
wrote:
Hello,
after a quick google-search: It seems an Error related to
the MSVCR80.DLL. AFAIK this .dll comes
with the libtiff via the osgeo4w setup. Which version of
libtiff do you have installed (check in the osgeo4w advanced
setup)?
But maybe some others have any other idea!?
/Johannes
Original-Nachricht
Datum: Mon, 28 Nov 2011 15:49:14 +0530
Von: Sandip Maity sandip.stesa...@gmail.com
An: grass-user@lists.osgeo.org
Betreff: [GRASS-user] Runtime error! / Program:
C:\\Osgeo4w\\bin\\python.exe
Dear friend,
I am compiling and installing grass on windows.
But getting error as follows.
Runtime error!
Program: C:\Osgeo4w\bin\python.exe
R6034
An application has made an attempt to load the c runtime library
incorrectly.
Please help me how can i resolve the issues.
regards.
Sandip
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
