Re: [GRASS-dev] developing a GUI wxgrass-based
Jaime, all, On Tue, Apr 8, 2008 at 12:05 AM, Jaime Carrera [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could give me some kind of orientation on how wxgrass accesses the list of raster/vector maps and both the tables and columns for the latter. I've gone through the code a couple of times, but I'm missing something. I have no answer for you but I report an email from Howard Butler here (GDAL Python guru) which might be (partially) relevant to improve our code documentation. Perhaps I am wrong and it's all fine.. no idea :-) Here we go: [ http://lists.osgeo.org/pipermail/discuss/2008-April/003345.html ] On Mon, Apr 7, 2008 at 4:26 PM, Howard Butler [EMAIL PROTECTED] wrote: Markus Neteler wrote: Hi OSGeo, I would like to propose another idea which might be a (long term) goal of OSGeo software development: OSGeo Python Library http://wiki.osgeo.org/wiki/OSGeo_Python_Library Currently it is quite complex to set up a Python based OSGeo software environment without knowing well the individual projects. It would be great to have a common abstraction layer/API which contains binding to several relevant OSGeo and related software projects with Python bindings to simplify programming. Hacks to the Wiki page and comments welcome, ... I think the most fruitful way to make it easier for folks to be able to use Python for geo stuff is to ensure that projects do the following: 1) Embrace PyPI. I made a major push with GDAL 1.5 to allow it to be built from *outside* the GDAL source tree. This means that a user can install gdal-bin and gdal-devel with their favorite package management system and then do easy_install GDAL and have working bindings. I would like to get Python MapScript to this point as well, but doing so will require a bit more effort than GDAL to get MapServer's source tree in shape (MapServer isn't really split into -devel and -bin, it's all just a big ball right now). Projects that aspire to be on PyPI and be easier to use from a Python perspective should ensure they're using Python distutils/setuptools and not require that an entire source tree of dependencies be available to build themselves. 2) Leverage Python docstrings. I also made a lot of effort to include Python docstrings in the OGR 1.5 release. I haven't gotten to GDAL's yet, but I hope to in the future. doctests, which are Python's name for combining documentation with regression testing, are also an excellent way to provide leverage. Python users have been heavily conditioned to look for doctests/docstrings in other Python libraries, and the OSGeo camp should follow suit. 3) Support things like __geo_interface__ and numpy's array interface. Python makes it so easy for everyone to write their own that everyone does. There are bits that everyone can agree on, and those are the points at which easy integration of the various libraries can be made. Howard ___ Discuss mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/discuss ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Proposal: OSGeo Cartographic Library
Dear all, I am not sure in how far this directly relates to the OSGeo Cartographic Library, but I have a feeling it does somehow: At my company, we are currently trying to phase out all closed source GIS tools that could potentially create vendor lock-ins and thus result in unpredictable financial risks and loss of flexibility. With the in-house workflow soon to be based on open standards and protocols plus XML files for complex GIS projects, we still face the problem of ESRI map documents (MXD format) project files. Sometimes clients want to get MXD project files along with the geodata and sometimes legal requirements force us to renew project application with maps based on the same MXD layouts as previous hand-ins. Unfortunately, MXD is a closed, binary format and ESRI have removed support for export/import of old ASCII ArcView project files from ArcMap, managing to create a sweet lock-in trap. I could not find a file format specification for MXD and neither any open source project that tries to reverse-engineer it. So my question is: How feasible do you think it would be to create open standards for a) GIS projects (layer names, data sources, grouping) b) layer style files (opacity, categories, colour schemes) c) feature labels (fonts, halos, label coords, rotation and size) ? Once such standards have been established and widely adopted, ESRI and others might be forced to implement them in their products, much like WMS, WFS and PostGIS support. Cheers, Benjamin Glynn Clements wrote: Markus Neteler wrote: (just submitted to OSGeo-Discuss) I would like to launch the idea of an OSGeo Cartographic Library to share concepts, source code and regression tests: http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library GRASS, QGIS and others are in the need of own map printing tools for high quality output but these projects should not start from scratch. There is a wealth of underlying code already in Mapserver, Mapguide etc which could be re-used in the terms of their respective licenses and certainly of programming language compatibility. Please hack the wiki page and post your ideas. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] developing a GUI wxgrass-based
Hi,
2008/4/8, Markus Neteler [EMAIL PROTECTED]:
I was wondering if someone could give me some kind of orientation on
how wxgrass accesses the list of raster/vector maps and both the
take a look at 'render' module (class 'Map' and 'Layer').
tables and columns for the latter. I've gone through the code a
you mean attribute data of vector map layers (?) ('dbm' module)
couple of times, but I'm missing something.
Markus:
I have no answer for you but I report an email from Howard Butler
here (GDAL Python guru) which might be (partially) relevant to improve
our code documentation. Perhaps I am wrong and it's all fine.. no idea :-)
For sure there are thousand of issues to be improved;-)
Martin
Here we go:
[ http://lists.osgeo.org/pipermail/discuss/2008-April/003345.html ]
On Mon, Apr 7, 2008 at 4:26 PM, Howard Butler [EMAIL PROTECTED] wrote:
Markus Neteler wrote:
Hi OSGeo,
I would like to propose another idea which might be a (long term) goal
of OSGeo software development:
OSGeo Python Library
http://wiki.osgeo.org/wiki/OSGeo_Python_Library
Currently it is quite complex to set up a Python based OSGeo software
environment without knowing well the individual projects. It would be
great
to have a common abstraction layer/API which contains binding to
several
relevant OSGeo and related software projects with Python bindings to
simplify programming.
Hacks to the Wiki page and comments welcome,
...
I think the most fruitful way to make it easier for folks to be able to
use
Python for geo stuff is to ensure that projects do the following:
1) Embrace PyPI. I made a major push with GDAL 1.5 to allow it to be
built
from *outside* the GDAL source tree. This means that a user can install
gdal-bin and gdal-devel with their favorite package management system and
then do easy_install GDAL and have working bindings. I would like to get
Python MapScript to this point as well, but doing so will require a bit
more
effort than GDAL to get MapServer's source tree in shape (MapServer isn't
really split into -devel and -bin, it's all just a big ball right now).
Projects that aspire to be on PyPI and be easier to use from a Python
perspective should ensure they're using Python distutils/setuptools and not
require that an entire source tree of dependencies be available to build
themselves.
2) Leverage Python docstrings. I also made a lot of effort to include
Python docstrings in the OGR 1.5 release. I haven't gotten to GDAL's yet,
but I hope to in the future. doctests, which are Python's name for
combining documentation with regression testing, are also an excellent way
to provide leverage. Python users have been heavily conditioned to look
for
doctests/docstrings in other Python libraries, and the OSGeo camp should
follow suit.
3) Support things like __geo_interface__ and numpy's array interface.
Python makes it so easy for everyone to write their own that everyone does.
There are bits that everyone can agree on, and those are the points at
which
easy integration of the various libraries can be made.
Howard
___
Discuss mailing list
[EMAIL PROTECTED]
http://lists.osgeo.org/mailman/listinfo/discuss
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Proposal: OSGeo Cartographic Library
[EMAIL PROTECTED] ha scritto: How feasible do you think it would be to create open standards for a) GIS projects (layer names, data sources, grouping) b) layer style files (opacity, categories, colour schemes) c) feature labels (fonts, halos, label coords, rotation and size) Partial response: SLD? http://www.opengeospatial.org/standards/sld pc -- Paolo Cavallini, see: http://www.faunalia.it/pc Noi ci troviamo con parecchie difficoltà con NGI http://www.ngi.it/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.out.gmap: export raster to Google Map tiles
On Tue, Apr 8, 2008 at 11:23 AM, Hamish [EMAIL PROTECTED] wrote: Tomas Cebecauer wrote: Note that modul has to be run from LOCATION with correct mercator projection used by google maps (epsg 900913). note that GRASS does not currently include /usr/share/proj/esri.extra (and other unofficial add-on EPSG codes in that dir) in $GISBASE/etc/ogr_csv/*, so you can't use 'g.proj -c epsg=900913' to create the location. Note sure, works for me: GRASS 6.3.svn (spearfish60):~ g.proj -c epsg=900913 loc=tets Location tets created! cd grassdata/tets/PERMANENT [EMAIL PROTECTED] PERMANENT]$ cat PROJ_INFO name: Mercator proj: merc datum: wgs84 ellps: wgs84 lat_ts: 0.0 lon_0: 0.0 x_0: 0.0 y_0: 0 k: 1.0 nadgrids: @null wktext: defined no_defs: defined Compare: cd /usr/local/share/proj grep 900913 esri.extra 900913 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m [EMAIL PROTECTED] +wktext +no_defs cs2cs -le | grep -i WGS84 WGS84 a=6378137.0 rf=298.257223563 WGS 84 Doesn't look so bad? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GForge tickets Trac
Markus Neteler pisze: Sascha fixed XML export of GForge today (thanks!): http://wald.intevation.org/export/tracker.php?group_id=21atid=204 Now we need to process this XML to generate something useful for trac. I'm sorry but I don't have much spare time until mid-summer or so (work work work). I won't be able to help much until then. Please anybody willing to port existing GForge tickets to Trac do it. Maciek ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sqlite and grass64
Maciej Sieczka pisze: FWIW SQLite Administrator looks very interesting [1]. From their screendumps it resembles PgAdmin much. Am I blind or what? Windows only, closed source. Yuck. Sorry. Maciek ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sqlite and grass64
Maciej Sieczka ha scritto: Maciej Sieczka pisze: FWIW SQLite Administrator looks very interesting [1]. From their screendumps it resembles PgAdmin much. Am I blind or what? Windows only, closed source. Yuck. Sorry. on the other hand, spatialite is gpl3 (and very cool!) pc -- Paolo Cavallini, see: http://www.faunalia.it/pc Noi ci troviamo con parecchie difficoltà con NGI http://www.ngi.it/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sqlite and grass64
It seems to me that wxSQLite+ might be a good option to manage SQLite dbs. http://cfred.free.fr/wxsqliteplus.php Jaime On Tue, Apr 8, 2008 at 7:23 AM, Maciej Sieczka [EMAIL PROTECTED] wrote: Michael Barton pisze: SQLite Browser is a light-weight application that we could package with GRASS if we wanted to switch to SQLite before making wxPython the default GUI. It's nice, but my concern with it is that is appears not to have been updated for a couple years. I found one other free tool for the Mac to access SQLite databases (a couple others to manage them only). There seems to be more available for Windows and Linux. FWIW SQLite Administrator looks very interesting [1]. From their screendumps it resembles PgAdmin much. (Un)Related cool stuff I just found - SpatialLite [2]. It aims to be same thing for SQLite as PostGIS is for PostgreSQL. Maybe an inspiration for a new GRASS vector format someday? [1]http://sqliteadmin.orbmu2k.de/ [2]http://www.gaia-gis.it/spatialite ___ 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] G_exp_colors()?
Hamish wrote: the problem is the data is 90% done by 0.4, but the colr/ rules are only written out on integer values Ah. Does the attached patch fix the problem? -- Glynn Clements [EMAIL PROTECTED] Index: lib/gis/color_xform.c === --- lib/gis/color_xform.c (revision 30880) +++ lib/gis/color_xform.c (working copy) @@ -165,7 +165,7 @@ x = exp(lx); if (i 0) - G_add_color_rule(prev, red, grn, blu, x, red2, grn2, blu2, dst); + G_add_d_raster_color_rule(prev, red, grn, blu, x, red2, grn2, blu2, dst); prev = x; ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: what if: a new GRASS directory layout?
Glynn Clements [EMAIL PROTECTED] writes: Full transaction support would be nice, but I don't know if it's worth the substantial effort involved in implementing it. BTW, what do you mean by full transaction support here? Actually, I was referring specifically to atomicity, i.e. being able to replace a single map atomically, with no interval where the map doesn't exist or is in an inconsistent state. ACK. I suppose that there are cases where it might be useful to be able to update multiple maps atomically, but that's even more work (you would need an inventory for the entire mapset, not just for indivdual maps). Since the scheme I've suggested reduces a raster to a structured inventory and a set of uniquely-named binary objects, it looks RDBMS-friendly as well. I wish I had the time to explore putting some GRASS rasters into an PostgreSQL database! In any case, all of these mechanisms would require substantial changes to a large number of modules. I'll try to check whether I could make the new layout available under the old API as well. The main problem is that a module reads a map via several calls. All of those calls must see the same map. I initially thought that you would need some form of locking, to prevent the map from being replaced in the middle of the sequence. However, you could achieve the same result by caching the inventory within the module, but the code which garbage-collects unreferenced elements would need to allow for this. Yes. The need for GC seems to be the weekest point of this scheme. On Unix, as a first approximation, I'd just open () every binary object that's referenced by the inventory being processed. This way, even if the file loses its name, it would be available to the program. In general, every binary object would need a list of references. Maintaining a list of names of referencing rasters shouldn't be too hard to implement. On the contrary, a list of PIDs (to allow for a raster to be referenced by a process) looks a bit fragile. Even there, you could run into problems where a module invokes another module; the child would need to use the same version of the map as the parent. Agreed. Actually, the only proper solution to this problem that I know is moving the whole computation chain into a ``parallel existence'' -- forking a separate copy-on-write location at the beginning of a ``transaction block'', and merging it back when it's done. And while I hope that something like this will eventually be available in GRASS, I probably wouldn't say that the current code base is anywhere near that. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats under WINGRASS
On 08/04/08 18:04, Niels Thevs wrote: Dear GRASS users, I am using WINGRASS 6.3 (RC5) and tried the command v.rast.stats. But I encountered the error messages below, though the vector and raster are in the same mapset. [EMAIL PROTECTED] is not in the current mapset (PERMANENT) An error occurred while converting vector to raster G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) [EMAIL PROTECTED] is not in the current mapset (PERMANENT) Does anybody know, how to overcome this problem ? This was fixed by Hamish here http://trac.osgeo.org/grass/changeset/30136 but apparently it did not get backported. A quick fix for you is to click on the command in the Output window, so that you can edit it at the bottom and change the [EMAIL PROTECTED] into vector=split1 and then push 'Run'. A more permanent fix is to download the current version of the script from here: http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats and replace you $GISBASE/scripts/v.rast.stats with the downloaded file. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats under WINGRASS
On 08/04/08 23:03, Moritz Lennert wrote: On 08/04/08 18:04, Niels Thevs wrote: Dear GRASS users, I am using WINGRASS 6.3 (RC5) and tried the command v.rast.stats. But I encountered the error messages below, though the vector and raster are in the same mapset. [EMAIL PROTECTED] is not in the current mapset (PERMANENT) An error occurred while converting vector to raster G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) [EMAIL PROTECTED] is not in the current mapset (PERMANENT) Does anybody know, how to overcome this problem ? This was fixed by Hamish here http://trac.osgeo.org/grass/changeset/30136 but apparently it did not get backported. Sorry, I correct myself: it was backported to RC6, so just install that version and you should be fine. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats underWINGRASS
Hi Moritz, Moritz, does it probably has been fixed in RC6? Niels, could you download and install WinGRASS-6.3.0RC6 (before uninstall RC5 using Add/Remove programs utility) and check if v.rast.stats works in it? Thanks Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Moritz Lennert Inviato: martedì 8 aprile 2008 23.03 A: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; GRASS devel; Hamish Oggetto: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats underWINGRASS On 08/04/08 18:04, Niels Thevs wrote: Dear GRASS users, I am using WINGRASS 6.3 (RC5) and tried the command v.rast.stats. But I encountered the error messages below, though the vector and raster are in the same mapset. [EMAIL PROTECTED] is not in the current mapset (PERMANENT) An error occurred while converting vector to raster G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) G__open(r): mapset (PERMANENT) doesn't match xmapset (PERMANENT_3280.0) [EMAIL PROTECTED] is not in the current mapset (PERMANENT) Does anybody know, how to overcome this problem ? This was fixed by Hamish here http://trac.osgeo.org/grass/changeset/30136 but apparently it did not get backported. A quick fix for you is to click on the command in the Output window, so that you can edit it at the bottom and change the [EMAIL PROTECTED] into vector=split1 and then push 'Run'. A more permanent fix is to download the current version of the script from here: http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast. stats and replace you $GISBASE/scripts/v.rast.stats with the downloaded file. Moritz ___ 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] g.mapsets revision 30712
On Sat, Apr 5, 2008 at 1:16 AM, Glynn Clements [EMAIL PROTECTED] wrote: Martin Landa wrote: 2008/4/4, Markus Neteler OSGeo [EMAIL PROTECTED]: r30712 | martinl | 2008-03-24 11:19:11 + (Mon, 24 Mar 2008) | 2 lines g.mapsets: (cosmetics) message cleaning, some minor changes in manual, tcl/tk-related code removed Glynn: Presumably g.mapsets.tcl should be removed, now that it is no longer used. The CMD line version of g.mapsets is lacking a parameter to remove (multiple) mapsets from the search path. This should be added before removing the Tcl version. I tried but got lost in the tokenizer. try the attached patch (for review), Martin I should probably have read this message before going ahead and making my own patch as soon as I read Markus' message. Thanks for your quick replies! Please submit the final version for testing to SVN... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: what if: a new GRASS directory layout?
Ivan Shmakov wrote: I initially thought that you would need some form of locking, to prevent the map from being replaced in the middle of the sequence. However, you could achieve the same result by caching the inventory within the module, but the code which garbage-collects unreferenced elements would need to allow for this. Yes. The need for GC seems to be the weekest point of this scheme. On Unix, as a first approximation, I'd just open () every binary object that's referenced by the inventory being processed. This way, even if the file loses its name, it would be available to the program. However: while updates to the cell/fcell file are atomic (new data is written to a temporary file which is rename()d upon closing), support files are typically updated by simply opening the output file for write. If the output file already exists, it is overwritten in place. Obviously, that would need to change in order for transactional I/O to work. The fact that individual modules can create their own private files in cell_misc complicates matters. BTW, the definition of support file includes the cellhd file, which is rather fundamental, as the layout of the cell/fcell file (rows, columns, format, compression) is stored in the cellhd file. If the contents of the cellhd file don't match the cell/fcell file, libgis will probably just crash. In general, every binary object would need a list of references. Maintaining a list of names of referencing rasters shouldn't be too hard to implement. On the contrary, a list of PIDs (to allow for a raster to be referenced by a process) looks a bit fragile. In-process references could be maintained by making a copy (or hard link) to the inventory, so that the GC treats it as live. You would need some kind of clean-up mechanism to handle any copies which are left behind if a module crashes. Even there, you could run into problems where a module invokes another module; the child would need to use the same version of the map as the parent. Agreed. Actually, the only proper solution to this problem that I know is moving the whole computation chain into a ``parallel existence'' -- forking a separate copy-on-write location at the beginning of a ``transaction block'', and merging it back when it's done. And while I hope that something like this will eventually be available in GRASS, I probably wouldn't say that the current code base is anywhere near that. Yep. For the time being, I'd settle for simply re-arranging the database layout to have one directory per map. [BTW, it has been pointed out that this can reduce the maximum number of maps per mapset, as the limit on an inode's hard link count limits the maximum number of subdirectories, while there is usually no fixed limit on the number of files. E.g. on Linux' ext2fs, the maximum hard link count is 65535, so you can't have more than 65533 subdirectories.] -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #70: imagery modules: strip @mapset part
#70: imagery modules: strip @mapset part --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: |Keywords: imagery --+- Comment (by glynn): Replying to [comment:4 glynn]: I have attached a more extensive version of the previous patch. attachment:ticket:70:imagery-mapset.patch This should cover all of the cases where filenames were being constructed manually. There remains the issue that the imagery library can only handle groups in the current mapset, for both read and write. Most of that could be fixed by replacing G_mapset() with . However, the I_find_* functions really need _new and _old versions, as (unlike the G_find_* functions) they don't accept a mapset argument. -- Ticket URL: http://trac.osgeo.org/grass/ticket/70#comment:5 GRASS GIS http://grass.osgeo.org GRASS Geographic Information System (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_exp_colors()?
Hamish wrote: the problem is the data is 90% done by 0.4, but the colr/ rules are only written out on integer values Glynn: Ah. Does the attached patch fix the problem? yes, it does. thanks. There are still slight differences (white spots), G63 r.info -r A20023352002365.L3m_MO_CHLO_4.chlor_A min=0.01 max=64.565418 G63 r.colors A20023352002365.L3m_MO_CHLO_4.chlor_A col=bcyr -g G63 cat colr/A20023352002365.L3m_MO_CHLO_4.chlor_A % 0.010003677613769071 64.565417527653337970150460023433 nv:255 *:255 0.010003677613769071:0:0:255 0.0109169168:0:7:255 0.0109169168:0:7:255 0.0119179072:0:15:255 0.0119179072:0:15:255 0.0130106801:0:22:255 0.0130106801:0:22:255 0.0142036512:0:30:255 0.0142036512:0:30:255 0.0155060078:0:38:255 0.0155060078:0:38:255 0.0169277797:0:45:255 0.0169277797:0:45:255 0.0184799162:0:53:255 49.6249366001:255:23:0 54.1751303026:255:16:0 54.1751303026:255:16:0 59.1425389006:255:8:0 59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0 the lowest values are less than the first color rule so they display as white. As do the max cell values which are slightly bigger than the color rule number with excessive number of decimal digits. replace r.colors/rules.c %.25f with %.15g or %.16g ? http://article.gmane.org/gmane.comp.gis.grass.devel/25291 Hamish You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #118: r.patch fails on WinGRASS RC6 and earlier
#118: r.patch fails on WinGRASS RC6 and earlier --+- Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: default | Version: unspecified Keywords:| --+- Students in my class have just discovered that r.patch fails under WinGRASS. The GUI won't launch and it gives an error from the command line. The errors are none-specific in both cases, making it difficult to understand what is going wrong. This happened on RC4 and is still a problem on the new RC6 version. Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/118 GRASS GIS http://grass.osgeo.org GRASS Geographic Information System (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_exp_colors()?
Hamish wrote:
the problem is the data is 90% done by 0.4, but the colr/ rules
are only written out on integer values
Glynn:
Ah. Does the attached patch fix the problem?
yes, it does. thanks.
There are still slight differences (white spots),
G63 r.info -r A20023352002365.L3m_MO_CHLO_4.chlor_A
min=0.01
max=64.565418
G63 r.colors A20023352002365.L3m_MO_CHLO_4.chlor_A col=bcyr -g
G63 cat colr/A20023352002365.L3m_MO_CHLO_4.chlor_A
% 0.010003677613769071 64.565417527653337970150460023433
nv:255
*:255
0.010003677613769071:0:0:255 0.0109169168:0:7:255
0.0109169168:0:7:255 0.0119179072:0:15:255
0.0119179072:0:15:255 0.0130106801:0:22:255
0.0130106801:0:22:255 0.0142036512:0:30:255
0.0142036512:0:30:255 0.0155060078:0:38:255
0.0155060078:0:38:255 0.0169277797:0:45:255
0.0169277797:0:45:255 0.0184799162:0:53:255
49.6249366001:255:23:0 54.1751303026:255:16:0
54.1751303026:255:16:0 59.1425389006:255:8:0
59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0
the lowest values are less than the first color rule so they display as
white. As do the max cell values which are slightly bigger than the color
rule number with excessive number of decimal digits.
Bear in mind that r.info -r is approximating the min/max values to 6
decimal places. The actual min/max will be much closer to the values
in the first line of the colr file. IEEE double is ~15 significant
decimal digits.
replace r.colors/rules.c %.25f with %.15g or %.16g ?
http://article.gmane.org/gmane.comp.gis.grass.devel/25291
That won't help at all. Excess digits in the decimal representation
won't do any harm; excess precision just gets discarded when the file
is read in.
Given that this seems to be specific to the use of G_log_colors(), I
suspect that the problem is due to slight errors in the calculation:
lx = lmin + (lmax - lmin) * i / samples;
x = exp(lx);
Theoretically:
i == 0:
lx = lmin + (lmax - lmin) * 0 / samples
= lmin + (lmax - lmin) * 0
= lmin
x = exp(lx)
= exp(lmin)
= min
i == samples:
lx = lmin + (lmax - lmin) * samples / samples;
= lmin + (lmax - lmin) * 1;
= lmin + lmax - lmin;
= lmax
x = exp(lx)
= exp(lmax)
= max
However, real arithmetic and floating-point arithmetic aren't quite
the same thing, and even the slightest error will cause the tests in
the lookup code to fail.
I can modify G_log_colors() to use special cases for i==0 and
i==samples (see attached patch).
Another option would be to add an extra rule at each end, so that any
values which are slightly out of range (by how much?) just use the end
colours.
But I'm wondering if it would be better to handle this in the lookup
code, i.e. whether there should be an option for out-of-range colours
to use the colour for the corresponding extreme (min or max).
--
Glynn Clements [EMAIL PROTECTED]
Index: lib/gis/color_xform.c
===
--- lib/gis/color_xform.c (revision 30909)
+++ lib/gis/color_xform.c (working copy)
@@ -161,8 +161,15 @@
y = min + (max - min) * i / samples;
G_get_d_raster_color(y, red2, grn2, blu2, src);
- lx = lmin + (lmax - lmin) * i / samples;
- x = exp(lx);
+ if (i == 0)
+ x = min;
+ else if (i == samples)
+ x = max;
+ else
+ {
+ lx = lmin + (lmax - lmin) * i / samples;
+ x = exp(lx);
+ }
if (i 0)
G_add_d_raster_color_rule(prev, red, grn, blu, x, red2, grn2,
blu2, dst);
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: what if: a new GRASS directory layout?
Glynn Clements [EMAIL PROTECTED] writes: I initially thought that you would need some form of locking, to prevent the map from being replaced in the middle of the sequence. However, you could achieve the same result by caching the inventory within the module, but the code which garbage-collects unreferenced elements would need to allow for this. Yes. The need for GC seems to be the weekest point of this scheme. On Unix, as a first approximation, I'd just open () every binary object that's referenced by the inventory being processed. This way, even if the file loses its name, it would be available to the program. However: while updates to the cell/fcell file are atomic (new data is written to a temporary file which is rename()d upon closing), support files are typically updated by simply opening the output file for write. If the output file already exists, it is overwritten in place. Obviously, that would need to change in order for transactional I/O to work. Yes. With the new scheme, objects/ may be created in place, but musn't ever be overwritten. The fact that individual modules can create their own private files in cell_misc complicates matters. BTW, the definition of support file includes the cellhd file, which is rather fundamental, as the layout of the cell/fcell file (rows, columns, format, compression) is stored in the cellhd file. If the contents of the cellhd file don't match the cell/fcell file, libgis will probably just crash. Agreed. In general, every binary object would need a list of references. Maintaining a list of names of referencing rasters shouldn't be too hard to implement. On the contrary, a list of PIDs (to allow for a raster to be referenced by a process) looks a bit fragile. In-process references could be maintained by making a copy (or hard link) to the inventory, so that the GC treats it as live. You would need some kind of clean-up mechanism to handle any copies which are left behind if a module crashes. However, having GC to process all the inventories won't be efficient (unless these are stored in a database's table with appropriate indices.) So, I had in mind keeping a references file along with each object file. But well, creating a temporary inventory to hold all the objects may help, e. g.: $ cat tmp/refs/r.mapcalc-26528.1 References: sO7dZ3p0hlA6iQGMN, EwqVK4sVoFq1bFK7y, KkUET1RdWlwXQxosV, ajK3kbLfQu3a4Osuq, 8isdA0FB3GCmP15JV, qJaJuz2k7hJKMvRIK $ cat objects/sO7dZ3p0hlA6iQGMN.refs 2005-04-25T19+-mod09-reflectance-250m-band-1 tmp/refs/r.mapcalc-26528.1 tmp/refs/r.univar-8974.1 $ There's still a locking issue regarding the `.refs' -- it needs to be handled if multiple processes try to update the file concurrently. Any ideas on how to implement it portably? (Perhaps it will be worth looking into, e. g., the SQLite source.) Even there, you could run into problems where a module invokes another module; the child would need to use the same version of the map as the parent. Agreed. Actually, the only proper solution to this problem that I know is moving the whole computation chain into a ``parallel existence'' -- forking a separate copy-on-write location at the beginning of a ``transaction block'', and merging it back when it's done. And while I hope that something like this will eventually be available in GRASS, I probably wouldn't say that the current code base is anywhere near that. Yep. For the time being, I'd settle for simply re-arranging the database layout to have one directory per map. [BTW, it has been pointed out that this can reduce the maximum number of maps per mapset, as the limit on an inode's hard link count limits the maximum number of subdirectories, while there is usually no fixed limit on the number of files. E.g. on Linux' ext2fs, the maximum hard link count is 65535, so you can't have more than 65533 subdirectories.] While the inventory scheme is free from hitting this limit. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_exp_colors()?
Hamish: There are still slight differences (white spots), G63 r.info -r A20023352002365.L3m_MO_CHLO_4.chlor_A min=0.01 max=64.565418 G63 r.colors A20023352002365.L3m_MO_CHLO_4.chlor_A col=bcyr -g G63 cat colr/A20023352002365.L3m_MO_CHLO_4.chlor_A % 0.010003677613769071 64.565417527653337970150460023433 nv:255 *:255 0.010003677613769071:0:0:255 0.0109169168:0:7:255 0.0109169168:0:7:255 0.0119179072:0:15:255 54.1751303026:255:16:0 59.1425389006:255:8:0 59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0 the lowest values are less than the first color rule so they display as white. As do the max cell values which are slightly bigger than the color rule number with excessive number of decimal digits. Glynn: Bear in mind that r.info -r is approximating the min/max values to 6 decimal places. The actual min/max will be much closer to the values in the first line of the colr file. IEEE double is ~15 significant decimal digits. Ok, right. FWIW in this case min is set from (double)10^-2, so should be as near to that as doubles can get. Given that this seems to be specific to the use of G_log_colors(), is it? for the same data 'r.colors -e color=bcyr' only gets half way through the data range: % 0 39 nv:255 *:255 0:127:255:128 1:255:1:0 1:255:1:0 2:255:1:0 2:255:1:0 5:255:1:0 5:255:1:0 6:255:1:0 6:255:1:0 7:255:1:0 7:255:1:0 10:255:1:0 10:255:1:0 11:255:1:0 11:255:1:0 16:255:1:0 16:255:1:0 22:255:1:0 22:255:1:0 39:255:1:0 I suspect that the problem is due to slight errors in the calculation: However, real arithmetic and floating-point arithmetic aren't quite the same thing, and even the slightest error will cause the tests in the lookup code to fail. I can modify G_log_colors() to use special cases for i==0 and i==samples (see attached patch). Yes, that worked, this is the new colr/ file: % 0.01208166817117 64.565417527653323759295744821429 nv:255 *:255 0.01208166817117:0:0:255 0.0109169168:0:7:255 0.0109169168:0:7:255 0.0119179072:0:15:255 0.0119179072:0:15:255 0.0130106801:0:22:255 0.0130106801:0:22:255 0.0142036512:0:30:255 45.4569157251:255:31:0 49.6249366001:255:23:0 49.6249366001:255:23:0 54.1751303026:255:16:0 54.1751303026:255:16:0 59.1425389006:255:8:0 59.1425389006:255:8:0 64.565417527653323759295744821429:255:0:0 or diff'd with the previous (r30909, G_add_d_..()): - % 0.010003677613769071 64.565417527653337970150460023433 + % 0.01208166817117 64.565417527653323759295744821429 ... - 0.010003677613769071:0:0:255 0.0109169168:0:7:255 + 0.01208166817117:0:0:255 0.0109169168:0:7:255 0.0109169168:0:7:255 0.0119179072:0:15:255 ... 54.1751303026:255:16:0 59.1425389006:255:8:0 - 59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0 + 59.1425389006:255:8:0 64.565417527653323759295744821429:255:0:0 but now -g does bad things to the original CELL 0-65534 map: (66535 is no-data, already reset to be NULL) % 0 -1 nv:255 *:255 nan:0:7:255 0:0:0:255 nan:0:15:255 nan:0:7:255 nan:0:22:255 nan:0:15:255 nan:255:23:0 nan:255:31:0 nan:255:16:0 nan:255:23:0 nan:255:8:0 nan:255:16:0 65534:255:0:0 nan:255:8:0 should it be like if (i == 0) - x = min; + x = exp(lmin); etc. ? Another option would be to add an extra rule at each end, so that any values which are slightly out of range (by how much?) just use the end colours. But I'm wondering if it would be better to handle this in the lookup code, i.e. whether there should be an option for out-of-range colours to use the colour for the corresponding extreme (min or max). you will see in the above colr/ file examples there is: nv:255 *:255 nv: is the color to use for null values, *: is the color to use for out of range. (a single number there expands to n:n:n greyscale) if we go slightly beyond min/max we will damage the *: functionality. Hamish You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
