Re: [GRASS-dev] [GRASS GIS] #2136: Create standard options for map or file base name (prefix)
#2136: Create standard options for map or file base name (prefix) -+-- Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Parser | Version: svn-releasebranch64 Keywords: base name, prefix, basename |Platform: All Cpu: All | -+-- Comment(by zarch): Replying to [comment:16 wenzeslaus]: Replying to [comment:14 zarch]: Just for the record this are ASCII characters » (175), ■ (254)... I wish this to be true but it is not. They might be part of some [http://en.wikipedia.org/wiki/Extended_ASCII extended ASCII]; I can see them at [http://www.asciitable.com/ asciitable] but not at [http://www.ascii-code.com/ ascii-code]. More importantly, they are not part of widely supported (and thus safe) [http://en.wikipedia.org/wiki/ASCII ASCII] which has only 128 printable and non-prinatble characters (to fit into 7 bits). ASCII corresponds to first 128 characters of [http://en.wikipedia.org/wiki/UTF-8 UTF-8]. yes, you are right, thanks for clarification. Replying to [comment:14 zarch]: Replying to [comment:16 wenzeslaus]: Perhaps one underscore is enough. I don't think so, a single underscore is too common, it is too prone to casual errors. For example, we decide to not write the dot in float number (basename_000.05) as in raster maps generated by r.horizon using a single underscore (basename_000_05), but in this way is not clear which one is the basename which the id. If in the future we will have to generate raster maps with two floating points (basename_000.05_000.10), if we consider to not use the dot, it is not readable (basename_000_05_000_10). Use two underscore (basename__000_05__000_10) at least avoid these problems (but it is not working in trac!). So I don't see too many options... Maybe we can define a GBASENAME_SEP variable in gis.h containing the default separator, and as suggested by hco, in the future add the possibility to set an environmental variable to customize the character or the sequence of characters that will be consider as basename separator. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2136#comment:17 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] #2352: Conflicting definitions of db__driver_describe_table
#2352: Conflicting definitions of db__driver_describe_table
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.5
Component: Database | Version: 6.4.3
Keywords: dbf driver, libdb |Platform: All
Cpu: All|
---+
Hi,
as reported here, http://bugs.debian.org/748680
there is a param def'n conflict for `db__driver_describe_table()` in
db/drivers/dbf/describe.c and lib/db/stubs/desc_table.c.
{{{
int db__driver_describe_table(dbString * table_name, dbTable ** table)
vs
int db__driver_describe_table(dbString * name, dbTable * table)
}}}
present in all branches, 6.3.0-trunk.
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2352
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] #2017: ogsf compilation error
#2017: ogsf compilation error ---+ Reporter: martinl| Owner: grass-dev@… Type: defect | Status: new Priority: blocker| Milestone: 7.0.0 Component: Compiling | Version: svn-trunk Keywords: libc, ogsf, libavutil, ffmpeg |Platform: Linux Cpu: x86-64 | ---+ Changes (by neteler): * priority: critical = blocker Comment: Replying to [comment:22 hamish]: A reminder, ffmpeg is not used with trunk, only for creating animations directly in tcl/tk NVIZ in grass 6. suggest to remove it from libogsf and configure.in in trunk. Sounds reasonable. Marked as blocker for the 7.0 release. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2017#comment:23 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] Rast_open_update?
Whenever I change a couple of cells in an existing raster map, I have to create a new raster map and patch the old and new maps, which can take long because r.patch has to read and write the entire map. There are Rast_open_old/new, but no Rast_open_update and AFAIK there are no raster modules that directly update existing raster maps. I don't know why. I thought it would be great if there was Rast_open_update so we can update existing raster maps without creating a temp map and patching it. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Rast_open_update?
Hi Huidae, FWIK, the reason why updating raster maps is currently not supported in GRASS at the module level is the storage format. Usually raster maps are stored using zip compressed rows. Rows are written in serial, hence if you modify a single row, the size of this row may be different after compression and does not fit exactly in the position of the old row in the existing file. From my knowledge there is currently no way to append rows or mark rows as invalid in existing raster maps. However, there is the possibility to store raster maps using uncompressed rows, but i don't recall any raster library function to update such maps. Best regards Soeren 2014-06-26 15:05 GMT+02:00 Huidae Cho gras...@gmail.com: Whenever I change a couple of cells in an existing raster map, I have to create a new raster map and patch the old and new maps, which can take long because r.patch has to read and write the entire map. There are Rast_open_old/new, but no Rast_open_update and AFAIK there are no raster modules that directly update existing raster maps. I don't know why. I thought it would be great if there was Rast_open_update so we can update existing raster maps without creating a temp map and patching it. ___ 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] new wxgui tool: Temporal plot
Hi everybody, I just commit in trunk (r60981) a new tool for wxgui, the Temporal plot. It allows the user to see in a plot the values of one or more temporal datasets (strds, stvds, str3ds) for a queried point defined by a coordinate pair, it can also save directly the plot to an image (so it is possible to run it on a script for several point). Testing and improvement are really welcome. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1213: wingrass 64bit branch
#1213: wingrass 64bit branch +--- Reporter: khsti | Owner: grass-dev@… Type: enhancement | Status: new Priority: major | Milestone: 6.4.4 Component: Packaging | Version: svn-releasebranch64 Keywords: wingrass 64bit |Platform: MSWindows 7 Cpu: Unspecified | +--- Comment(by hellik): Replying to [comment:7 hamish]: see some initial notes for winGRASS-64bit: http://trac.osgeo.org/grass/wiki/CompileOnWindows#winGRASS-64bit-notes extension welcome. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1213#comment:8 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] #2004: wxgui: ctrl-t to tile layer manager and map window full screen
#2004: wxgui: ctrl-t to tile layer manager and map window full screen
---+
Reporter: hamish | Owner: grass-dev@…
Type: enhancement| Status: new
Priority: normal | Milestone: 7.1.0
Component: wxGUI | Version: svn-trunk
Keywords: window layout |Platform: All
Cpu: All|
---+
Comment(by wenzeslaus):
Replying to [comment:4 hamish]:
ps- any thoughts on the usefulness (or not) of the multi-display window
tiling patch attached to this ticket?
I like the idea but I remember when I was looking at the code in the
patch, my conclusion was that a lot of work is still required. Moreover,
I'm afraid that it will be hard to do it generally, especially in cross-
platform manner, for example even the tiling functionality in Ubuntu's
Unity does not work perfectly and there are different limitations in
Ubuntu 12.04 and 14.04.
Hoverer, general tiling window managers might be pretty good option. The
advantage is that you can also layout things like a terminal window. I'm
attaching screenshot from from Ubuntu 14.04 (with Unity) where I've used
`Ctrl+Alt+1` for terminal, `Ctrl+Alt+7` for layer manager, and
`Ctrl+Alt+9` and `Ctrl+Alt+3` for map displays. Terminal and especially
layer manager are unnecessary long but it was actually quite useful for
long commands and long map names.
By the way, the screenshot shows also another Unity's feature, a search in
main menu (aka HUD). This started to work with Ubuntu 14.04 (I don't know
if because of updates in wxPython, wxWidgets, wxGtk or Unity itself). By
this I don't mean that that everybody should start using Ubuntu. My point
is that there are some system features which GRASS can benefit from.
(Cycling just GRASS windows instead of all using {{{Ctrl+`}}} is
advantageous too, by the way.)
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2004#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
[GRASS-dev] sphinx documentation for lib python
Hi devs, I'm going to start to work on sphinx documentation for lib/python in the next week/s. I would like to know which directory do you like to have on the docs. I think that all the directories (ctypes, imaging, pydispatch, pygrass, script, temporal) should be in. what do you think? PS I would like also to modify pygrass documentation removing all method, classes and function documentation (moving it to the new programming documentation) and leaving it only the user documentation with example. is it ok for you? -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sphinx documentation for lib python
Hi Luca, On Thu, Jun 26, 2014 at 11:02 AM, Luca Delucchi lucadel...@gmail.com wrote: Hi devs, I'm going to start to work on sphinx documentation for lib/python in the next week/s. I would like to know which directory do you like to have on the docs. I think that all the directories (ctypes, imaging, pydispatch, pygrass, script, temporal) should be in. I'm not sure about how it works with ctypes but all the other should be there for sure, although pydispatch and imaging are little bit special since they partially contain 3rd party code. what do you think? PS I would like also to modify pygrass documentation removing all method, classes and function documentation (moving it to the new programming documentation) and leaving it only the user documentation with example. is it ok for you? I'm not exactly sure what do you mean by that. I know that there are different possibilities how to approach this. Can please you provide more examples and describe it more (e.g. draft the rules how doc should be written)? Thank you, Vaclav -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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] sphinx documentation for lib python
On 26 June 2014 17:21, Vaclav Petras wenzesl...@gmail.com wrote: Hi Luca, Hi Vaclav, On Thu, Jun 26, 2014 at 11:02 AM, Luca Delucchi lucadel...@gmail.com wrote: Hi devs, I'm going to start to work on sphinx documentation for lib/python in the next week/s. I would like to know which directory do you like to have on the docs. I think that all the directories (ctypes, imaging, pydispatch, pygrass, script, temporal) should be in. I'm not sure about how it works with ctypes but all the other should be there for sure, although pydispatch and imaging are little bit special since they partially contain 3rd party code. Yes, after sent the email I had your same doubt with ctypes. I'll try and see what happen :-) what do you think? PS I would like also to modify pygrass documentation removing all method, classes and function documentation (moving it to the new programming documentation) and leaving it only the user documentation with example. is it ok for you? I'm not exactly sure what do you mean by that. I know that there are different possibilities how to approach this. Can please you provide more examples and describe it more (e.g. draft the rules how doc should be written)? I take as example raster [0]. For RastRow there is a description with example and after start the documentation about RastRow class. I would like to keep the description with example there and move the RastRow class documentation to the new lib/python documentation. This because I think that http://grass.osgeo.org/grass71/manuals/pygrass/ should be for user and the new lib/python documentation is for developers and the two documentations should be separated. Is it more clear now? Thank you, Vaclav [0] http://grass.osgeo.org/grass71/manuals/pygrass/raster.html -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sphinx documentation for lib python
Hi Luca, [snip] I take as example raster [0]. For RastRow there is a description with example and after start the documentation about RastRow class. I would like to keep the description with example there and move the RastRow class documentation to the new lib/python documentation. This because I think that http://grass.osgeo.org/grass71/manuals/pygrass/ should be for user and the new lib/python documentation is for developers and the two documentations should be separated. Is it more clear now? IMHO was pygrass designed to be used by Python developers, hence all the documentation was written for developers. User usually do not write modules with low level map access. :) I wouldn't split the pygrass documentation. We need the examples and the class documentation to actually program with pygrass. Otherwise developers have to search for documentation in two different places. However, i do not really understand why the pygrass documentation belongs into the manual page section? IMHO all library documentation belongs into the programming manual. Best regards Soeren Thank you, Vaclav [0] http://grass.osgeo.org/grass71/manuals/pygrass/raster.html -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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] sphinx documentation for lib python
On Thu, Jun 26, 2014 at 11:50 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Luca, [snip] I take as example raster [0]. For RastRow there is a description with example and after start the documentation about RastRow class. I would like to keep the description with example there and move the RastRow class documentation to the new lib/python documentation. This because I think that http://grass.osgeo.org/grass71/manuals/pygrass/ should be for user and the new lib/python documentation is for developers and the two documentations should be separated. Is it more clear now? IMHO was pygrass designed to be used by Python developers, hence all the documentation was written for developers. User usually do not write modules with low level map access. :) I wouldn't split the pygrass documentation. We need the examples and the class documentation to actually program with pygrass. Otherwise developers have to search for documentation in two different places. Thanks Luca, it is more clear now what you want to do but as Soeren noted we should make clear who are users and who are developers. I usually cannot agree with people's opinions here and there, e.g. on Doxygen mailing list somebody was saying something about commenting Python code in # comments with Doxygen for developers (probably project developers) and then using docstrings for users (developers depending on the code/library, project users). I don't think that these two are separate worlds, especially in cases (like GRASS) when you time to time end up looking to the source code itself. I can agree on having the introduction/tutorial/description of PyGRASS raster classes in different document (HTML page) than the detailed documentation of (all) classes, functions and parameters generated from docstrings. This makes sense to me. However, both these documents (HTML pages) should be part of the same documentation, Sphinx generated documentation of python/lib (grass package) in this case. However, i do not really understand why the pygrass documentation belongs into the manual page section? IMHO all library documentation belongs into the programming manual. If you are speaking about the URL, it is a separate, minor, yet important problem, I believe. Since we decided to have Python documentation separated from C documentation we need separate URLs. We have now this URLs: http://grass.osgeo.org/documentation/manuals/ http://grass.osgeo.org/manuals/ http://grass.osgeo.org/grass71/manuals/ http://grass.osgeo.org/grass71/manuals/pygrass/ http://grass.osgeo.org/programming7/ And we need to change pygrass to python/lib (grass?, grass-python-package?) and also add wxGUI (wxgui?, grass-wxgui-package). Here is my draft: http://grass.osgeo.org/grass71/manuals/programming (for general intro and C (API?) documentation) http://grass.osgeo.org/grass71/manuals/python (for grass package) http://grass.osgeo.org/grass71/manuals/wxgui (for grass wxGUI (not yet?) package) http://grass.osgeo.org/grass71/manuals/[index.html] (standard user documentation) But we should perhaps consider also possibility of having the same documentation in two different formats (user in our HTML, Sphinx HTML, man-like HTML, or perhaps C in Breathe Sphinx, or Python aslo in Doxygen as we have now). This could be solved by having python-doxygen, python-sphinx and python as a simlink to one of them (in case of user doc it might be less straightforward). Vaclav See also: [GRASS-web] Addon manual pages not linked http://lists.osgeo.org/pipermail/grass-web/2013-December/004587.html Best regards Soeren Thank you, Vaclav [0] http://grass.osgeo.org/grass71/manuals/pygrass/raster.html -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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] #2353: v.univar says type not supported instead of column does not exist
#2353: v.univar says type not supported instead of column does not exist
+---
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: trivial | Milestone: 7.1.0
Component: Database| Version: svn-trunk
Keywords: v.univar, vector, messages |Platform: All
Cpu: Unspecified |
+---
G7:v.univar with column which does not exists reports low-level message
no such column tow times together with some other things and than gives
GRASS standard error Column type not supported. It should end after the
first try, not print the low-level (detailed) messages (if possible,
should go to debug), and print the correct error message Column does not
exist (or not found?).
{{{
v.univar map=bridges column='YEAR_BUILTTT'
}}}
{{{
DBMI-SQLite driver error:
Error in sqlite3_prepare():
SELECT cat, YEAR_BUILTTT FROM bridges
no such column: YEAR_BUILTTT
DBMI-SQLite driver error:
Error in sqlite3_prepare():
SELECT cat, YEAR_BUILTTT FROM bridges
no such column: YEAR_BUILTTT
ERROR: Column type not supported
}}}
I was not looking to the source code.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2353
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] new wxgui tool: Temporal plot
On Thu, Jun 26, 2014 at 3:52 PM, Luca Delucchi lucadel...@gmail.com wrote: Hi everybody, I just commit in trunk (r60981) a new tool for wxgui, the Temporal plot. It allows the user to see in a plot the values of one or more temporal datasets (strds, stvds, str3ds) for a queried point defined by a coordinate pair, it can also save directly the plot to an image (so it is possible to run it on a script for several point). nice work, Luca (and thanks to Anna for code cleanup). Here the obligatory screenshot made by Luca: http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/tplot/tplot.png Testing and improvement are really welcome. thanks Markus -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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] Enable compilation with SQLite by deafut
Hi, I just noticed that the default value in ./configure for SQLite support is no. Since sqlite is the default for GRASS 7 wouldn't make sense to have it enabled by default? For example, wxGUI does not even considers missing SQLite as a possibility. I'm not sure if it is right and if modules are more robust. However, to make compilation easier for (compilation) first time users, I suggest to change the default to yes. I don't know how to do it, configure(.in) is still mysterious for me. Thanks, Vaclav ./configure --help | grep sql --with-sqlite support SQLite functionality (default: no) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enable compilation with SQLite by deafut
On Thu, Jun 26, 2014 at 10:06 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, I just noticed that the default value in ./configure for SQLite support is no. Since sqlite is the default for GRASS 7 wouldn't make sense to have it enabled by default? For example, wxGUI does not even considers missing SQLite as a possibility. I'm not sure if it is right and if modules are more robust. However, to make compilation easier for (compilation) first time users, I suggest to change the default to yes. To me that sounds reasonable. I don't know how to do it, configure(.in) is still mysterious for me. Very easy: - in configure.in line 253, take out the , no - then run autoconf-2.13 - run configure ... to test Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enable compilation with SQLite by deafut
On Thu, Jun 26, 2014 at 4:25 PM, Markus Neteler nete...@osgeo.org wrote: On Thu, Jun 26, 2014 at 10:06 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, I just noticed that the default value in ./configure for SQLite support is no. Since sqlite is the default for GRASS 7 wouldn't make sense to have it enabled by default? For example, wxGUI does not even considers missing SQLite as a possibility. I'm not sure if it is right and if modules are more robust. However, to make compilation easier for (compilation) first time users, I suggest to change the default to yes. To me that sounds reasonable. OK, done in r60995 I don't know how to do it, configure(.in) is still mysterious for me. Very easy: - in configure.in line 253, take out the , no - then run autoconf-2.13 - run configure ... to test Thanks, this was really easy, but my understanding is still low. After autoconf2.13, I tested with make distclean, configure and make. Vaclav http://trac.osgeo.org/grass/changeset/60995 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2037: i.gensig cannot create signature file
#2037: i.gensig cannot create signature file +--- Reporter: venkat | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 6.4.5 Component: wxGUI | Version: 6.4.3 RCs Keywords: i.gensig, l12n |Platform: MSWindows 8 Cpu: x86-64 | +--- Changes (by neteler): * milestone: 6.4.3 = 6.4.5 Comment: Does the problem persist with 6.4.4? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2037#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] Rast_open_update?
Hi Soeren, Ah! You're right. Cell files have pointers to rows in the header, so maybe, we could implement functions that can copy multiple rows at a time without uncompressing/compressing them row by row even if MASK may not be applied properly. This is not a true update, but at least copy can be more efficient than now. Regards, Huidae On Thu, Jun 26, 2014 at 9:30 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Huidae, FWIK, the reason why updating raster maps is currently not supported in GRASS at the module level is the storage format. Usually raster maps are stored using zip compressed rows. Rows are written in serial, hence if you modify a single row, the size of this row may be different after compression and does not fit exactly in the position of the old row in the existing file. From my knowledge there is currently no way to append rows or mark rows as invalid in existing raster maps. However, there is the possibility to store raster maps using uncompressed rows, but i don't recall any raster library function to update such maps. Best regards Soeren 2014-06-26 15:05 GMT+02:00 Huidae Cho gras...@gmail.com: Whenever I change a couple of cells in an existing raster map, I have to create a new raster map and patch the old and new maps, which can take long because r.patch has to read and write the entire map. There are Rast_open_old/new, but no Rast_open_update and AFAIK there are no raster modules that directly update existing raster maps. I don't know why. I thought it would be great if there was Rast_open_update so we can update existing raster maps without creating a temp map and patching it. ___ 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
