Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support -+-- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:13 wenzeslaus]: Files are much smaller The downside of this is that the d.* command will take longer as it has to compress the output file. and there is one file less If desired, we could have a single file without the compression overhead by using the PNG writer from lib/pngdriver, which allows the compression level to be set via the GRASS_PNG_COMPRESSION environment variable. (thanks to composing in Python) but during zooming/panning the most of the time is spent with disk IO. (Tested on Ubuntu 10.04.) Zooming and panning require re-executing the d.* commands to generate new images. But we can output binary data to stdout and read them in Python directly. This would avoid disk IO. What do you think about using stdout instead of a file in case of d.* modules? That requires either storing all layers in memory, regardless of whether or not they are displayed, or re-generating layers if they are disabled then re-enabled. It also eliminates the possibility of implementing a decent caching mechanism (i.e. being able to undo zoom/pan operations by re-using the previous images rather than having to re-generate them). And using pipes may be slower than disk (if the Python side is using select(), there will be a context switch for each pipe-buffer-size of data). -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:14 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1725: m.cogo include starting co-ord in output
#1725: m.cogo include starting co-ord in output -+-- Reporter: gfleming | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 6.4.3 Component: Vector | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- if you specify a starting coordinate it would be useful to have the option to include it in m.cogo output so that all points representing a parcel will be present. At the moment it has to be added in a separate step to complete linework or area construction. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1725 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1696: Error message v.db.dropcol (Add-On Path)
#1696: Error message v.db.dropcol (Add-On Path) ---+ Reporter: jradinger | Owner: hamish Type: defect | Status: assigned Priority: blocker| Milestone: 6.4.3 Component: Shell Scripts | Version: unspecified Keywords: |Platform: Unspecified Cpu: All| ---+ Changes (by hamish): * priority: normal = blocker Comment: Replying to [comment:1 hamish]: right, this is a sibling of #1683, sorry I haven't been able to get to all of them yet. Further review of the GUI's method of setting the ADDON environment variable is needed too, but the scripts should be robust enough to deal with it regardless. re. Further review of the GUI's method of setting the ADDON environment variable is needed, 6.4.3 should not be released with the recent system vs. grass enviro var duplication confusion. Last chance to justify the need for a parallel method before I remove the g.gisenv ADDON_PATH stuff from init.sh and the GUI in 6.x.svn... As quoted above, I didn't want to do that without discussion of why the redundant g.gisenv method needed to be there. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1696#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1692: calling a script within a script failing on Windows XP
#1692: calling a script within a script failing on Windows XP -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: Shell Scripts| Version: 6.4.2 Keywords: v.random.cover, wingrass, shell scripts |Platform: MSWindows XP Cpu: x86-32 | -+-- Comment(by hamish): we need to fix this ASAP as it takes out a bunch of the scripts, including many of the v.db.* ones. anyone have ideas? thanks, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/1692#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1452: wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken
#1452: wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 6.4.3 Component: Projections/Datums | Version: svn-releasebranch64 Keywords: location wizard, g.proj |Platform: All Cpu: All | -+-- Comment(by hamish): Replying to [comment:15 neteler]: Is this still a problem? An exhaustive test of grass/qgis/cs2cs/postgis against 4.8.0-final re. proj4 bug # 122 has been on my too list since way too long ago. I'll try to get to that this week. From what I understand, QGIS is still broken, although they use a different path than grass and their solution involved patching particular CRSs as people complained, each time the CRS files were updated. :-/ But Frank did clean up the situation a bit before the 4.8.0 release, so I'm hoping for success. best, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/1452#comment:16 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] winGRASS 6.4.svn: Attribute manager not opening
Hi,
does this have to do with parsing the vector/$MAP/dbln file?
There was an unfortunate thing in the 6.x format spec of that file where
space was used as the delimiter and it was impossible to fix for spaces
in the path, since the result would always be ambiguous. In GRASS 7 I
changed the delim to '|', and AFAIR backported read-support for that back
to grass6. If that sounds like the issue let me know and I'll dig out
more details about it, and how to work around it so it works cleanly
in all branches in a backwarks-forwards compatible way.
Note that for the dbln file the C code looks for and substitutes for
$GISDBASE/$LOCATION_NAME/$MAPSET/
on all platforms, they are simulated enviro variables and for file-
system portability should be kept in the above form instead of replacing
with a real path. (unless that's really what you want to do)
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences.
sorry, this email thread got lost in the pile. where/what specifically
are you talking about there?
Hamish
[sorry for the top posting, broken linewrap, and missing authors, too
late to fight with yahoo tonight]
when loading roadsmajor of NC on various windows
machines (with
and without white space in the grassdata path, we get
Error:
'columns' is not recognized as an internal or external
command,
operable program or batch file
[OK]
Then the attrib. manager opens but it remains empty.
Maybe here?
dbmgr/manager.py
...
self.listOfCommands.append(('v.db.addcol',
{ 'map' :
self.vectorName,
'layer' :
self.layer,
'columns' : '%s %s' % (name,
ctype) }
))
No idea..
Markus
Problem occurs when calling this (line 194, dbmgr/manager.py
in grass64)
ret = RunCommand('v.db.select',
quiet = True,
parent = self,
flags = 'c',
map = self.mapDBInfo.map,
layer = layer,
columns = ','.join(columns),
fs = fs,
where = where,
stdout = outFile)
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences. On
Windows it is causing splitting the whole command into 2
parts -
before and after pipe. As a result 'columns' parameter
(after pipe) is
treated like another command. As a temporal workaround you
can set the
separator to something different in preferences (more
characters are
accepted) - this should work immediately. I can also
revert the
change.
On Linux the characters in parameters are escaped properly
probably in
Popen but not on Windows. Anyone knows how to solve this
properly?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist sep= or fs= ?
On Wed, Sep 5, 2012 at 10:09 AM, Markus Neteler nete...@osgeo.org wrote: Hi, me and some of my course participants (GeoSTAT 2012) stumbled over the change of sep= to fs= in GRASS 7. While ... On Thu, Dec 11, 2008 at 11:21 AM, Hamish hamis...@yahoo.com wrote: Huidae Cho wrote: When I first wrote the original script, I also thought about fs=. But, you're right, there are no fields to separate, and that's why it's been separator=. ok, reverted. Hamish it has become again fs=... http://grass.osgeo.org/grass70/manuals/html70_user/g.mlist.html In a quick poll in my course the people (being R savvy) all voted for separator=, also to keep consistency with R! (and GRASS 6 btw). I would strongly suggest to change all fs= in GRASS 7 (several modules) to separator= before it propagates more. Reverted back to separator in r53139. Markus M Bonus: no script breakage from GRASS 6 to 7. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] geodesic distances for measuring and buffers, even when working in planar coordinate system ? [was: Re: [GRASS-user] What distance is being measured and used for buffers ?]
On Fri, Sep 7, 2012 at 9:45 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 07/09/12 09:05, Markus Metz wrote: On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/09/12 18:02, Moritz Lennert wrote: Leaving below mail as record of my original issue, I would to raise the fundamental question of whether it would be feasible 1) to (optionally) provide geodesic instead of planar distances when measuring, even if the location is in a projected coordinate system. E.g. QGIS provides the possibility in distance measuring to check a box to activate geodesic distance 2) to (optionally) allow the creation of buffers based on geodesic distances, again in a projected location, which would imply non-circular buffers. Exploring my exploration of this in the hope that someone might share an interest: r.buffer actually provides the possibility of geodesic buffering when used in a lat-long location. Would it be difficult to implement the same in v.buffer ? The short answer is yes, it will be difficult. The GRASS-internal vector buffering algorithm has a number of bugs, the only vector buffering method that is AFAICT bug-free is v.buffer in trunk with GEOS support which uses the GEOS buffering algorithm which in turn does not (yet?) support geodesic distances in latlong. Ok, thanks for the answer. This means that efforts should be put into including this into GEOS and in the mean time, maybe write a small script v.buffer.geodesic that uses r.buffer. Since we're on it: any idea about question 1) ? I guess this feature would need to be implemented on both library and module level. A library function to first project to latlong, then calculate geodesic distance would be needed. Modules could then get an option to use geodesic distance, as long as it is not a pseudo xy projection, and make use of the new library function if requested. There may be a lot of pitfalls with such a feature. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1706: wingrass: open attribute table fails
#1706: wingrass: open attribute table fails -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 6.4.3 Component: wxGUI| Version: svn-releasebranch64 Keywords: wingrass,db |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by annakrat): This error is caused by changes for #1633 and more information is in the discussion [http://osgeo-org.1560.n6.nabble.com/winGRASS-6-4-svn-Attribute-manager- not-opening-td4999639.html here] -- Ticket URL: http://trac.osgeo.org/grass/ticket/1706#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] winGRASS 6.4.svn: Attribute manager not opening
Hi,
On Sun, Sep 9, 2012 at 1:15 PM, Hamish hamis...@yahoo.com wrote:
Hi,
does this have to do with parsing the vector/$MAP/dbln file?
There was an unfortunate thing in the 6.x format spec of that file where
space was used as the delimiter and it was impossible to fix for spaces
in the path, since the result would always be ambiguous. In GRASS 7 I
changed the delim to '|', and AFAIR backported read-support for that back
to grass6. If that sounds like the issue let me know and I'll dig out
more details about it, and how to work around it so it works cleanly
in all branches in a backwarks-forwards compatible way.
Note that for the dbln file the C code looks for and substitutes for
$GISDBASE/$LOCATION_NAME/$MAPSET/
on all platforms, they are simulated enviro variables and for file-
system portability should be kept in the above form instead of replacing
with a real path. (unless that's really what you want to do)
This doesn't seem related. I explained the problem in the mail above
but I can try to explain it more clearly if needed.
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences.
sorry, this email thread got lost in the pile. where/what specifically
are you talking about there?
Here is the ticket:
http://trac.osgeo.org/grass/ticket/1633
Anna
Hamish
[sorry for the top posting, broken linewrap, and missing authors, too
late to fight with yahoo tonight]
when loading roadsmajor of NC on various windows
machines (with
and without white space in the grassdata path, we get
Error:
'columns' is not recognized as an internal or external
command,
operable program or batch file
[OK]
Then the attrib. manager opens but it remains empty.
Maybe here?
dbmgr/manager.py
...
self.listOfCommands.append(('v.db.addcol',
{ 'map' :
self.vectorName,
'layer' :
self.layer,
'columns' : '%s %s' % (name,
ctype) }
))
No idea..
Markus
Problem occurs when calling this (line 194, dbmgr/manager.py
in grass64)
ret = RunCommand('v.db.select',
quiet = True,
parent = self,
flags = 'c',
map = self.mapDBInfo.map,
layer = layer,
columns = ','.join(columns),
fs = fs,
where = where,
stdout = outFile)
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences. On
Windows it is causing splitting the whole command into 2
parts -
before and after pipe. As a result 'columns' parameter
(after pipe) is
treated like another command. As a temporal workaround you
can set the
separator to something different in preferences (more
characters are
accepted) - this should work immediately. I can also
revert the
change.
On Linux the characters in parameters are escaped properly
probably in
Popen but not on Windows. Anyone knows how to solve this
properly?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1619: v.krige won't load: ImportError: No module named globalvar
#1619: v.krige won't load: ImportError: No module named globalvar -+-- Reporter: momsen | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: krige|Platform: Linux Cpu: x86-64 | -+-- Comment(by annakrat): I can fix the FlatNotebook part of error (probably tomorrow, I must first download some packages to be able to test it). Anna -- Ticket URL: https://trac.osgeo.org/grass/ticket/1619#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support -+-- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by cmbarton): Perhaps it would help to give a simple description of the display workflow. 1. All rendering begins with GRASS display modules, d.*. The PNG driver is set so that rendering is to temporary PNM files. It could also be to PNG or Cairo with current GRASS 7 architecture. IMHO, this is the place of the greatest slow down. The default setting of the PNG driver is to render files produced by the display modules to the current screen resolution and H/W ratio, using a combination of temporary display region and PNG driver settings for H and W. This avoids a problem with the old xmon driver that rendered to the current region only--fast for regions with few cells but really slow for regions with lots of cells. 2. All rendered PPM files are sent to g.pnmcomp along with opacity values for each layer. These are rendered into a composite PNM image with the H/W values from the PNG driver settings. The PNM image is translated to a PNG. 3. The PNG is read by wxPython and rendered to a display context (DC) canvas. It can be shifted and rescaled on the fly (though with impacts to resolution) so that panning and zooming actions can happen visually while any needed rerendering is done in the background Overlays like scales and legends are done somewhat differently. They also depend on relevant GRASS modules like d.barscale and d.legend, but they render to PNG files and are not composited with g.pnmcomp. They are read into a DC canvas individually so that each can be arranged on top of the base composite map. There are several possible places for speed up in this workflow 1. All GRASS layers could simply be rendered to PNG files and use wxPython for compositing in the DC canvas. Glynn has suggested this and it has long been considered a medium term goal. But it takes fairly substantial rewriting of part of the display code. Not huge, but considerable work all the same. This could skip running g.pnmcomp and g.pnmtopng. There are a number of wxPython compositing tools that allow you to shift images on screen, zoom, and add transparency. 2. A 'wxPython driver' could be developed that would dispense with rendering to files that need to be read. We discussed this sometime back. Glynn's opinion at the time was that this would not be significantly faster than rendering to files. Moreover the files provide a way to recover the display in case of a crash. Of course the temp files also can get orphaned and left on disk if there is a crash. 3. Intermediate would be to have something like g.pnmcomp that works directly with PNG files or at least outputs to a PNG file to save the PNM to PNG translation. I'm not sure if using a compressed file format would save anything because something somewhere has to compress and decompress it, taking CPU time. Also there is the chance of loss of information, though that is probably of little to no concern for a display that is regularly refreshed. 4. The d.* modules simply take some time to render. I'm pretty sure that this is what takes up the most time in displays, even with displaying to screen resolution instead of region resolution. Perhaps these could be sped up. Or perhaps the rendering and compositing could be done in GRASS in a single step. Hope this is helpful to thinking about this. Michael -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:15 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist sep= or fs= ?
On Sun, Sep 9, 2012 at 1:33 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: ... Reverted back to separator in r53139. Thanks - I have updated now the related HTML manuals. MarkusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS6.4.3svn d.rast -o, d.vect -c, Browse for v.out.ogr
d.rast -o landuse96_28m cat=1,2 run in command console is interpreted as follows: Command 'd.rast -l -a -n -d -u -s -e -9 -6 -_ -2 -8 -m map=-o cat=1,2' failed Details: Sorry, l is not a valid flag Sorry, a is not a valid flag Sorry, n is not a valid flag Sorry, d is not a valid flag Sorry, u is not a valid flag Sorry, s is not a valid flag Sorry, e is not a valid flag Sorry, 9 is not a valid flag Sorry, 6 is not a valid flag Sorry, _ is not a valid flag Sorry, 2 is not a valid flag Sorry, 8 is not a valid flag Sorry, m is not a valid flag d.rast landuse96_28m cat=1,2 -o works fine. I tried to fix it so it should work now. I hope I didn't break something else, this is quite difficult to test. does this fix solve also the flags with d.vect? For example I get d.vect map=-c basin_50Kval Command 'd.vect -b -a -s -i -n -_ -5 -0 -K -v -a -l map=-c' failed Details: Sorry, b is not a valid flag Sorry, s is not a valid flag Sorry, n is not a valid flag Sorry, _ is not a valid flag Sorry, 5 is not a valid flag Sorry, 0 is not a valid flag Sorry, K is not a valid flag Sorry, l is not a valid flag Thanks a lot. I think I have written that the color fill on cutting planes does not work on windows - I tried it again and it works great, We just worked in class with wxnviz last week and we did not have any problems on 20+ computers and laptops running windows and Mac OSX, so that is fantastic, given how new the GUI is. Also, this is the first year that I haven't seen many complaints about import/export of raster and vector data, so that is a great improvement too. The only comment I have seen so far was lack of Browse button when selecting the directory for v.out.ogr output, I am wondering whether it is intentional due to some technical issues or just an oversight, given that r.out.gdal has such option. Helena add volume still does not open dialog Maybe someone else (who is more familiar with PATH and Makefiles) could help? Anna I am running Michaels Mac binary, Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1726: r.plane
#1726: r.plane
-+--
Reporter: hamish | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Keywords: r.plane |Platform: All
Cpu: All |
-+--
Hi,
The r.plane script (all versions) does a bit of a funny thing, it takes as
input azimuth as degrees CCW from north.
Which is a bit weird, as it's neither the nautical compass convention
(degrees CW from north), nor the mathematical convention that grass
usually uses (theta measured CCW from the +x axis).
before I change it, does anyone know why it might intentionally be weird
like that?
as with d.barb and some other modules, the updated version would give you
the alternate option to work in nautical convention.
{{{
type_opt = G_define_option();
type_opt-key = aspect_type;
type_opt-type = TYPE_STRING;
type_opt-required = NO;
type_opt-answer = cartesian;
type_opt-options = cartesian,compass;
type_opt-description = _(Direction map aspect type);
}}}
the test case I'm working with is to make a generalized background trend
map by taking some raster data, use r.slope.aspect + r.univar to find the
average slope,dx,dy maps, then use atan2(dy,dx) to find the mean azimuth.
then use raster map's center x,y,z value as the pivot point for r.plane.
(probably should use median(z) instead of center-z for that?)
another point of refinement is to take the center-of-gravity center cell
as the pivot point not the center of the region, as there may be block of
null cells not contributing to the mean. To find the COG there is the
v.points.cog addon script, but I suspect the method may be a bit
inefficient. any other modules that could do that?
thoughts?
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1726
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1726: r.plane: change azimuth option to be CCW from the +x axis (was: r.plane)
#1726: r.plane: change azimuth option to be CCW from the +x axis -+-- Reporter: hamish | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Python | Version: svn-trunk Keywords: r.plane |Platform: All Cpu: All | -+-- -- Ticket URL: https://trac.osgeo.org/grass/ticket/1726#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] is r.in.png working in GRASS 7?
I just tried to use r.in.png to prepare a demo of georectifying for my class 1. I made a map from the sc demo data of roads, streams, and lakes 2. I exported it to PNG. Looks fine 3. I used r.in.png to import it. No error. 4. No map I tried the default settings and the floating point flag. Any ideas? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
