From michael.barton at asu.edu Fri Dec 1 00:11:59 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Dec 1 00:12:19 2006 Subject: [GRASS-dev] are we ready for a 6.2.1 release? In-Reply-To: <20061130202414.58b07f53.hamish_nospam@yahoo.com> Message-ID: On 11/30/06 12:24 AM, "Hamish" wrote: > Now that the gis.m startup error message problem is (fingers crossed) > dealt with, are there any other outstanding issues holding back a 6.2.1 > release? These should be critical bug fixes only. > > Due to badly broken ps.map in 6.2.0 and the common hard to understand > gis.m startup error message, I'd hope for a release soon. It is now 30 > days since 6.2.0 was released (and that's a nice round number). As far as I know, we're pretty stable. OK from my perspective. I've only been breaking NVIZ for 6.3 ;-) Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Fri Dec 1 00:09:36 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Dec 1 00:13:24 2006 Subject: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/gui/tcltk/gis.m mapcanvas.tcl, 1.52, 1.53 In-Reply-To: <20061130194556.65949e80.hamish_nospam@yahoo.com> References: <20061129202905.68d9489b.hamish_nospam@yahoo.com> <20061130194556.65949e80.hamish_nospam@yahoo.com> Message-ID: <17775.25776.520735.847279@cerise.gclements.plus.com> Hamish wrote: > oh, and FWIW I figured out why my tcl exec solution was failing with: > ERROR: region <> not found > It was trying to run `g.region ""` (expands to `g.region region=""`) > > It's redundant now, but for the record adding a "concat" fixed it: > > -set regcmd [list exec "g.region" "-ug" $args] > +set regcmd [list exec "g.region" [concat "-ug " $args]] > set retval [catch $regcmd result] This is bogus. It will fail if $args isn't empty: % set args {foo bar baz} % set regcmd [list exec "g.region" [concat "-ug " $args]] % puts $regcmd exec g.region {-ug foo bar baz} % set args foo % set regcmd [list exec "g.region" [concat "-ug " $args]] % puts $regcmd exec g.region {-ug foo} IOW, the entire list of arguments (including the "-ug") will be passed to g.region as a single argument. I'm guessing that you're focusing on the case where $args is empty: % set args "" % set regcmd [list exec "g.region" "-ug" $args] % puts $regcmd exec g.region -ug {} % set args "" % set regcmd [list exec "g.region" [concat "-ug " $args]] % puts $regcmd exec g.region -ug If so, the correct fix is: set regcmd [concat exec g.region -ug $args] E.g.: % set args "" % set regcmd [concat exec g.region -ug $args] % puts $regcmd exec g.region -ug % set args foo % set regcmd [concat exec g.region -ug $args] % puts $regcmd exec g.region -ug foo % set args {foo bar baz} % set regcmd [concat exec g.region -ug $args] % puts $regcmd exec g.region -ug foo bar baz NOTE: if a procedure's last formal argument is named "args", it is treated specially: $args will be a list containing all of the remaining arguments. This allows variadic procedures to be implemented. If you are passing a list of arguments as a list (rather than as individual arguments), use a name other than "args". Otherwise, the list will get "wrapped" inside another list. Only use "args" as an argument variable if the procedure is supposed to be variadic. -- Glynn Clements From glynn at gclements.plus.com Fri Dec 1 00:31:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Dec 1 00:31:03 2006 Subject: [GRASS-dev] Clicking on a text layer in GIS manager gives tcl error In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55C69@s5-dar-r1.nrn.nrcan.gc.ca> References: <0E5A77B55A57D511BB3F0002A537C26208C55C66@s5-dar-r1.nrn.nrcan.gc.ca> <0E5A77B55A57D511BB3F0002A537C26208C55C69@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <17775.27060.959866.517681@cerise.gclements.plus.com> Patton, Eric wrote: > > > If I add a text layer to gis.m and click on it, I get the following error: > > > > > > invalid command name "<<<<<<<" > > > invalid command name "<<<<<<<" > > > while executing > > > "<<<<<<< dtext.tcl" > > > > Your sources have conflicts from a cvs update (the update failed and the > > "<<<<<<<" are the lines where they were conflicts during cvs update). > > > > You need to correct these (and the method depends on whether you have > > local changes or not). > > Hmm, I didn't get any cvs errors during update. Conflicts are only reported once; if you miss them the first time, you won't get any warning on subsequent updates. Tip: update with: cvs update 2>&1 | fgrep -v 'cvs server: Updating ' This makes it much easier to spot "useful" messages. > Should I blow away my cvs directory and do a fresh checkout instead? Although it's now moot, just deleting the file in question and updating that file (or directory) will suffice. -- Glynn Clements From tlaronde at polynum.com Fri Dec 1 00:43:01 2006 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Fri Dec 1 00:40:07 2006 Subject: [GRASS-dev] 6.x Vector's wording commented Message-ID: <20061130234301.GA3308@polynum.com> Hello, In the following, I have tried to comment the _wording_ (the glossary) of GRASS GPL documentation of the new vector engine. I would highly appreciate that someday someone could comment KerGIS documentation too, since both projects are based on CERL GRASS and are providing something that is particular: topological GIS. Some may be wishing that the open source/free software provides for "free" the equivalent of the commercial products. But I, personnally, do not have chosen open source software for free like "talking about freedom after the twelfth gratis beer". I don't want, neither, to make clones of commercial standard gis software and I'm not that impressed about the bulk of them, having tried to make something hard with them and never managed to (with a reasonable investment in time and money) while it has been achieved with GRASS GPL 5.0 at its time and in time. Topology is CERL GRASS based GIS singularity. And it's a good one. Libre software has been blamed from neither improving things, nor introducing outstanding new schemes, but simply mimicking, or even "faking". This is not true if one considers GRASS CERL for example, the CSRG BSD improvements and so on. It is more true with the bulk of the late production of the so-called free software, poorly innovative altogether. But with GRASS GPL and KerGIS this can/could change precisely because we are on our own track and if we keep improving on our own scheme. Even if I have suffered from some french GRASS users' spite (and never from developers... perhaps because people _working_ may disagree, but respect other people _working_...), I wish wholeheartly the best to GRASS GPL, not because I'm a nice guy, but because this is my interest: GRASS GPL loosing users will not increase KerGIS base; and GRASS GPL providing great things will give me, and others, incentive to improve KerGIS too. And if I make momentary mistakes, there will be a sibling project to rely upon. I think the reciprocal holds too. Not competition: emulation; another point of view to react with or against. In what follows, I comment about the wording of the documentation, _not_ about the engineering decisions or the implementation of your new vector engine, since this is none of my business to do so. My comments are based on my knowledge of the legacy GRASS and I hope that people will find some explanations "obvious". It will mean that the explanation is the simplest one, that is the shortest path to the truth of its object (this definition is not mine; it was given by Charles de Gaulle). I don't think that what is below is perfect, since I have limited time, and since it is in an approximate english. A french version would, obviously, match better what I have in mind. If things may seem obvious when now explained, they were not, at least in my mind, some years ago. I explicitely state things that were implicit or embedded in the code, or I introduce supplementary notions that, IMO, give sense to the whole thing. ---quote Background Generally, the vector data model is used to describe geographic phenomena which may be represented by geometric entities (primitives) like points, lines, and areas. The GRASS vector data model includes the description of topology, where besides the coordinates describing the location of the points, lines, boundaries and centroids, their spatial relations are also stored. In general, topological GIS require a data structure where the common boundary between two adjacent areas is stored as a single line, simplifying the map maintenance. ---endquote Assigning the vector description of the geometrical data its place in the GIS whole could be made like this: GRASS/KerGIS is a _system_ that is a coherent set of programs meant to work together in the same environment, used to add value to geometrical descriptions, whether by deducing from the geometrical descriptions topological or logical properties, or by adding non geometrical attributes to geometrical data. The system accepts and treats geometrical data in 3 main flavors: 1) By erudition: no rules are known but only a succession of ponctual facts. This is the raster description. Since, mathematically, there may be an infinite amount of points lying in a two dimensions region, the single values are not points, but represent a definite rectangular area with a fixed width (x) and height (y) named a CELL. The main utilities of the GIS will take these raw facts and deduce logical relationship, for example deducing watershed etc. 2) By describing exhaustively the organization of the space in the region of interest by giving rules to group points in one dimension geometrical elements. The element of the vector is an arc, that is an oriented set of vertices. The vector is an exhaustive description of a finite number of arcs with almost infinite precision. 3) By describing a set of singularities (SITES) that may be, whether singular sites of interest, or an approximation of some aspect of a whole region by the gift of a finite number of weighted singularities. SITES are used as themselves, or as a transformation description. The IMAGERY is _not_ a fundamental geometrical description. It is a set of utilities to put an incorrect raster description in a canonical state, that is, mainly, to insure that the CELL are homogeneous, having a fixed width, height and comparison plane. Note about your description: the first line says that: points, lines, and areas are the primitives. This is true but, since you have introduced 3D you should add: volumes. But after that, you name _centroids_: centroids are _not_ geometrical elements; they are not primitives. This is inconsistent. The distinction shall be introduced afterward. The next section is the more problematic one, since distinct notions are merged and blured, and since some definitions are circular. Some choice of the words are problematic too when one comes to the "category". ---quote Introduction [skipping what is the description of the features and that are engineering decisions] The following vector objects are available: * point: a point * line: a sequence of vertices connected by line(s) with two endpoints called nodes * boundary: the border line of an area * centroid: the label point of an area * area: the topological composition of centroid and boundary * face: a 3D area * kernel: a 3D centroid in a volume (not yet implemented) * volume: a 3D corpus (not yet implemented) ---endquote Some features in GRASS 6.x vector engine will be hard to describe, because (I think this is due to the support of external formats) you are melting things that are in a different league. Taking a mathematical standpoint for such a package is always a good start. The aim is to gain an orthogonal base, that is a set of independent primitive elements. Is a centroid independent from the area? no. Is the boundary independent from an area? no. So area, centroid, boundary do not make an orthogonal base. Furthermore, it will be clearer to describe first, and separately, the _geometrical_ elements, and to introduce after attributes, that is assignation of non geometrical properties. I will reset my initial description: 1) the vector element is an ARC, that is an oriented vector of vertices. 2) the vertices can be seen as control points. The nature of the one dimension element drawned according to these control points can be called the functional type (in KerGIS V_FTYPE_*). There was (is) only one functional type supported: V_FTYPE_LINE (polylines, or segments). 3) the topological type of the ARC tells what _geometrical_ element to deduce from the ARCS. Topological types are : V_TTYPE_DOT, V_TTYPE_PATH, V_TTYPE_EDGE (were respectively DOT, LINE and AREA in legacy code). 4) the geometrical figures are deduced from the previous informations. The geometrical figures are V_GTYPE_POINT, V_GTYPE_LINE, G_GTYPE_AREA. 5) the legacy categories are associated with _geometrical figures_ by a _topological_ mean: a point "on" an element (nearest to this element than to another one) [category are now in KerGIS group numbers, and label group names ? la DNS]. COMMENT: so a "line" is not a "sequence of vertices connected by lines" since this definition is circular. The ARC is the way the information is stored and the topology deduced. The geometrical elements are [I use KerGIS macro definitions, you should adapt with your terminology]: 1) a point: made by an ARC of type V_TTYPE_DOT; 2) a path: made by an ARC of type V_TTYPE_PATH. The only functionnal type supported at the moment is the straight line between two vertices, hence a path appears as a polyline (note: a curve, or B?zier curve is given between two points with the adjunction of two control points; so the definition will hold in this case two, but the implementation of the ARC structures will not suffice; the simplest definition I have ever found is in the MetafontBook by Donald E. Knuth). There could be more one day. 3) an area: made by a closed set of connected ARCs of type V_TTYPE_EDGE, with no connected ARC not belonging to the set lying inside the hull described by the set [this is true for legacy GRASS and KerGIS; is it still true for GRASS GPL or do you allow non topologically clean data?]. There is here a subtlety: an area is an element topologically deduced from one dimension elements (ARCs). In the definition given above, the vector description is exhaustive. But it is exhaustive about the elements that are the ARCs. Each ARC belonging to the vector is either taken into account or not, depending on if it is DEAD or ALIVE. A dead arc---in the legacy CERL GRASS and in KerGIS, I don't know for GRASS GPL---is not taken into account when building the support or plus file. But with the geometrical elements deduced from these ARCs that are the description, some elements may _not_ belong to the vector set, the elements of dimension 2 (areas) or 3 (volumes). Actually, if one takes a vector with some isle, there are two legitimate areas: the inner isle, or the complement (the "infinite" space minus the isle, that is the "outside" area). Hence a mean shall be given to describe what belongs to the set, and, by deduction, what does _not_ belong to the set. This is why there is the need to give a supplementary information (see theorem 9 of David hilbert's Grundlagen der Geometrie) to tell what areas are alive: a point "inside". This point is not uniq, and is not a geometrical primitive: it is a geometrical attribute. CONSEQUENCE: there is an apparent lack of symetry between dimension 0 and 1, and dimension 2 and 3, since a group [KerGIS terminology, legacy cat] of 0 is valid for a point or a path, but not for an area or a volume. The "centroid" or the "boundary" are not primitive elements, they are geometrical properties of the area primitive. NOTE: from the discussion about the v.category, it was clear that there was perhaps some need, sometimes, to obtain the contour of an area. But the fact that the boundary is _not_ a primitive element, and that it has nothing to do here even if sometimes there is need to retrieve the info (that is what the v.out.* utilities mainly do) is made even clearer by the fact that this definition does not scale. Indeed, what is an area contour? The outer boundary, ok. But this is simply the particular case of the outer boundary of a _group_ of elementary areas, where the group is reduced to a sole element. Once you have introduced and explain how everything is constructed from (level 1) ARCs, to (level 2) geometrical elements, you can explain how to link non geometrical attributes to groups of geometrical elements. That's why KerGIS has replaced "category" by "group" since it is the fundamental idea that was underneath, and since grouping is not only useful with external attributes: it is also useful for grouping geometries. ---quote For historical reasons, there are two internal libraries for vector: * diglib, dig_*(), DIGLIB, libdig.a, digit library, grass3.x, 4.x and * Vlib, Vect_*(), VECTLIB_REAL, libvect.a, vector library, grass4.x The Vlib Vector library was introduced in grass4.0 to hide internal vector files' formats and structures. In GRASS 6 everything is accessed via Vect_*() functions, for example: Old 4.x code: xx = Map.Att[Map.Area[area_num].att].x; New 6.x functions: Vect_get_area_centroid() Vect_get_centroid_coor() ---endquote Actually, they are 3 levels in the vector module: 1) V0: the handling of arrays of points, used for purely geometrical manipulation and, for example, used when importing from other formats; 2) V1: related to the way the geometrical information are described, that is the handling of the ARCS; 3) V2: used when building or accessing information deduced from the ARCs. The Vect_* functions, in the legacy code and in KerGIS, are related to the higher level gis database handling of a vectorial element (that is composed, indeed, of several distinct files spread in dedicated places in the gis database). The Vect_* functions are related to the vector map as a whole (an atom), opening and initializing. In an approximate view, these functions do not handle the inner organization of the files but built the higher level abstraction, gathering the information spread in the database. The V1, V2 and Vect_ were introduced by Dave Gerdes for 4.0. For completness, I have added V0. Rule of thumb: Dave Gerdes was the main father of the vectorial engine. If he has decided to introduce these distinctions, it is probably good to consider them. They are sound. May I suggest that, in the future (with no obligation to change the implementation), GRASS GPL team reintroduces this naming scheme? Historical note: the dig_* function were mainly associated with V0 and V1 levels. ---quote Vector library categories and layers Note: "layer" was called "field" in earlier version. In GRASS a "category" is a feature ID used to link geometry with attributes stored in one or many (external) database table(s). Each vector feature inside a vector map has zero, one or more tuple(s). A user can (but not must) create attribute tables which are referenced by the layer, and rows which are essentially referenced by the pair. ---endquote Traditionnally (in CAD), a layer is a set of elements grouped by logical functionnality. A french translation are sometimes "calque" (translucent paper, tracing paper) because, before computers, the tracings of elements were made on translucent papers and when one wanted to see how the distinct levels fit together they stacked the translucent papers one on another to see the combination (this matches the meaning in layer when displaying). IMHO, since you introduce "layer" about non geometrical attributes with a rdbm style management, why don't you simply say: table instead of layer or field, and column_value instead of "category"? I may be wrong about my interpretation but I must say that from your description I understand absolutely nothing about the way attributes are handled :) And the wording does not help. ---quote Vector library and Attributes Note: "layer" was called "field" in earlier version. The old GRASS 4.x 'dig_cats' files are not used any more and vectors' attributes are stored in external database. Connection with the database is done through drivers based on DBMI library (odbc, dbf, PostgreSQL and MySQL drivers are available at this time). Records in a table are linked to vector entities by field and category number. The field identifies table and the category identifies record. I.e., for any unique combination map+mapset+field+category, there exists one unique combination driver+database+table+row. ---endquote I do not understand: do you link by rows? That is, if I have, say an area with category number 123, that has an equivalent text (for KerGIS this is group and group name) "74001A2574" ("74001" the insee code of a french town in departement 74, the section "A", and the number of the parcel in this section) and I have several records (rows) to link to the area, I need to duplicate the "categories"? Here "field" is still here instead of "layer". But is the "category" a number, a text, the value of a column or what? ---quote map[@mapset] field table [key [database [driver]]] If key, database or driver are omitted (on second and higher row only) the last definition is used. Definitions from DB file in other mapsets may be overwritten by a definition in the current mapset if mapset is specified with map name. Wild cards * and ? may be used in map and mapset names. Variables $GISDBASE, $LOCATION, $MAPSET, $MAP, $FIELD may be used in table, key, database and driver names. Note that $MAPSET is not the current mapset but mapset of the map the rule is defined for. Note that features in GRASS vectors may have attributes in different tables or may be without attributes. Boundaries form areas but it may happen that some boundaries are not closed (such boundaries would not appear in polygon layer). Boundaries may have attributes. All types may be mixed in one vector. The link to the table is permanent and it is stored in 'dbln' file in vector directory. Tables are considered to be a part of the vector and g.remove, for example, deletes linked tables of the vector. Attributes must be joined with geometry. Examples: Examples are written mostly for the dbf driver, where database is full path to the directory with dbf files and table name is the name of dbf file without .dbf extension. * 1 tbl id $GISDBASE/$LOCATION/$MAPSET/vector/$MAP dbf This definition says that entities with category of field 1 are linked to dbf tables with names tbl.dbf saved in vector directories of each map. ---endquote Here field is still here in place of layer. Why don't you use a BNF description, making the distinction between productions and terminals? Why don't you use meaningful examples? Is "tbl" a reserved word? A production? A value? If it is the name of a table why don't you use "name_of_my_table" for example? Is "id" a reserved word, a production ? Why use such a generic term and not, if it is a column name "column_name" for example? I may not be a genius, but I think I am not below the average. And "parsing" your description with my C mind, it coredumps! And I will not give you the result since it has private informations ;) Hope this help, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From hamish_nospam at yahoo.com Fri Dec 1 03:23:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 1 03:23:59 2006 Subject: [GRASS-dev] Re: [bug #5341] Data corruption problem with v.db.select In-Reply-To: <20061130092443.447421006AB@lists.intevation.de> References: <20061130092443.447421006AB@lists.intevation.de> Message-ID: <20061201152354.230909a2.hamish_nospam@yahoo.com> > http://intevation.de/rt/webrt?serial_num=5341 Well, that didn't take long. We now have a nasty 6.2.1 blocker bug. See the spearfish example below. HB: > > v.db.select segfaults if SQL query is malformed: > > > > G63> v.db.select -c fish_sites col=site_id where="CAT = 1" > > Ai1 > > > > G63> v.db.select -c fish_sites col=site_id where="CAT=1" > > Segmentation fault MS: > Why do you think "CAT=1" is malformed and "CAT = 1" is not? > See eg. http://www.w3schools.com/sql/sql_where.asp. Both notations are > allowed. > > Also GRASS manual mentions both, eg. > http://grass.itc.it/grass63/manuals/html63_user/sql.html: > > d.vect map where="individual='juvenile' yes you are correct. (fyi, I put that example in, we were tracking the movements of sea lion pups) re-testing for that sea lion map, it is only v.db.select that is broken. d.vect, v.extract work without the extra whitespace. the column= where= options are newer than 6.0.2, so can't test that, but they do break in 6.1.0. > This bug is similar to my recent > http://intevation.de/rt/webrt?serial_num=5341, It is the same bug. Merged. #spearfish #includes Brad's updates from 2 days ago G63> v.db.select -c archsites where="CAT = 1" 1|Signature Rock G63> v.db.select -c archsites where="CAT=1" DBMI-DBF driver error: SQL parser error in statement: SELECT * FROM archsites WHERE CAT=1) Error in db_open_select_cursor() ERROR: Cannot open select cursor G63> v.db.select -c archsites column=str1 where="CAT = 1" Signature Rock G63> v.db.select -c archsites column=str1 where="CAT=1" No Name G63> v.db.select archsites where="CAT = 1" col=cat cat 1 G63> v.db.select archsites where="CAT=1" col=cat cat 11 ==> that is very bad, it reports the attribute of the wrong cat ! Hamish From hamish_nospam at yahoo.com Fri Dec 1 03:39:35 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 1 03:39:40 2006 Subject: [GRASS-dev] Re: [bug #5341] (grass) v.db.select: segfault In-Reply-To: <20061130092432.6D8821006A8@lists.intevation.de> References: <20061130092432.6D8821006A8@lists.intevation.de> Message-ID: <20061201153935.2a82bf2d.hamish_nospam@yahoo.com> > G63> v.db.select archsites where="CAT = 1" col=cat > cat > 1 > > G63> v.db.select archsites where="CAT=1" col=cat > cat > 11 > > ==> that is very bad, it reports the attribute of the wrong cat ! found it. v.db.select/main.c: if (where_opt->answer) { char *buf = NULL; - buf = G_malloc ((strlen(where_opt->answer) + 7)); + buf = G_malloc ((strlen(where_opt->answer) + 8)); sprintf (buf, " WHERE %s", where_opt->answer); db_append_string ( &sql, buf ); G_free (buf); } strlen() returns the length of the string without the null terminator. So the *buf string was allocated one smaller than it needed to be. fixed in CVS & 6.2 branch. Hamish From dylan.beaudette at gmail.com Fri Dec 1 06:10:02 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Dec 1 06:10:05 2006 Subject: [GRASS-dev] Changes to r.sun made Feb 2006 [resolved] Message-ID: <3c5546140611302110v189a47b5sda2003e31bff394e@mail.gmail.com> Sorry for the noise, it looks like this was an operator error on my part. Cheers, Dylan PS: with even better results from r.sun: http://169.237.35.250/~dylan/temp/11-yr_variation_vs_modeled.png when using longer term averages, the R^2 goes to 0.95 ! (right hand sub-figure), but still working on optimal Linke turbidity values. On 11/28/06, Dylan Beaudette wrote: > Hi everyone, > > I am repeating an experiment, originally conducted Feb 7th 2006, comparing the > output from r.sun with real data from a weather station. > > On Feb 7th, 2006 the output from r.sun (computed with customized linke > turbidity values) very closely matched the weather station data. > > As of today the exact same experiment gives slightly different results: > 1. the correlation between r.sun and the weather station is nearly identical > 2. the output from r.sun (specifically the beam component) is about 1500 > Wh/sq. meter/day higher than it should be. > > The only thing that has changed since I last conducted this experiment was > r.sun. From the CVS server it looks like r.sun/main.c was altered shortly > after I did my original experiment: > > ----------------------------------------------------------------------------------------------- > Revision 2.14 / (as text) / (view) - annotate - [select for diffs] , Tue Feb > 21 10:00:52 2006 UTC (9 months ago) by markus > Branch: MAIN > Changes since 2.13: +28 -174 lines > Diff to previous 2.13 > > Jaro Hofierka: new shadow algorithm; dist param changed to fixed value; > correction factor for shadowing to account for the earth curvature > ----------------------------------------------------------------------------------------------- > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/raster/r.sun/main.c > > > In summary, the diffuse component of the modeled solar radiation is nearly the > same as it was when computed by r.sun Feb 7 2006. The beam component is now > about 1500 Wh/sq m / day higher than it was as on Feb 7 2006. > > This brings up an interesting question: which results from r.sun where the > most representative of reality ? I noticed that the changes made to r.sun > involved a shadow algorithm- yet my weather station (and modeled area) are > not greatly affected by the shadowing of adjacent terrain. > > Any thoughts on how to best proceed would be greatly appreciated. > > PS: > the original results were mentioned in a previous message to the GRASS list > on Feb 8 2006. > http://www.nabble.com/-GRASSLIST%3A10214--some-nice-results-from-r.sun-t1087635.html > > -- > Dylan Beaudette > Soils and Biogeochemistry Graduate Group > University of California at Davis > 530.754.7341 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From grass-bugs at intevation.de Fri Dec 1 07:36:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Dec 1 07:36:30 2006 Subject: [GRASS-dev] [bug #5361] (grass) build system: "etc" PGMs should skip HTML page gen Message-ID: <20061201063628.D3AAF1006A6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5361 ------------------------------------------------------------------------- Subject: build system: "etc" PGMs should skip HTML page gen the Makefile "htmletc" target should skip htmlgen steps for most (all?) cases. include/Make/Html.make: # html rules for ETC commands htmletc: htmletc1 htmlgen htmletc1: $(call htmldesc,$(ETC)/$(PGM)) currently some are skipped in the build master help index: tools/build_html_index.sh EXCLUDEHTML="" but they shouldn't be generated in the first place. r.watershed.ram and r.watershed.seg currently stick out. cd grass63/include/Make/ for FILE in `locate 'grass63/' | grep Makefile` ; do grep -H -A1 "htmletc" $FILE | cut -f7- -d/ done imagery/i.ask/Makefile:htmletc1: imagery/i.ask/Makefile- @echo no docs needed for $(PGM) imagery/i.find/Makefile:htmletc: imagery/i.find/Makefile- @echo no docs needed for $(PGM) imagery/i.ortho.photo/photo.camera/Makefile:htmletc1: imagery/i.ortho.photo/photo.camera/Makefile- $(MKDIR) $(GISBASE)/docs/html imagery/i.ortho.photo/photo.elev/Makefile:htmletc: imagery/i.ortho.photo/photo.elev/Makefile- @echo no docs needed for $(PGM) imagery/i.ortho.photo/photo.target/Makefile:htmletc1: imagery/i.ortho.photo/photo.target/Makefile- @echo No docs needed for $(PGM) raster/r.support/modcats/Makefile:htmletc1: raster/r.support/modcats/Makefile- @echo "No docs to generate." raster/r.support/modcolr/Makefile:htmletc1: raster/r.support/modcolr/Makefile- @echo "No docs to generate." raster/r.support/modhead/Makefile:htmletc1: raster/r.support/modhead/Makefile- @echo "No docs to generate." raster/r.support/modhist/Makefile:htmletc1: raster/r.support/modhist/Makefile- @echo "No docs to generate." raster/r.watershed/ram/Makefile:htmletc1: raster/r.watershed/ram/Makefile- @echo "No docs to generate." raster/r.watershed/seg/Makefile:htmletc1: raster/r.watershed/seg/Makefile- @echo "No docs to generate." for FILE in `locate 'grass63/' | grep Makefile` ; do grep -H "default: etc" $FILE | cut -f7- -d/ done imagery/i.ask/Makefile:default: etc imagery/i.find/Makefile:default: etc imagery/i.ortho.photo/photo.2image/Makefile:default: etc imagery/i.ortho.photo/photo.2target/Makefile:default: etc imagery/i.ortho.photo/photo.camera/Makefile:default: etc imagery/i.ortho.photo/photo.elev/Makefile:default: etc imagery/i.ortho.photo/photo.init/Makefile:default: etc imagery/i.ortho.photo/photo.rectify/Makefile:default: etc imagery/i.ortho.photo/photo.target/Makefile:default: etc raster/r.support/modcats/Makefile:default: etc raster/r.support/modcolr/Makefile:default: etc raster/r.support/modhead/Makefile:default: etc raster/r.support/modhist/Makefile:default: etc raster/r.watershed/ram/Makefile:default: etc raster/r.watershed/seg/Makefile:default: etc ? Hamish -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Fri Dec 1 09:09:53 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 1 09:10:03 2006 Subject: [GRASS-dev] Re: r.to.rast3elev In-Reply-To: <456FD7DE.3090109@gmx.de> References: <20061201164142.1d713734.hamish_nospam@yahoo.com> <456FD7DE.3090109@gmx.de> Message-ID: <20061201210953.0f7a161a.hamish_nospam@yahoo.com> Anybody object to activating this module in the GRASS 6.2 release branch? Hamish S?ren wrote: > not critical, but i think r.to.rast3elev is stable enough and offers a > lot of nice features. Some users also requested this module in grass > 6.2, but i missed the release termin. > > So it would be nice to have r.to.rast3elev in grass 6.2.1. From neteler at itc.it Fri Dec 1 09:24:28 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Dec 1 09:24:30 2006 Subject: [GRASS-dev] Re: r.to.rast3elev In-Reply-To: <20061201210953.0f7a161a.hamish_nospam@yahoo.com> References: <20061201164142.1d713734.hamish_nospam@yahoo.com> <456FD7DE.3090109@gmx.de> <20061201210953.0f7a161a.hamish_nospam@yahoo.com> Message-ID: <456FE6BC.7070708@itc.it> No objections from here, I was thinking the same. Markus Hamish wrote on 12/01/2006 09:09 AM: > Anybody object to activating this module in the GRASS 6.2 release branch? > > > Hamish > > > S?ren wrote: > >> not critical, but i think r.to.rast3elev is stable enough and offers a >> lot of nice features. Some users also requested this module in grass >> 6.2, but i missed the release termin. >> >> So it would be nice to have r.to.rast3elev in grass 6.2.1. >> From jachym.cepicky at centrum.cz Fri Dec 1 10:05:45 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Dec 1 10:05:50 2006 Subject: [GRASS-dev] creating new location in krovak projection In-Reply-To: <20061128195227.GA10864@bartok.itc.it> References: <20061128194254.GA9662@localdomain> <20061128195227.GA10864@bartok.itc.it> Message-ID: <20061201090545.GC7696@localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061201/c07ce894/attachment.bin From hamish_nospam at yahoo.com Fri Dec 1 10:16:54 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 1 10:17:00 2006 Subject: [GRASS-dev] Re: [GRASS-user] updating kriging modules for grass 62 In-Reply-To: <456E951E.6030402@ufg.uni-kiel.de> References: <456E951E.6030402@ufg.uni-kiel.de> Message-ID: <20061201221654.1ae6d3fc.hamish_nospam@yahoo.com> As a start I would really really like to include "Launch QGIS" and "Launch R" menus items in the GUI's "Xtns" menu* automatically. That would encourage folks to explore. Some sort of GMT intergration would be nice too. [*] If the program wasn't found it should grey out the menu item (test at gis startup to set a HAVE_QGIS variable: if [ -x `which qgis` ] (whatever the tcl equivalent of that is) On one hand I'd prefer binary packagers to use GEM to do this, on the other hand this is a general need, needless duplication of effort, extra work for the packagers... A GEM package to enable this would be a cool first start. Hamish ps - I would suggest renaming the Xtns menu to "Extensions". It's easier to understand, especially by non-english speakers who already have enough work trying to decode the language anyway and IMO looks more professional. From neteler at itc.it Fri Dec 1 10:26:13 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Dec 1 10:26:15 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> Message-ID: <20061201092613.GD32250@bartok.itc.it> Hi developers, I have seen this message in the GDAL list: On Tue, Nov 28, 2006 at 11:03:00AM +1100, Craig Feuerherdt wrote: ... > I am using Gentoo Linux. .. > When I attempt to use ogrinfo I get the following errors: > > ogrinfo PGeo:b_pgeo > ERROR 1: /usr/grass-6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > ERROR 1: /usr/grass- 6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > Segmentation fault > > I can not work out why the error involves GRASS? cd lib/vask/ grep stdscr * V_call.c: getyx (stdscr, y, x); V_exit.c: keypad(stdscr, 0); V_init.c: keypad(stdscr, 1); V_support.c: getyx(stdscr, cury, curx) ; But: find . -name "*.c" |xargs fgrep --files-with-match stdscr |\ xargs fgrep --files-without-match curses.h ./V_exit.c ./V_call.c ./V_init.c Can this be the problem? However, in vask.h it is included. Means, that it is included twice in V_support.c, a problem? Markus From grass-bugs at intevation.de Fri Dec 1 10:35:11 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Dec 1 10:35:13 2006 Subject: [GRASS-dev] [bug #5341] (grass) v.db.select: segfault Message-ID: <20061201093511.AB9261006A6@lists.intevation.de> hamish_nospam@yahoo.com wrote (Fri, Dec 1 2006 03:39:42): > fixed in CVS & 6.2 branch. Allright! One can always count on you. Works OK now, no matter how many spaces between the operator and the arguments. Many thanks. Closing it. Maciek -------------------------------------------- Managed by Request Tracker From hofierka at geomodel.sk Fri Dec 1 11:50:08 2006 From: hofierka at geomodel.sk (Jaro Hofierka) Date: Fri Dec 1 11:50:04 2006 Subject: [GRASS-dev] Re: r.sun units In-Reply-To: <20061201132700.749a08c0.hamish_nospam@yahoo.com> References: <20061201132700.749a08c0.hamish_nospam@yahoo.com> Message-ID: <457008E0.7000606@geomodel.sk> Hamish wrote: > Hi Jaro, Marcel, Tomas, > > I was wondering if you could contribute some insight WRT this thread on > the GRASS users' list: > > http://thread.gmane.org/gmane.comp.gis.grass.devel/17118 > > > I fear my advice so far is rather bad. > > thanks, > Hamish > Hamish, Your advices were right. I am not sure if anything is still unclear, but I would add some minor clarifications: >> Is this essentially this same thing, as it is "integrated" over an >> hour when summed for the entire day? > > I would guess sum midnight to midnight hourly averages of W/m2 = mode2 ? Effectively, "per day" means from sunrise to sunset time (these are calculated internally), during night there is no solar radiation. Small amount of available diffuse radiation shortly before the sunrise and after the sunset are neglected. We use "per day" unit for situations where we need to calculate amount of available energy for a certain period of year (e.g. months). If you need radiation within one day you can use mode 1 - irradiance values [W/m^2] to calculate irradiance for a specific time and then multiply with your time interval. Some differences comparing with measurements may arrise from different time systems. r.sun uses local solar time, while practicaly we use "civic" times with time zones (and also modified with "summer/daylight saving time"). Marcel can send you more information about this. I believe the JRC team has some modification of r.sun that uses civic time. > I was aware of the Joule - Watt relationship, but was not quite sure why r.sun > was using W*h instead of Joules. Since a Mega-Joule is a much more readily > used unit of enery, I think that I will do the conversion from now on. This is solely for practical reasons. All calculations are done using watts (e.g. solar constant, irradiance), so expressing radiation in Wh is straightforward and gives a better idea how much energy is available, for example, for solar energy applications (photovoltaics, thermal systems). You can still make a simple conversion if you need joules. Jaro From benjamin.ducke at ufg.uni-kiel.de Fri Dec 1 14:21:43 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Dec 1 14:08:53 2006 Subject: [GRASS-dev] configuring grass 6.3 for cross compilation Message-ID: <45702C67.80307@ufg.uni-kiel.de> dear GRASS developers, I am trying to cross-compile GRASS 6.3.cvs using Radim's instructions on this page: http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux However, configure aborts with: ... checking for proj_api.h... yes configure: warning: *** Cannot check PROJ.4 version (cross-compiling). checking for location of External PROJ.4 library... checking for pj_get_def in -lproj... yes checking for location of External PROJ.4 data files... configure: warning: *** External PROJ.4 directory not specified checking for /epsg... configure: error: Cannot check for file existence when cross compiling This did not happen with a 6.1 cvs version. Are there any updates on how to configure 6.3 for cross compilation? Any help will be greatly appreciated! Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From marcel.suri at jrc.it Fri Dec 1 15:37:52 2006 From: marcel.suri at jrc.it (Marcel Suri) Date: Fri Dec 1 15:51:21 2006 Subject: [GRASS-dev] Re: r.sun units In-Reply-To: <457008E0.7000606@geomodel.sk> References: <20061201132700.749a08c0.hamish_nospam@yahoo.com> <457008E0.7000606@geomodel.sk> Message-ID: <45703E40.6010108@jrc.it> Hello, I looked at the discussion related to the units used in r.sun and can just summarize what were other have already said: The mode 1 gives values of instantaneous solar power (irradiance) impinging on a surface in "Watts per square meter" (W/m2) or in other words in "joules per second per square meter" (J/m2/s) The mode 2 integrates solar energy (irradiation) according to user-defined steps that is received by square meter during the whole day (actually from sunrise to sunset). The result is given in Watt-hours per square meter (Wh/m2) -> if multiplied by 3600, the daily total energy received by the surface would be expressed in joules per square meter (J/m2). We are aware of using Watt-hours (as non-SI unit), but this is because we work in the field of photovoltaic applications (solar electricity), where this unit is still preferred. Best regards, Marcel -- Marcel Suri European Commission - DG Joint Research Centre Institute for Environment and Sustainability Renewable Energies Unit via E. Fermi 1, TP 450 I-21020 Ispra (VA), Italy phone: +39 0332 786661, fax: +39 0332 789992 http://re.jrc.ec.europa.eu/pvgis/pv/ ****** Interested in solar radiation data? Please help us to understand better your needs, and fill in a questionnaire at: http://re.jrc.ec.europa.eu/iea-shc-task36/quest1_en.htm Jaro Hofierka wrote: > Hamish wrote: > >> Hi Jaro, Marcel, Tomas, >> >> I was wondering if you could contribute some insight WRT this thread on >> the GRASS users' list: >> >> http://thread.gmane.org/gmane.comp.gis.grass.devel/17118 >> >> >> I fear my advice so far is rather bad. >> >> thanks, >> Hamish From neteler at itc.it Fri Dec 1 16:39:51 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Dec 1 16:39:54 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? Message-ID: <20061201153951.GF16862@bartok.itc.it> hi, are there objections to rename r.out.gdal2 to r.out.gdal and remove the now obsolete scripts/r.out.gdal/ ? I have used the C version quite a bit successfully. Markus From epatton at nrcan.gc.ca Fri Dec 1 16:46:21 2006 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Dec 1 16:46:25 2006 Subject: [GRASS-dev] RE: [GRASS-user] Clicking on a text layer in GIS manager gives tcl error In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55C6B@s5-dar-r1.nrn.nrcan.gc.ca> Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55C6D@s5-dar-r1.nrn.nrcan.gc.ca> Oh yes, those work great as well. The text, scale, and legend positioning tools is great for putting together diagrams, figures, etc. The more I can do in Grass, the less I have to rely on e.g. Inkscape to do the final text tweaking, which saves quite a bit of time. ~ Eric. -----Original Message----- From: Michael Barton To: Patton, Eric; grass-dev@grass.itc.it Cc: grassuser@grass.itc.it Sent: 11/30/2006 1:49 PM Subject: Re: [GRASS-user] Clicking on a text layer in GIS manager gives tcl error On 11/30/06 11:14 AM, "Patton, Eric" wrote: > Michael, > > As Thierry mentioned, deleting my grass6 directory and doing a fresh cvs > checkout solved the problem. > > BTW, text positioning works great! Thanks, Good. I'm happy that the text positioning works. I like it. Have you tried the legend and scalebar mouse positioning too? Do they work for you? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From wegmann at biozentrum.uni-wuerzburg.de Fri Dec 1 17:34:13 2006 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Fri Dec 1 17:35:33 2006 Subject: [GRASS-dev] r.resamp.stats error Message-ID: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> Hello, I found a weird behaviour in r.resamp.stats which causes a shift of the resulting image but only on a large scale (subcontinental scale, shift to south-west). I tried to reproduce it with the spearfish dataset but failed. Doing it on Africa srtm DEM (res based on gtopo30 DEM): g.region -g ... res=0.00083333 .. g.region res=0.0083333 r.resamp.stats input=dem output=dem_resampstats method=average produces this output of a small region with islands shown in the jpg (overlay with original raster) any idea how to fix this? regards, Martin BTW r.resamp.stats is fast - it takes less than 15min for this analysis. -------------- next part -------------- A non-text attachment was scrubbed... Name: resamp_stats_shift.jpg Type: image/jpeg Size: 11571 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061201/139aeacd/resamp_stats_shift-0001.jpg From landa.martin at gmail.com Fri Dec 1 18:30:30 2006 From: landa.martin at gmail.com (Martin Landa) Date: Fri Dec 1 18:30:33 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: <20061201153951.GF16862@bartok.itc.it> References: <20061201153951.GF16862@bartok.itc.it> Message-ID: Hi, +1 for r.out.gdal2 -> r.out.gdal(C) maybe it could be safer to rename the r.out.gdal(script) to r.out.gdal2 or r.out.gdal.sh and to add an appropriate warning, e.g. WARNING: This module is superseded and will be removed in future versions of GRASS. Use r.out.gdal instead. Martin 2006/12/1, Markus Neteler : > hi, > > are there objections to rename r.out.gdal2 to > r.out.gdal and remove the now obsolete > scripts/r.out.gdal/ > ? > > I have used the C version quite a bit successfully. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From dylan.beaudette at gmail.com Fri Dec 1 19:39:39 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Dec 1 19:08:56 2006 Subject: [GRASS-dev] Changes to r.sun made Feb 2006 [resolved] In-Reply-To: <456FE737.5070402@itc.it> References: <3c5546140611302110v189a47b5sda2003e31bff394e@mail.gmail.com> <456FE737.5070402@itc.it> Message-ID: <200612011039.39500.dylan.beaudette@gmail.com> Hi Markus, I can think of a couple of things to be added to the manual page: much of which I would be happy to write. 1. clarification on units : i.e. in light of current discussion (no pun intended ! ) it would be good to give a brief overview of radiant energy: comparing what r.sun models to the output of a common sensor. 2. a quick example on using monthly , or as hamish suggested daily interpolated, linke turbidity values - i.e. bash style, or something like: # next revision: based on visual inspection linke_monthly[1]=5.9 linke_monthly[2]=5.8 linke_monthly[3]=5.6 linke_monthly[4]=5.6 linke_monthly[5]=5.3 linke_monthly[6]=5.0 linke_monthly[7]=4.8 linke_monthly[8]=5.0 linke_monthly[9]=5.0 linke_monthly[10]=5.2 linke_monthly[11]=5.4 linke_monthly[12]=5.6 -------- example script for modeling an entire year ----------------------- #load an array with monthly linke turbidity factors for a mountainous area: for i in `seq 1 31`; do linke[$i]=${linke_monthly[1]}; done for i in `seq 32 59`; do linke[$i]=${linke_monthly[2]}; done for i in `seq 60 90`; do linke[$i]=${linke_monthly[3]}; done for i in `seq 91 120`; do linke[$i]=${linke_monthly[4]}; done for i in `seq 121 151`; do linke[$i]=${linke_monthly[5]}; done for i in `seq 152 181`; do linke[$i]=${linke_monthly[6]}; done for i in `seq 182 212`; do linke[$i]=${linke_monthly[7]}; done for i in `seq 213 243`; do linke[$i]=${linke_monthly[8]}; done for i in `seq 244 273`; do linke[$i]=${linke_monthly[9]}; done for i in `seq 274 304`; do linke[$i]=${linke_monthly[10]}; done for i in `seq 305 334`; do linke[$i]=${linke_monthly[11]}; done for i in `seq 335 365`; do linke[$i]=${linke_monthly[12]}; done export linke #loop through each day in the year time \ for x in `seq 1 365` do echo "Running r.sun for day $x: Linke turbidity factor= ${linke[$x]}" r.sun --o -s elevin=$elev aspin=$aspect slopein=$slope \ diff_rad=diffuse_0$x beam_rad=beam_0$x insol_time=time_0$x refl_rad=refl_0$x \ day=$x \ lin=${linke[$x]} done -------- example script for modeling an entire year ----------------------- 3. a bit of background / or ideas (i have the references handy) on calculating estimated linke turbidity values from local weather station data. I have yet to do this with my project, as i am having a tough time with the equations. should have this worked out soon. I need to write-up most of these things for my MS thesis anyways, so i would be happy to contribute to the manual. Obviously review by Jaro and the solar gang would be a good idea. Cheers, Dylan On Friday 01 December 2006 00:26, Markus Neteler wrote: > hi Dylan, > > since I soon have to work with r.sun, too, I would highly appreciate > if you could add your findings to the manual page. > You/others pointed out some things which should/could be clarified > there, please do so while memory is still fresh. > Probably also a small text chunk about the units doesn't harm. > > thanks in advance > Markus > > Dylan Beaudette wrote on 12/01/2006 06:10 AM: > > Sorry for the noise, it looks like this was an operator error on my part. > > > > Cheers, > > > > Dylan > > > > PS: with even better results from r.sun: > > > > http://169.237.35.250/~dylan/temp/11-yr_variation_vs_modeled.png > > > > when using longer term averages, the R^2 goes to 0.95 ! (right hand > > sub-figure), but still working on optimal Linke turbidity values. > > > > On 11/28/06, Dylan Beaudette wrote: > >> Hi everyone, > >> > >> I am repeating an experiment, originally conducted Feb 7th 2006, > >> comparing the > >> output from r.sun with real data from a weather station. > >> > >> On Feb 7th, 2006 the output from r.sun (computed with customized linke > >> turbidity values) very closely matched the weather station data. > >> > >> As of today the exact same experiment gives slightly different results: > >> 1. the correlation between r.sun and the weather station is nearly > >> identical > >> 2. the output from r.sun (specifically the beam component) is about 1500 > >> Wh/sq. meter/day higher than it should be. > >> > >> The only thing that has changed since I last conducted this > >> experiment was > >> r.sun. From the CVS server it looks like r.sun/main.c was altered > >> shortly > >> after I did my original experiment: > >> > >> ------------------------------------------------------------------------ > >>----------------------- > >> > >> Revision 2.14 / (as text) / (view) - annotate - [select for diffs] , > >> Tue Feb > >> 21 10:00:52 2006 UTC (9 months ago) by markus > >> Branch: MAIN > >> Changes since 2.13: +28 -174 lines > >> Diff to previous 2.13 > >> > >> Jaro Hofierka: new shadow algorithm; dist param changed to fixed value; > >> correction factor for shadowing to account for the earth curvature > >> ------------------------------------------------------------------------ > >>----------------------- > >> > >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/raster/r.sun/main.c > >> > >> > >> In summary, the diffuse component of the modeled solar radiation is > >> nearly the > >> same as it was when computed by r.sun Feb 7 2006. The beam component > >> is now > >> about 1500 Wh/sq m / day higher than it was as on Feb 7 2006. > >> > >> This brings up an interesting question: which results from r.sun > >> where the > >> most representative of reality ? I noticed that the changes made to > >> r.sun > >> involved a shadow algorithm- yet my weather station (and modeled > >> area) are > >> not greatly affected by the shadowing of adjacent terrain. > >> > >> Any thoughts on how to best proceed would be greatly appreciated. > >> > >> PS: > >> the original results were mentioned in a previous message to the > >> GRASS list > >> on Feb 8 2006. > >> http://www.nabble.com/-GRASSLIST%3A10214--some-nice-results-from-r.sun-t > >>1087635.html > >> > >> > >> -- > >> Dylan Beaudette > >> Soils and Biogeochemistry Graduate Group > >> University of California at Davis > >> 530.754.7341 > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From dylan.beaudette at gmail.com Fri Dec 1 21:06:17 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Dec 1 20:35:35 2006 Subject: [GRASS-dev] Re: r.sun units In-Reply-To: <457008E0.7000606@geomodel.sk> References: <20061201132700.749a08c0.hamish_nospam@yahoo.com> <457008E0.7000606@geomodel.sk> Message-ID: <200612011206.17726.dylan.beaudette@gmail.com> On Friday 01 December 2006 02:50, Jaro Hofierka wrote: > Hamish wrote: > > Hi Jaro, Marcel, Tomas, > > > > I was wondering if you could contribute some insight WRT this thread on > > the GRASS users' list: > > > > http://thread.gmane.org/gmane.comp.gis.grass.devel/17118 > > > > > > I fear my advice so far is rather bad. > > > > thanks, > > Hamish > > Hamish, > > Your advices were right. I am not sure if anything is still unclear, but > > I would add some minor clarifications: > >> Is this essentially this same thing, as it is "integrated" over an > >> hour when summed for the entire day? > > > > I would guess sum midnight to midnight hourly averages of W/m2 = mode2 ? > > Effectively, "per day" means from sunrise to sunset time (these are > calculated internally), during night there is no solar radiation. Small > amount of available diffuse radiation shortly before the sunrise and > after the sunset are neglected. We use "per day" unit for situations > where we need to calculate amount of available energy for a certain > period of year (e.g. months). If you need radiation within one day you > can use mode 1 - irradiance values [W/m^2] to calculate irradiance for a > specific time and then multiply with your time interval. > > Some differences comparing with measurements may arrise from different > time systems. r.sun uses local solar time, while practicaly we use > "civic" times with time zones (and also modified with "summer/daylight > saving time"). > > Marcel can send you more information about this. I believe the JRC team > has some modification of r.sun that uses civic time. > > > I was aware of the Joule - Watt relationship, but was not quite sure why > > r.sun was using W*h instead of Joules. Since a Mega-Joule is a much more > > readily used unit of enery, I think that I will do the conversion from > > now on. > > This is solely for practical reasons. All calculations are done using > watts (e.g. solar constant, irradiance), so expressing radiation in Wh > is straightforward and gives a better idea how much energy is available, > for example, for solar energy applications (photovoltaics, thermal > systems). You can still make a simple conversion if you need joules. > > Jaro > Jaro, others; Thank you for the quick clarifications. I would be happy to summarize this for the r.sun manual page- with your revision before posting. Cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From rez at touchofmadness.com Sat Dec 2 00:22:40 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Dec 2 00:22:49 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <20061201092613.GD32250@bartok.itc.it> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> <20061201092613.GD32250@bartok.itc.it> Message-ID: <1165015360.16142.58.camel@devel> On Fri, 2006-12-01 at 10:26 +0100, Markus Neteler wrote: > Hi developers, > > I have seen this message in the GDAL list: > > On Tue, Nov 28, 2006 at 11:03:00AM +1100, Craig Feuerherdt wrote: > ... > > I am using Gentoo Linux. > .. > > When I attempt to use ogrinfo I get the following errors: > > > > ogrinfo PGeo:b_pgeo > > ERROR 1: /usr/grass-6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > ERROR 1: /usr/grass- 6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > Segmentation fault > > > > I can not work out why the error involves GRASS? > > cd lib/vask/ > grep stdscr * > V_call.c: getyx (stdscr, y, x); > V_exit.c: keypad(stdscr, 0); > V_init.c: keypad(stdscr, 1); > V_support.c: getyx(stdscr, cury, curx) ; > > But: > find . -name "*.c" |xargs fgrep --files-with-match stdscr |\ > xargs fgrep --files-without-match curses.h > ./V_exit.c > ./V_call.c > ./V_init.c > > Can this be the problem? However, in vask.h it is included. > Means, that it is included twice in V_support.c, a problem? I move to the top of V_support.c and added it to another file that was missing it. I also added a macro around to prevent multiple inclusion. Updated documentation, also. The files could probably use some #ifdef HAVE_CURSES_H macros... Let me know if it's still broke and I'll add the above macro where needed. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Sat Dec 2 00:45:35 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 00:45:38 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <20061201092613.GD32250@bartok.itc.it> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> <20061201092613.GD32250@bartok.itc.it> Message-ID: <17776.48799.575408.324783@cerise.gclements.plus.com> Markus Neteler wrote: > I have seen this message in the GDAL list: > > On Tue, Nov 28, 2006 at 11:03:00AM +1100, Craig Feuerherdt wrote: > ... > > I am using Gentoo Linux. > .. > > When I attempt to use ogrinfo I get the following errors: > > > > ogrinfo PGeo:b_pgeo > > ERROR 1: /usr/grass-6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > ERROR 1: /usr/grass- 6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > Segmentation fault > > > > I can not work out why the error involves GRASS? > > cd lib/vask/ > grep stdscr * > V_call.c: getyx (stdscr, y, x); > V_exit.c: keypad(stdscr, 0); > V_init.c: keypad(stdscr, 1); > V_support.c: getyx(stdscr, cury, curx) ; Note that most of the curses "functions" which don't begin with "w" are actually macros which call the corresponding function with "stdscr" as the target window, e.g.: #define addch(ch) waddch(stdscr,ch) #define addchnstr(str,n) waddchnstr(stdscr,str,n) #define addchstr(str) waddchstr(stdscr,str) ... and so on. My guess is that, in some curses implementations, stdscr might be a macro. A normal GRASS binary distribution wouldn't be compatible with such an implementation; you would need to re-compile GRASS. -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 01:00:47 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 01:00:50 2006 Subject: [GRASS-dev] configuring grass 6.3 for cross compilation In-Reply-To: <45702C67.80307@ufg.uni-kiel.de> References: <45702C67.80307@ufg.uni-kiel.de> Message-ID: <17776.49711.359993.548386@cerise.gclements.plus.com> Benjamin Ducke wrote: > I am trying to cross-compile GRASS 6.3.cvs using Radim's instructions > on this page: http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux > > However, configure aborts with: > > ... > checking for proj_api.h... yes > configure: warning: *** Cannot check PROJ.4 version (cross-compiling). > checking for location of External PROJ.4 library... > checking for pj_get_def in -lproj... yes > checking for location of External PROJ.4 data files... > configure: warning: *** External PROJ.4 directory not specified > checking for /epsg... configure: error: Cannot check for file existence > when cross compiling > > > This did not happen with a 6.1 cvs version. > > Are there any updates on how to configure 6.3 for cross compilation? > Any help will be greatly appreciated! Right now, you can't. I'm looking into a fix, but until then you'll need to manually remove the check from the configure script. -- Glynn Clements From michael.barton at asu.edu Sat Dec 2 01:03:22 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Dec 2 01:03:28 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: <20061201153951.GF16862@bartok.itc.it> Message-ID: On 12/1/06 8:39 AM, "Markus Neteler" wrote: > hi, > > are there objections to rename r.out.gdal2 to > r.out.gdal and remove the now obsolete > scripts/r.out.gdal/ > ? > > I have used the C version quite a bit successfully. > > Markus > > PLEASE DO! Thanks so much Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sat Dec 2 01:04:41 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 01:04:46 2006 Subject: [GRASS-dev] r.resamp.stats error In-Reply-To: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> References: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <17776.49945.104564.229227@cerise.gclements.plus.com> Martin Wegmann wrote: > I found a weird behaviour in r.resamp.stats which causes a shift of the > resulting image but only on a large scale (subcontinental scale, shift to > south-west). > > I tried to reproduce it with the spearfish dataset but failed. > > Doing it on Africa srtm DEM (res based on gtopo30 DEM): > > g.region -g > ... > res=0.00083333 > .. > > g.region res=0.0083333 > r.resamp.stats input=dem output=dem_resampstats method=average > > produces this output of a small region with islands shown in the jpg (overlay > with original raster) > > any idea how to fix this? regards, Martin Odd. Can you provide the exact commands, including import and region-setting? (I have all of the gtopo30 files). -- Glynn Clements From grass-bugs at intevation.de Sat Dec 2 07:53:45 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Dec 2 07:53:47 2006 Subject: [GRASS-dev] [bug #5362] (grass) fg Message-ID: <20061202065345.3F1EE1005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5362 ------------------------------------------------------------------------- Subject: fg dfyhtfhg -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Sat Dec 2 07:58:05 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Dec 2 07:58:07 2006 Subject: [GRASS-dev] [bug #5363] (grass) RT integration with squirrelmail Message-ID: <20061202065805.EDD0A1005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5363 ------------------------------------------------------------------------- Subject: RT integration with squirrelmail How we can integrate RT with Squirrelmail.... -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Sat Dec 2 08:29:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Dec 2 08:29:18 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: Message-ID: On 12/1/06 10:30 AM, "Martin Landa" wrote: > +1 for r.out.gdal2 -> r.out.gdal(C) I have a question. Will GRASS still need a full install of GDAL for exporting via C-based r.out.gdal? Or can we drop this as a dependency? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From landa.martin at gmail.com Sat Dec 2 09:09:34 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sat Dec 2 09:09:42 2006 Subject: [GRASS-dev] v.in.db: even with "where=" option the entire table is copied In-Reply-To: <20061129165604.GP14587@bartok.itc.it> References: <20061129165604.GP14587@bartok.itc.it> Message-ID: Hi, 2006/11/29, Markus Neteler : > I have found a nice bug in v.in.db: > Even when I use a "where=" SQL statement to limit the > number of points fetched from the DB, the entire table > is copied. The module uses db_copy_table() which isn't > appropriate. > > v.extract builds a list of cats to copy, then uses > db_copy_table_by_ints(). So far I failed to transfer > this approach to v.in.db. fixed in CVS and backported to 6.2 Martin > Help appreciated... > thanks > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Sat Dec 2 10:41:00 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 10:41:05 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <1165015360.16142.58.camel@devel> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> <20061201092613.GD32250@bartok.itc.it> <1165015360.16142.58.camel@devel> Message-ID: <17777.18988.129952.530548@cerise.gclements.plus.com> Brad Douglas wrote: > The files could probably use some #ifdef HAVE_CURSES_H macros... In most cases, there isn't much point conditionalising inside source files. Most of the code which uses curses absolutely requires it, and can't do anything without it. If anything, vask, and everything which requires it, should be conditionalised in the Makefiles. If you don't have curses, vask doesn't get built, and modules which require it don't get built. The main complication is the imagery library. Parts of it require vask; they would need to be conditionalised individually rather than omitting the entire library if curses isn't available. That could by done either by listing the individual object files in lib/imagery/Makefile, with the vask-dependent ones conditionalised, or by bracketing the bodies of the source files with "#ifdef HAVE_CURSES_H". -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 11:54:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 11:54:08 2006 Subject: [GRASS-dev] configuring grass 6.3 for cross compilation In-Reply-To: <17776.49711.359993.548386@cerise.gclements.plus.com> References: <45702C67.80307@ufg.uni-kiel.de> <17776.49711.359993.548386@cerise.gclements.plus.com> Message-ID: <17777.23374.323542.605684@cerise.gclements.plus.com> Glynn Clements wrote: > > Are there any updates on how to configure 6.3 for cross compilation? > > Any help will be greatly appreciated! > > Right now, you can't. I'm looking into a fix, but until then you'll > need to manually remove the check from the configure script. I've committed a change to the configure script which should fix this, although I don't a cross-compilation environment to check it. -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 11:58:31 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 11:59:58 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: Message-ID: <17777.23639.817918.518816@cerise.gclements.plus.com> Michael Barton wrote: > > +1 for r.out.gdal2 -> r.out.gdal(C) > > I have a question. Will GRASS still need a full install of GDAL for > exporting via C-based r.out.gdal? Or can we drop this as a dependency? What do you mean by a "full" install? GRASS needs GDAL regardless of r.{in,out}.gdal. You will need GDAL headers and library to build r.out.gdal, and the library to run it. OTOH, GDAL won't need to be built with GRASS support, so you don't need to build GDAL without GRASS, build GDAL, then build it again with GRASS (unless you need GDAL to have GRASS support for some other reason). -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 12:01:29 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 12:01:34 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <17776.48799.575408.324783@cerise.gclements.plus.com> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> <20061201092613.GD32250@bartok.itc.it> <17776.48799.575408.324783@cerise.gclements.plus.com> Message-ID: <17777.23817.465851.809692@cerise.gclements.plus.com> Glynn Clements wrote: > > I have seen this message in the GDAL list: > > > > On Tue, Nov 28, 2006 at 11:03:00AM +1100, Craig Feuerherdt wrote: > > ... > > > I am using Gentoo Linux. > > .. > > > When I attempt to use ogrinfo I get the following errors: > > > > > > ogrinfo PGeo:b_pgeo > > > ERROR 1: /usr/grass-6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > > ERROR 1: /usr/grass- 6.1.0/lib/libgrass_vask.so: undefined symbol: stdscr > > > Segmentation fault > > > > > > I can not work out why the error involves GRASS? > > > > cd lib/vask/ > > grep stdscr * > > V_call.c: getyx (stdscr, y, x); > > V_exit.c: keypad(stdscr, 0); > > V_init.c: keypad(stdscr, 1); > > V_support.c: getyx(stdscr, cury, curx) ; > > Note that most of the curses "functions" which don't begin with "w" > are actually macros which call the corresponding function with > "stdscr" as the target window, e.g.: > > #define addch(ch) waddch(stdscr,ch) > #define addchnstr(str,n) waddchnstr(stdscr,str,n) > #define addchstr(str) waddchstr(stdscr,str) > > ... and so on. > > My guess is that, in some curses implementations, stdscr might be a > macro. A normal GRASS binary distribution wouldn't be compatible with > such an implementation; you would need to re-compile GRASS. Having thought about this some more, I'm more interested in how GDAL ends up using the parts of GRASS which use the vask library. ... I should have guessed; it's the imagery library: /* -------------------------------------------------------------------- */ /* Check if this is a valid GRASS imagery group. */ /* -------------------------------------------------------------------- */ else { struct Ref ref; I_init_group_ref( &ref ); if ( I_get_group_ref( pszName, &ref ) == 0 ) { free(pszGisdb); free(pszLoc); free(pszMapset); free(pszElem); free(pszName); return NULL; } for( int iRef = 0; iRef < ref.nfiles; iRef++ ) { papszCells = CSLAddString( papszCells, ref.file[iRef].name ); papszMapsets = CSLAddString( papszMapsets, ref.file[iRef].mapset ); G_add_mapset_to_search_path ( ref.file[iRef].mapset ); } I_free_group_ref( &ref ); } Now, none of this involves vask, but because some parts of the imagery library require it, the imagery library itself requires it. AFAICT, the following files from lib/imagery actually use vask: file used by ask_bands.c ask_colors.c tape_info.c v_exec.c ask_bands.c, tape_info.c (both unused) vask_group.c i.class IOW, the only reason why the imagery library needs to use vask is because i.class uses I_vask_subgroup_old(). In which case, that code can be moved to i.class, leaving the vask and edit libraries as the only libraries which uses curses. More later ... -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Sat Dec 2 12:38:03 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Dec 2 12:25:00 2006 Subject: [GRASS-dev] configuring grass 6.3 for cross compilation In-Reply-To: <17777.23374.323542.605684@cerise.gclements.plus.com> References: <45702C67.80307@ufg.uni-kiel.de> <17776.49711.359993.548386@cerise.gclements.plus.com> <17777.23374.323542.605684@cerise.gclements.plus.com> Message-ID: <4571659B.5060306@ufg.uni-kiel.de> Ok, it works now. Thanks, Glynn. Glynn Clements wrote: > Glynn Clements wrote: > >>> Are there any updates on how to configure 6.3 for cross compilation? >>> Any help will be greatly appreciated! >> Right now, you can't. I'm looking into a fix, but until then you'll >> need to manually remove the check from the configure script. > > I've committed a change to the configure script which should fix this, > although I don't a cross-compilation environment to check it. > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From benjamin.ducke at ufg.uni-kiel.de Sat Dec 2 12:51:49 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Dec 2 12:38:46 2006 Subject: [GRASS-dev] missing VERSIONNUMBER in GRASS 6.3.cvs Message-ID: <457168D5.4020102@ufg.uni-kiel.de> I just noticed that the VERSIONNUMBER file does not seem to get installed any longer. GEM needs this to read the version of the installed GRASS! Is there a replacement? Can we have VERSIONNUMBER back? Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From glynn at gclements.plus.com Sat Dec 2 12:51:27 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 12:51:30 2006 Subject: [GRASS-dev] vask and undefined symbol: stdscr - was Re: [Gdal-dev] Error accessing Pgeo through ODBC In-Reply-To: <17777.23817.465851.809692@cerise.gclements.plus.com> References: <442163630611271603n6155ba9dk6339018c4348c2e2@mail.gmail.com> <20061201092613.GD32250@bartok.itc.it> <17776.48799.575408.324783@cerise.gclements.plus.com> <17777.23817.465851.809692@cerise.gclements.plus.com> Message-ID: <17777.26815.100589.821262@cerise.gclements.plus.com> Glynn Clements wrote: > AFAICT, the following files from lib/imagery actually use vask: > > file used by > > ask_bands.c > ask_colors.c > tape_info.c > v_exec.c ask_bands.c, tape_info.c (both unused) > vask_group.c i.class > > IOW, the only reason why the imagery library needs to use vask is > because i.class uses I_vask_subgroup_old(). In which case, that code > can be moved to i.class, leaving the vask and edit libraries as the > only libraries which uses curses. > > More later ... I've eliminated the vask dependency for lib/imagery. Now, the only things which should require curses are those which actually use it, primarily those which use the vask (i.ortho.photo, i.class, etc/set_data, r.le.setup, r.support, v.transform) or edit (etc/set_data, r.support) libraries, although a couple of modules use curses directly (e.g. d.colors, i.vpoints). -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Sat Dec 2 17:26:23 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sat Dec 2 17:13:20 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation Message-ID: <4571A92F.2000306@ufg.uni-kiel.de> Bad news: it seems impossible to cross-compile the current GRASS 6.3.cvs version. Bsically, every module I try to compile for Win32 on my Linux box fails with sth. like this: *** No rule to make target `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so', needed by `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe Obviously, it should not be looking for libgrass_vect.so but for libgrass_vect.dll ! I am still able to compile the same modules, using the same tools, in a GRASS 6.1.CVS tree! Maybe some change to the configure script or one of the GRASS makefiles broke something? Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From grass-bugs at intevation.de Sat Dec 2 18:23:25 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Dec 2 18:23:26 2006 Subject: [GRASS-dev] [bug #5365] (grass) lukas1990 Message-ID: <20061202172325.1C4781006AB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5365 ------------------------------------------------------------------------- Subject: lukas1990 Platform: WindowsNT/2000/XP grass binary for platform: Downloaded precompiled Binaries Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Sat Dec 2 18:45:41 2006 From: michael.barton at asu.edu (Michael Barton) Date: Sat Dec 2 18:45:56 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: <17777.23639.817918.518816@cerise.gclements.plus.com> Message-ID: On 12/2/06 3:58 AM, "Glynn Clements" wrote: > What do you mean by a "full" install? GRASS needs GDAL regardless of > r.{in,out}.gdal. > > You will need GDAL headers and library to build r.out.gdal, and the > library to run it. > > OTOH, GDAL won't need to be built with GRASS support, so you don't > need to build GDAL without GRASS, build GDAL, then build it again with > GRASS (unless you need GDAL to have GRASS support for some other > reason). > Actually, it appears that I really had two questions. One you've answered. The other is will GDAL need to be installed for GRASS binaries to work after it has been built? Thanks Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-bugs at intevation.de Sat Dec 2 19:08:17 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sat Dec 2 19:08:19 2006 Subject: [GRASS-dev] [bug #3646] (grass) NVIZ: eye -> center = scene setup destroyed Message-ID: <20061202180817.913481005D9@lists.intevation.de> The bug is fixed in CVS, thanks to Bob and Michael. Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Sat Dec 2 19:23:17 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Dec 2 19:23:21 2006 Subject: [GRASS-dev] Re: [bug #5341] Data corruption problem with v.db.select In-Reply-To: <20061201152354.230909a2.hamish_nospam@yahoo.com> References: <20061130092443.447421006AB@lists.intevation.de> <20061201152354.230909a2.hamish_nospam@yahoo.com> Message-ID: <4571C495.4070703@o2.pl> For the thread completeness - Hamish has fixed this in CVS. Maciek From glynn at gclements.plus.com Sat Dec 2 19:29:51 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 19:29:53 2006 Subject: [GRASS-dev] missing VERSIONNUMBER in GRASS 6.3.cvs In-Reply-To: <457168D5.4020102@ufg.uni-kiel.de> References: <457168D5.4020102@ufg.uni-kiel.de> Message-ID: <17777.50719.207536.432384@cerise.gclements.plus.com> Benjamin Ducke wrote: > I just noticed that the VERSIONNUMBER file does not seem to get > installed any longer. GEM needs this to read the version of the > installed GRASS! Is there a replacement? Can we have VERSIONNUMBER It gets installed here. Are you sure that you didn't get an error in lib/init? -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 19:41:08 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 19:41:10 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <4571A92F.2000306@ufg.uni-kiel.de> References: <4571A92F.2000306@ufg.uni-kiel.de> Message-ID: <17777.51396.332236.298841@cerise.gclements.plus.com> Benjamin Ducke wrote: > Bad news: > it seems impossible to cross-compile the current GRASS 6.3.cvs version. > > Bsically, every module I try to compile for Win32 on my Linux box fails > with sth. like this: > > *** No rule to make target > `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so', > needed by > `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe > > Obviously, it should not be looking for libgrass_vect.so but for > libgrass_vect.dll ! > > I am still able to compile the same modules, using the same tools, in a > GRASS 6.1.CVS tree! > > Maybe some change to the configure script or one of the GRASS makefiles > broke something? Odd. AFAICT, cross-compiling shared libraries should never have worked. SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns the build platform, not the host platform. It should be using either $host or the components $host_cpu, $host_vendor, and $host_os. -- Glynn Clements From glynn at gclements.plus.com Sat Dec 2 19:45:20 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Dec 2 19:46:39 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: <17777.23639.817918.518816@cerise.gclements.plus.com> Message-ID: <17777.51648.843562.98463@cerise.gclements.plus.com> Michael Barton wrote: > > What do you mean by a "full" install? GRASS needs GDAL regardless of > > r.{in,out}.gdal. > > > > You will need GDAL headers and library to build r.out.gdal, and the > > library to run it. > > > > OTOH, GDAL won't need to be built with GRASS support, so you don't > > need to build GDAL without GRASS, build GDAL, then build it again with > > GRASS (unless you need GDAL to have GRASS support for some other > > Actually, it appears that I really had two questions. One you've answered. > The other is will GDAL need to be installed for GRASS binaries to work after > it has been built? If you build GRASS against shared GDAL libraries, you will need those libraries to run GRASS. If you use static GDAL libraries, you don't need those to run GRASS, although you will still need any of GDAL's dependencies which are themselves shared libraries. -- Glynn Clements From neteler at itc.it Sat Dec 2 20:59:03 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Dec 2 20:59:05 2006 Subject: [GRASS-dev] Re: r.to.rast3elev In-Reply-To: <20061202195747.GA20001@bartok.itc.it> References: <20061202195747.GA20001@bartok.itc.it> Message-ID: <20061202195903.GB20001@bartok.itc.it> I have added r.to.rast3elev to 6.2.-CVS-relbranch which required a backport of parser.c macros, too. Compilation tested and works. The today's snapshot of 6.2.-CVS-relbranch contains it. Markus On Sat, Dec 02, 2006 at 08:57:47PM +0100, Markus Neteler wrote: > No objections from here, I was thinking the same. > > Markus > > Hamish wrote on 12/01/2006 09:09 AM: > > Anybody object to activating this module in the GRASS 6.2 release branch? > > > > > > Hamish > > > > > > S??ren wrote: > > > >> not critical, but i think r.to.rast3elev is stable enough and offers a > >> lot of nice features. Some users also requested this module in grass > >> 6.2, but i missed the release termin. > >> > >> So it would be nice to have r.to.rast3elev in grass 6.2.1. > >> From landa.martin at gmail.com Sat Dec 2 21:55:34 2006 From: landa.martin at gmail.com (Martin Landa) Date: Sat Dec 2 21:55:36 2006 Subject: [GRASS-dev] [bug #5219] (grass) d.vect display=cat works only for layer 1 In-Reply-To: <20061018104828.F3708101FA2@lists.intevation.de> References: <20061018104828.F3708101FA2@lists.intevation.de> Message-ID: Hi, 2006/10/18, Request Tracker : > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219 > ------------------------------------------------------------------------- > > Subject: d.vect display=cat works only for layer 1 > > Although I specify 'layer=2' to be queried, the 'd.vect display=shape,cat' > displays catgory numbers from layer 1, instead of layer 2. > > It is reproducible with any data. Eg.: > > 1. v.random out=pts n=10 > 2. v.category input=pts output=pts2 type=point option=add cat=100 layer=2 step=10 > 3. d.vect pts2 layer=1 display=shape,cat > 4. d.vect pts2 layer=2 display=shape,cat > > You'll see the pictures of 3. and 4. are identical, while they shouldn't, as > the cats in layer 2 and layer 1 of pts2 are different, It seems you have to specify the llayer parameter too, e.g. d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2 It is really confusing, I am not sure how to solve it. Do you think, would be enough to print a given warning, e.g. "The layer number (2) and layer number for labels (1) are not the same.". Best, Martin PS: I am really looking forward to the new bug tracker! Thanks Maciek for working on it... > Seems kind of related to another layer-related bug in d.vect: > https://intevation.de/rt/webrt?serial_num=4004 > > Maciek > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From benjamin.ducke at ufg.uni-kiel.de Sun Dec 3 11:39:52 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Sun Dec 3 11:26:47 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <17777.51396.332236.298841@cerise.gclements.plus.com> References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> Message-ID: <4572A978.2020402@ufg.uni-kiel.de> Hmmmm, but I just tried a 6.2.0 source tree and used these instructions: http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux ... and it worked OK, too! And all the GRASS libs it made are definitely shared DLLs. (although I did not get GDAL support working, but that's not important for me at this point) Glynn Clements wrote: > Benjamin Ducke wrote: > >> Bad news: >> it seems impossible to cross-compile the current GRASS 6.3.cvs version. >> >> Bsically, every module I try to compile for Win32 on my Linux box fails >> with sth. like this: >> >> *** No rule to make target >> `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so', >> needed by >> `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe >> >> Obviously, it should not be looking for libgrass_vect.so but for >> libgrass_vect.dll ! >> >> I am still able to compile the same modules, using the same tools, in a >> GRASS 6.1.CVS tree! >> >> Maybe some change to the configure script or one of the GRASS makefiles >> broke something? > > Odd. > > AFAICT, cross-compiling shared libraries should never have worked. > SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns > the build platform, not the host platform. > > It should be using either $host or the components $host_cpu, > $host_vendor, and $host_os. > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From grass-bugs at intevation.de Sun Dec 3 22:00:32 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Sun Dec 3 22:00:34 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region Message-ID: <20061203210032.ED5891005BE@lists.intevation.de> Hi, can someone please review this g.region patch proposal? https://intevation.de/rt/webrt?serial_num=4451 thanks Markus -------------------------------------------- Managed by Request Tracker From dylan.beaudette at gmail.com Sun Dec 3 23:11:27 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Sun Dec 3 22:40:29 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region In-Reply-To: <20061203210032.ED5891005BE@lists.intevation.de> References: <20061203210032.ED5891005BE@lists.intevation.de> Message-ID: <200612031411.27610.dylan.beaudette@gmail.com> On Sunday 03 December 2006 13:00, Markus Neteler via RT wrote: > Hi, > > can someone please review this g.region patch proposal? > > https://intevation.de/rt/webrt?serial_num=4451 > > thanks > Markus > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev While I cannot vouch for the code aspect of this, the new options would be quite useful for my operations. Thanks Markus and others! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From grass-bugs at intevation.de Sun Dec 3 22:49:07 2006 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sun Dec 3 22:49:09 2006 Subject: [GRASS-dev] [bug #4110] (grass) v.digit: Could not set Tcl system encoding to Message-ID: <20061203214907.4FE2F1005BE@lists.intevation.de> mneteler wrote (Sat, Dec 2 2006 18:17:08): > I just merged some apparently related reports. These are 2 different issues. One thing is that ISO-8859-2 is not supported, which was the bug 4110. Adding iso-8859-2 to lib/form/generate.c as you suggested made v.digit listing it as one of available encodings when editing data attributes (cool). However, still Polish accented letters in v.digit are displayed as garbage when entered, and d.what.vect in form mode prints them as garbage as well. This is propably to the other issue #3131, that v.digit keeps on printing the error to the terminal: D0/0: Name = _grass_internal_database_encoding Could not set Tcl system encoding to no matter what encoding is used. According to Glynn's analysis of lib/form/form.c "the encoding name is an empty string" - see his note from Wed, Feb 22 2006 14:08:26. Maciek -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Mon Dec 4 01:50:21 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Dec 4 01:50:31 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <4572A978.2020402@ufg.uni-kiel.de> References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> <4572A978.2020402@ufg.uni-kiel.de> Message-ID: <17779.28877.162022.812361@cerise.gclements.plus.com> Benjamin Ducke wrote: > Hmmmm, but I just tried a 6.2.0 source tree and used these instructions: > http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux > > ... and it worked OK, too! > > And all the GRASS libs it made are definitely shared DLLs. Those instructions don't appear to use the GRASS configure script, but a "winconfigure" script which is presumably supplied with QGIS. -- Glynn Clements From glynn at gclements.plus.com Mon Dec 4 01:58:41 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Dec 4 01:58:49 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region In-Reply-To: <20061203210032.ED5891005BE@lists.intevation.de> References: <20061203210032.ED5891005BE@lists.intevation.de> Message-ID: <17779.29377.966414.414928@cerise.gclements.plus.com> Markus Neteler via RT wrote: > can someone please review this g.region patch proposal? > > https://intevation.de/rt/webrt?serial_num=4451 I don't see any point in the size= option; I wouldn't expect it to be used much, and you can always just pass the same value to rows= and cols=. The rest of it seems fine. -- Glynn Clements From hamish_nospam at yahoo.com Mon Dec 4 02:50:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 4 02:50:46 2006 Subject: [GRASS-dev] [bug #5219] (grass) d.vect display=cat works only for layer 1 In-Reply-To: References: <20061018104828.F3708101FA2@lists.intevation.de> Message-ID: <20061204145039.72d9d68a.hamish_nospam@yahoo.com> Martin Landa wrote: > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219 > > ------------------------------------------------------------------- .. > It seems you have to specify the llayer parameter too, e.g. > > d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2 > > It is really confusing, I am not sure how to solve it. Do you think, > would be enough to print a given warning, e.g. "The layer number (2) > and layer number for labels (1) are not the same.". It would appear to be perfectly legal to display shapes from one layer and labels from another. So if this should be mentioned at all, it should use G_message and not G_warning? (so --quiet makes it go away) At minimum the label section of the d.vect help page needs to clarify this. Hamish From benjamin.ducke at ufg.uni-kiel.de Mon Dec 4 08:50:34 2006 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Dec 4 08:37:28 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <17779.28877.162022.812361@cerise.gclements.plus.com> References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> <4572A978.2020402@ufg.uni-kiel.de> <17779.28877.162022.812361@cerise.gclements.plus.com> Message-ID: <4573D34A.4040801@ufg.uni-kiel.de> Of course, that's the difference! I am using that script myself ... my fault. Are there any plans to modify the GRASS configure script to allow for MINGW cross compilation? Glynn Clements wrote: > Benjamin Ducke wrote: > >> Hmmmm, but I just tried a 6.2.0 source tree and used these instructions: >> http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux >> >> ... and it worked OK, too! >> >> And all the GRASS libs it made are definitely shared DLLs. > > Those instructions don't appear to use the GRASS configure script, but > a "winconfigure" script which is presumably supplied with QGIS. > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From landa.martin at gmail.com Mon Dec 4 10:07:00 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Dec 4 10:07:02 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region In-Reply-To: <17779.29377.966414.414928@cerise.gclements.plus.com> References: <20061203210032.ED5891005BE@lists.intevation.de> <17779.29377.966414.414928@cerise.gclements.plus.com> Message-ID: Hi, I have updated the patch for the current CVS + reordering flags (Print) + capitalize messages/warnings/ferrors - removing size parameter Any objections? Best, Martin 2006/12/4, Glynn Clements : > > Markus Neteler via RT wrote: > > > can someone please review this g.region patch proposal? > > > > https://intevation.de/rt/webrt?serial_num=4451 > > I don't see any point in the size= option; I wouldn't expect it to be > used much, and you can always just pass the same value to rows= and > cols=. > > The rest of it seems fine. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g_region_rc.diff.gz Type: application/x-gzip Size: 3577 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061204/31ef21e2/g_region_rc.diff.gz From landa.martin at gmail.com Mon Dec 4 12:15:52 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Dec 4 12:15:56 2006 Subject: [GRASS-dev] [bug #5219] (grass) d.vect display=cat works only for layer 1 In-Reply-To: <20061204145039.72d9d68a.hamish_nospam@yahoo.com> References: <20061018104828.F3708101FA2@lists.intevation.de> <20061204145039.72d9d68a.hamish_nospam@yahoo.com> Message-ID: Hi, 2006/12/4, Hamish : > Martin Landa wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219 > > > ------------------------------------------------------------------- > .. > > It seems you have to specify the llayer parameter too, e.g. > > > > d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2 > > > > It is really confusing, I am not sure how to solve it. Do you think, > > would be enough to print a given warning, e.g. "The layer number (2) > > and layer number for labels (1) are not the same.". > > > It would appear to be perfectly legal to display shapes from one layer > and labels from another. So if this should be mentioned at all, it > should use G_message and not G_warning? (so --quiet makes it go away) > At minimum the label section of the d.vect help page needs to clarify > this. I agree with you, the similar patch (note: without doc update)? Best regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: d_vect_llayer.diff.gz Type: application/x-gzip Size: 503 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061204/50dde4ba/d_vect_llayer.diff.gz From landa.martin at gmail.com Mon Dec 4 12:25:11 2006 From: landa.martin at gmail.com (Martin Landa) Date: Mon Dec 4 12:25:14 2006 Subject: [GRASS-dev] [bug #5219] (grass) d.vect display=cat works only for layer 1 In-Reply-To: References: <20061018104828.F3708101FA2@lists.intevation.de> <20061204145039.72d9d68a.hamish_nospam@yahoo.com> Message-ID: ... oops, I forgot to test DISP_CAT, etc. The updated patch attached. Martin 2006/12/4, Martin Landa : > Hi, > > 2006/12/4, Hamish : > > Martin Landa wrote: > > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219 > > > > ------------------------------------------------------------------- > > .. > > > It seems you have to specify the llayer parameter too, e.g. > > > > > > d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2 > > > > > > It is really confusing, I am not sure how to solve it. Do you think, > > > would be enough to print a given warning, e.g. "The layer number (2) > > > and layer number for labels (1) are not the same.". > > > > > > It would appear to be perfectly legal to display shapes from one layer > > and labels from another. So if this should be mentioned at all, it > > should use G_message and not G_warning? (so --quiet makes it go away) > > At minimum the label section of the d.vect help page needs to clarify > > this. > > I agree with you, the similar patch (note: without doc update)? > > Best regards, Martin > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: d_vect-llayer-2.diff.gz Type: application/x-gzip Size: 548 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061204/c2084620/d_vect-llayer-2.diff.gz From grass-bugs at intevation.de Mon Dec 4 15:10:03 2006 From: grass-bugs at intevation.de (Markus Neteler via RT) Date: Mon Dec 4 15:10:10 2006 Subject: [GRASS-dev] [bug #4110] (grass) v.digit: Could not set Tcl system encoding to Message-ID: <20061204141003.41E9A1006AB@lists.intevation.de> I have added some encodings which are listed now (but cannot be applied apart from UTF-8). I found also that ../../include/form.h:#define F_ENCODING "_grass_internal_database_encoding" which seems to be the default. More reasonable G_debug messages are in CVS now (debug level 3). Question: theurrent GRASS_DB_ENCODING is (null) - should predefine GRASS_DB_ENCODING in lib/init/init.sh (if so, to which encoding?) I don't quite understand how this encoding thing works. Markus -------------------------------------------- Managed by Request Tracker From neteler at itc.it Mon Dec 4 17:33:27 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Dec 4 17:33:29 2006 Subject: [GRASS-dev] implementing drop column into DBF driver Message-ID: <20061204163327.GC25728@bartok.itc.it> Hi, I tried to implement drop column into DBF driver to get rid of columns like 'cat_' when re-importing an exported map: echo "ALTER TABLE mymap DROP COLUMN cat_" | db.execute Attached the changes to lib/db/sqlp/ and /db/drivers/dbf/ The idea is to load the table internally in SQLP_DROP_COLUMN (such as SQLP_ADD_COLUMN does) but to jump over the column which we want to drop. So I took load_table() and made it load_table_selective(), most likely in an ugly way. While ugly, it could work but apparently I never reach SQLP_DROP_COLUMN. It bails out with ... D3/3: sql: ALTER TABLE mymap DROP COLUMN cat_ D3/3: SQL statement parsed successfully: ALTER TABLE mymap DROP COLUMN cat_ ... D3/3: add_column(): tab = 11, type = 3, name = edg_id, width = 20, decimals = 6 D3/3: Doing SQL command <8> on DBF table... (see include/sqlp.h) dbmi: Protocol error D2/3: G__home home = /home/neteler ERROR: Error while executing: "ALTER TABLE mymap DROP COLUMN cat_ " I have no clue why. Help is welcome. Thanks, Markus -------------- next part -------------- ? include/config.h ? include/version.h ? include/winname.h ? include/Make/Grass.make ? include/Make/Platform.make ? lib/db/dbmi_base/OBJ.i686-pc-linux-gnu ? lib/db/dbmi_client/OBJ.i686-pc-linux-gnu ? lib/db/dbmi_driver/OBJ.i686-pc-linux-gnu ? lib/db/sqlp/OBJ.i686-pc-linux-gnu ? lib/db/sqlp/lex.yy.c ? lib/db/sqlp/y.output ? lib/db/sqlp/y.tab.c ? lib/db/sqlp/y.tab.h ? lib/db/stubs/OBJ.i686-pc-linux-gnu Index: include/sqlp.h =================================================================== RCS file: /home/grass/grassrepository/grass6/include/sqlp.h,v retrieving revision 1.18 diff -u -r1.18 sqlp.h --- include/sqlp.h 10 Oct 2006 08:21:34 -0000 1.18 +++ include/sqlp.h 4 Dec 2006 16:14:10 -0000 @@ -10,6 +10,7 @@ #define SQLP_UPDATE 5 #define SQLP_DELETE 6 #define SQLP_ADD_COLUMN 7 +#define SQLP_DROP_COLUMN 8 /* SQL OPERATORS */ /* Arithmetical */ Index: lib/db/sqlp/print.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/db/sqlp/print.c,v retrieving revision 1.12 diff -u -r1.12 print.c --- lib/db/sqlp/print.c 10 Oct 2006 08:19:34 -0000 1.12 +++ lib/db/sqlp/print.c 4 Dec 2006 16:14:10 -0000 @@ -75,6 +75,9 @@ case (SQLP_DROP): fprintf( stderr, "DROP\n"); break; + case (SQLP_DROP_COLUMN): + fprintf( stderr, "DROP COLUMN\n"); + break; case (SQLP_INSERT): fprintf( stderr, "INSERT\n"); break; Index: lib/db/sqlp/yac.y =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/db/sqlp/yac.y,v retrieving revision 1.24 diff -u -r1.24 yac.y --- lib/db/sqlp/yac.y 10 Oct 2006 08:19:34 -0000 1.24 +++ lib/db/sqlp/yac.y 4 Dec 2006 16:14:11 -0000 @@ -104,6 +104,8 @@ y_alter: ALTER TABLE y_table ADD COLUMN y_columndef { sqpCommand(SQLP_ADD_COLUMN); } | ALTER TABLE y_table ADD y_columndef { sqpCommand(SQLP_ADD_COLUMN); } + | ALTER TABLE y_table DROP COLUMN y_column { sqpCommand(SQLP_DROP_COLUMN); } + ; y_create: -------------- next part -------------- ? db/drivers/dbf/OBJ.i686-pc-linux-gnu Index: db/drivers/dbf/dbfexe.c =================================================================== RCS file: /home/grass/grassrepository/grass6/db/drivers/dbf/dbfexe.c,v retrieving revision 1.38 diff -u -r1.38 dbfexe.c --- db/drivers/dbf/dbfexe.c 10 Oct 2006 08:20:25 -0000 1.38 +++ db/drivers/dbf/dbfexe.c 4 Dec 2006 16:25:39 -0000 @@ -70,7 +70,7 @@ } G_free ( tmpsql) ; - G_debug (3, "SQL statement parsed successfully" ); + G_debug (3, "SQL statement parsed successfully: %s", sql ); /* sqpPrintStmt(st); */ /* debug output only */ @@ -91,7 +91,8 @@ } if ((st->command == SQLP_DROP) || (st->command == SQLP_DELETE) || - (st->command == SQLP_INSERT) || (st->command == SQLP_UPDATE) || (st->command == SQLP_ADD_COLUMN) + (st->command == SQLP_INSERT) || (st->command == SQLP_UPDATE) || + (st->command == SQLP_ADD_COLUMN) || (st->command == SQLP_DROP_COLUMN) ) { if ( db.tables[tab].write == FALSE ) { append_error( "Cannot modify table, don't have write permission for DBF file.\n"); @@ -102,7 +103,7 @@ /* find columns */ ncols = st->nCol; if (st->command == SQLP_INSERT || st->command == SQLP_SELECT - || st->command == SQLP_UPDATE) { + || st->command == SQLP_UPDATE || st->command == SQLP_DROP_COLUMN) { if (ncols > 0) { /* colums were specified */ cols = (int *) G_malloc (ncols * sizeof(int)); for (i = 0; i < ncols; i++) { @@ -140,6 +141,7 @@ } /* do command */ + G_debug(3,"Doing SQL command <%d> on DBF table... (see include/sqlp.h)", st->command); switch (st->command) { case (SQLP_ADD_COLUMN): load_table(tab); @@ -159,6 +161,15 @@ dbval->d = 0.0; dbval->c = NULL; dbval->is_null = 1; + } + db.tables[tab].updated = TRUE; + break; + + case (SQLP_DROP_COLUMN): + ret = load_table_selective(tab, st->Col[0].s); + if ( ret == DB_FAILED ) { + append_error("Cannot delete column.\n"); + return DB_FAILED; } db.tables[tab].updated = TRUE; break; Index: db/drivers/dbf/proto.h =================================================================== RCS file: /home/grass/grassrepository/grass6/db/drivers/dbf/proto.h,v retrieving revision 1.4 diff -u -r1.4 proto.h --- db/drivers/dbf/proto.h 16 Mar 2004 13:06:33 -0000 1.4 +++ db/drivers/dbf/proto.h 4 Dec 2006 16:25:39 -0000 @@ -17,6 +17,7 @@ int free_table ( int ); int find_table ( char * ); int load_table_head( int ); +int load_table_selective ( int, char *); int load_table( int ); int save_table( int ); int describe_table( int, int *, int, dbTable ** ); Index: db/drivers/dbf/table.c =================================================================== RCS file: /home/grass/grassrepository/grass6/db/drivers/dbf/table.c,v retrieving revision 1.18 diff -u -r1.18 table.c --- db/drivers/dbf/table.c 9 Feb 2006 03:08:48 -0000 1.18 +++ db/drivers/dbf/table.c 4 Dec 2006 16:25:39 -0000 @@ -216,6 +216,78 @@ return DB_OK; } +/* loads table except for dropcol */ +int +load_table_selective ( int t, char *dropcol) +{ + int i, j, ncols, nrows, dbfcol; + DBFHandle dbf; + char *buf; + ROW *rows; + VALUE *val; + + G_debug ( 3, "load_table_selective(): tab = %d dropcol = %s", t, dropcol); + + if ( db.tables[t].loaded == TRUE ) /*already loaded */ + return DB_OK; + + dbf = DBFOpen( db.tables[t].file, "r" ); + if( dbf == NULL ) { + append_error("Cannot open dbf file.\n"); + return DB_FAILED; + } + + ncols = db.tables[t].ncols; + nrows = DBFGetRecordCount( dbf ); + rows = db.tables[t].rows; + rows = (ROW *) G_malloc ( nrows * sizeof(ROW) ); + db.tables[t].arows = nrows; + + G_debug ( 2, " ncols = %d nrows = %d", ncols, nrows); + + for( i = 0; i < nrows; i++ ) + { + rows[i].alive = TRUE; + rows[i].values = (VALUE *) G_calloc ( ncols, sizeof (VALUE) ); + + for( j = 0; j < ncols; j++ ) + { + /* jump over column to drop */ + if ( G_strcasecmp( db.tables[t].cols[j].name, dropcol ) == 0 ) + continue; + + val = &(rows[i].values[j]); + + dbfcol = j; + + val->is_null = DBFIsAttributeNULL ( dbf, i, dbfcol ); + if ( !(val->is_null) ) { + switch ( db.tables[t].cols[j].type ) + { + case DBF_INT: + val->i = DBFReadIntegerAttribute( dbf, i, dbfcol ); + break; + case DBF_CHAR: + buf = (char *) DBFReadStringAttribute( dbf, i, dbfcol ); + save_string ( val, buf); + break; + case DBF_DOUBLE: + val->d = DBFReadDoubleAttribute( dbf, i, dbfcol ); + break; + } + } + } + } + + DBFClose ( dbf ); + + db.tables[t].rows = rows; + db.tables[t].nrows = nrows -1; /* one less */ + db.tables[t].loaded = TRUE; + + return DB_OK; +} + int save_table ( int t) { From michael.barton at asu.edu Mon Dec 4 20:17:03 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Dec 4 20:17:50 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region In-Reply-To: <20061203210032.ED5891005BE@lists.intevation.de> Message-ID: On 12/3/06 2:00 PM, "Markus Neteler via RT" wrote: > Hi, > > can someone please review this g.region patch proposal? > > https://intevation.de/rt/webrt?serial_num=4451 > > thanks > Markus Looks good to me. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Tue Dec 5 01:44:44 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Dec 5 01:44:47 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <4573D34A.4040801@ufg.uni-kiel.de> References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> <4572A978.2020402@ufg.uni-kiel.de> <17779.28877.162022.812361@cerise.gclements.plus.com> <4573D34A.4040801@ufg.uni-kiel.de> Message-ID: <17780.49404.951530.711239@cerise.gclements.plus.com> Benjamin Ducke wrote: > Are there any plans to modify the GRASS configure script to > allow for MINGW cross compilation? SC_CONFIG_FLAGS would need to be changed to use $host etc rather than the output from "uname". The main problem is that the two approaches use entirely different platform identifiers. E.g on my system: # this is what SC_CONFIG_FLAGS uses $ echo `uname -s`-`uname -r` Linux-2.6.15.1 # this is what autoconf says $ ./configure ... ... GRASS is now configured for: i686-pc-linux-gnu ... IOW, someone would need to change all of the "case" patterns to use autoconf names instead, which means figuring out the mapping between the two. The only viable solution I can see is to essentially scrap the bulk of the existing SC_CONFIG_FLAGS macro, and replace it with: case $host in i?86-pc-linux-*) SHLIB_CFLAGS="-fPIC" SHLIB_SUFFIX=".so" CFLAGS_OPTIMIZE=-O2 SHLIB_LD="${CC} -shared" LDFLAGS="-Wl,--export-dynamic" LD_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}' ;; *) AC_MSG_ERROR([*** Unsupported platform: $host; please update SC_CONFIG_FLAGS in aclocal.m4]) ;; esac Then, we wait for people to contribute the information which we need to support the other platforms. The downside is that the other platforms won't be supported until that happens. -- Glynn Clements From hamish_nospam at yahoo.com Tue Dec 5 02:20:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 5 02:20:50 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.surf.rst limitations? In-Reply-To: <20061204211107.ir0iigv34koowskk@webmail.polimi.it> References: <20061204181537.18496.qmail@web36501.mail.mud.yahoo.com> <20061204211107.ir0iigv34koowskk@webmail.polimi.it> Message-ID: <20061205142039.18b7b40b.hamish_nospam@yahoo.com> Hi Roberto, here are some updates for v.surf.bspline vs. today's CVS. The most important is not calling G_write_history() until after the raster map is closed with G_close_cell(). Also: * added opt->guisection for some options to make the GUI less cluttered. (feel free to come up with a better name for the tab) * added G_command_history() to save the command line into the history file so you can later know what the input map and settings were, and G_put_cell_title() to set the output map title. (see r.resamp.interp) I think it is good policy that all modules which create a new raster map should use those. Hamish -------------- next part -------------- ? OBJ.i686-pc-linux-gnu ? vsb_5dec.diff Index: main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/vector/lidar/v.bspline/main.c,v retrieving revision 1.5 diff -u -r1.5 main.c --- main.c 4 Sep 2006 23:58:47 -0000 1.5 +++ main.c 5 Dec 2006 01:16:40 -0000 @@ -38,7 +38,7 @@ int last_row, last_column, grid, bilin, flag_ext, flag_auxiliar; /* booleans */ double passoN, passoE, lambda, mean; - char *mapset, *dvr, *db, *vector, *map, table_name[1024]; /* */ + char *mapset, *dvr, *db, *vector, *map, table_name[1024], title[64]; int *lineVect; /* Vector restoring primitive's ID*/ double **raster_matrix; /* Matrix to store the auxiliar raster values*/ @@ -49,10 +49,10 @@ struct Map_info In, In_ext, Out; struct GModule *module; - struct Option *in_opt, *in_ext_opt, *out_opt, *out_map_opt, *dbdriver, *dbdatabase, \ - *passoE_opt, *passoN_opt, *lambda_f_opt, *type; + struct Option *in_opt, *in_ext_opt, *out_opt, *out_map_opt, *dbdriver, + *dbdatabase, *passoE_opt, *passoN_opt, *lambda_f_opt, *type; struct History history; - + struct Cell_head elaboration_reg, original_reg; struct Reg_dimens dims; BOUND_BOX general_box, overlap_box; @@ -67,16 +67,11 @@ /* Options' declaration */ module = G_define_module(); module->keywords = _("vector, interpolation"); - module->description = _("Bicubic or bilineal interpolation with Tykhonov regularization"); + module->description = + _("Bicubic or bilineal interpolation with Tykhonov regularization"); + + in_opt = G_define_standard_option(G_OPT_V_INPUT); - in_opt = G_define_option () ; - in_opt->key = "input"; - in_opt->type = TYPE_STRING; - in_opt->key_desc = "name"; - in_opt->required = YES; - in_opt->gisprompt = "old,vector,vector"; - in_opt->description = _("Name of input vector map"); - in_ext_opt = G_define_option () ; in_ext_opt->key = "input_ext"; in_ext_opt->type = TYPE_STRING; @@ -85,22 +80,13 @@ in_ext_opt->gisprompt = "old,vector,vector"; in_ext_opt->description = _("Name of input vector map of sparse points"); - out_opt = G_define_option () ; - out_opt->key = "output"; - out_opt->type = TYPE_STRING; - out_opt->key_desc = "name"; + out_opt = G_define_standard_option(G_OPT_V_OUTPUT); out_opt->required = NO; - out_opt->gisprompt = "new,vector,vector"; - out_opt->description = _("Name of output vector map"); - - out_map_opt = G_define_option () ; + + out_map_opt = G_define_standard_option(G_OPT_R_OUTPUT); out_map_opt->key = "raster_out"; - out_map_opt->type = TYPE_STRING; - out_map_opt->key_desc = "name"; - out_map_opt->gisprompt = "new,cell,raster"; out_map_opt->required = NO; - out_map_opt->description = _("Name of output raster map"); - + dbdatabase = G_define_option() ; dbdatabase->key = "database" ; dbdatabase->type = TYPE_STRING ; @@ -109,7 +95,7 @@ dbdatabase->description = _("Database name"); if ( (db=G__getenv2("DB_DATABASE",G_VAR_MAPSET)) ) dbdatabase->answer = G_store ( db ); - + dbdriver = G_define_option() ; dbdriver->key = "driver" ; dbdriver->type = TYPE_STRING ; @@ -119,20 +105,24 @@ dbdriver->description = _("Driver name"); if ( (dvr = G__getenv2("DB_DRIVER",G_VAR_MAPSET)) ) dbdriver->answer = G_store ( dvr ); - + passoE_opt = G_define_option(); passoE_opt->key = "sie"; passoE_opt->type = TYPE_DOUBLE; passoE_opt->required = NO; passoE_opt->answer = "4"; - passoE_opt->description = _("Interpolation spline step value in east direction"); - + passoE_opt->guisection = "Settings"; + passoE_opt->description = + _("Interpolation spline step value in east direction"); + passoN_opt = G_define_option(); passoN_opt->key = "sin"; passoN_opt->type = TYPE_DOUBLE; passoN_opt->required = NO; passoN_opt->answer = "4"; - passoN_opt->description = _("Interpolation spline step value in north direction"); + passoN_opt->guisection = "Settings"; + passoN_opt->description = + _("Interpolation spline step value in north direction"); type = G_define_option(); type->key = "type"; @@ -141,13 +131,15 @@ type->description = _("Spline type of interpolation"); type->options = "bilinear,bicubic"; type->answer = "bilinear"; - + type->guisection = "Settings"; + lambda_f_opt = G_define_option(); lambda_f_opt->key = "lambda_i"; lambda_f_opt->type = TYPE_DOUBLE; lambda_f_opt->required = NO; lambda_f_opt->description =_("Thychonov regularization weigth"); lambda_f_opt->answer = "1"; + lambda_f_opt->guisection = "Settings"; /* Parsing */ G_gisinit(argv[0]); @@ -190,7 +182,7 @@ } else { flag_ext = TRUE; G_warning (_("<%s> vector map will be interpolated"), in_ext_opt->answer); - + if ((mapset = G_find_vector2 (in_ext_opt->answer, "")) == NULL) G_fatal_error ( _("Could not find input map <%s>"), in_ext_opt->answer); @@ -234,9 +226,6 @@ if ((raster = G_open_fp_cell_new (out_map_opt->answer)) < 0) G_fatal_error (_("Raster <%s> could not be open."), out_map_opt->answer); - - G_short_history (out_map_opt->answer, "raster", &history); - G_write_history (out_map_opt->answer, &history); } driver = db_start_driver_open_database (dbdriver->answer, dbdatabase->answer); @@ -457,8 +446,19 @@ Vect_close (&In); if (flag_ext != FALSE) Vect_close (&In_ext); if (vector) Vect_close (&Out); - - if (map) G_close_cell (raster); + + if (map) { + G_close_cell(raster); + + /* set map title */ + sprintf(title, "%s interpolation with Tykhonov regularization", + type->answer); + G_put_cell_title(out_map_opt->answer, title); + /* write map history */ + G_short_history(out_map_opt->answer, "raster", &history); + G_command_history(&history); + G_write_history(out_map_opt->answer, &history); + } G_done_msg(""); exit(EXIT_SUCCESS); From dca.gis at gmail.com Tue Dec 5 07:28:04 2006 From: dca.gis at gmail.com (Daniel Calvelo) Date: Tue Dec 5 07:28:07 2006 Subject: [GRASS-dev] implementing drop column into DBF driver In-Reply-To: <20061204163327.GC25728@bartok.itc.it> References: <20061204163327.GC25728@bartok.itc.it> Message-ID: <1a486f560612042228v7fad87fl662c4b50ad9f8bbd@mail.gmail.com> Hi Markus, Check st->nCol and whether st->Col[0] exist at the time you call load_table_selective. It seems that the bang happens around the point you call the function; the sqpAddColumn should have put your colname there, but... Daniel. On 12/4/06, Markus Neteler wrote: > Hi, > > I tried to implement drop column into DBF driver to get > rid of columns like 'cat_' when re-importing an exported map: > echo "ALTER TABLE mymap DROP COLUMN cat_" | db.execute > > Attached the changes to lib/db/sqlp/ and /db/drivers/dbf/ > > The idea is to load the table internally in SQLP_DROP_COLUMN > (such as SQLP_ADD_COLUMN does) but to jump over the column > which we want to drop. > So I took load_table() and made it load_table_selective(), > most likely in an ugly way. > > While ugly, it could work but apparently I never reach > SQLP_DROP_COLUMN. It bails out with > > ... > D3/3: sql: ALTER TABLE mymap DROP COLUMN cat_ > D3/3: SQL statement parsed successfully: ALTER TABLE mymap DROP COLUMN cat_ > ... > D3/3: add_column(): tab = 11, type = 3, name = edg_id, width = 20, decimals = 6 > D3/3: Doing SQL command <8> on DBF table... (see include/sqlp.h) > dbmi: Protocol error > D2/3: G__home home = /home/neteler > ERROR: Error while executing: "ALTER TABLE mymap DROP COLUMN cat_ > " > > I have no clue why. Help is welcome. > > Thanks, > Markus > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > > -- -- Daniel Calvelo Aros From grass-bugs at intevation.de Tue Dec 5 08:23:09 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Dec 5 08:23:11 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities Message-ID: <20061205072309.EE1D11005CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5367 ------------------------------------------------------------------------- Subject: 6.3 NVIZ: tcltk 8.3 incompatibilities Hi, in 6.3-cvs NVIZ, panel_rast.tcl and panel_main.tcl use "frame padx pady" in a few places. This is incompatible with Tcl/Tk 8.3 and causes a lock-up during the menu building. compare: http://www.tcl.tk/man/tcl8.3/TkCmd/frame.htm http://www.tcl.tk/man/tcl8.4/TkCmd/frame.htm thanks, Hamish -------------------------------------------- Managed by Request Tracker From roberto at geomatica.como.polimi.it Tue Dec 5 09:23:17 2006 From: roberto at geomatica.como.polimi.it (Roberto Antolin) Date: Tue Dec 5 09:24:49 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.surf.rst limitations? In-Reply-To: <20061205142039.18b7b40b.hamish_nospam@yahoo.com> References: <20061204181537.18496.qmail@web36501.mail.mud.yahoo.com> <20061204211107.ir0iigv34koowskk@webmail.polimi.it> <20061205142039.18b7b40b.hamish_nospam@yahoo.com> Message-ID: <45752C75.9090501@geomatica.como.polimi.it> Hi Hamish and all, Thank you for the update and the information :) I'll merge this update to my v.surf.bspline version and try to send my last updates today. Cheers, Roberto. Hamish ha scritto: >Hi Roberto, > >here are some updates for v.surf.bspline vs. today's CVS. > >The most important is not calling G_write_history() until after >the raster map is closed with G_close_cell(). > >Also: >* added opt->guisection for some options to make the GUI less >cluttered. (feel free to come up with a better name for the tab) > >* added G_command_history() to save the command line into the history >file so you can later know what the input map and settings were, and >G_put_cell_title() to set the output map title. (see r.resamp.interp) >I think it is good policy that all modules which create a new raster map >should use those. > > >Hamish > > -- Roberto Antol?n S?nchez Politecnico di Milano ? Polo Regionale di Como (Laboratorio di Geomatica V2.8) Via Valleggio, 11 ? 22100 Como, Italy tel: +39 031 332 7533 || fax: +39 031 332 7519 email: roberto.antolin@polimi.it From hamish_nospam at yahoo.com Tue Dec 5 09:35:13 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 5 09:35:21 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities In-Reply-To: <20061205072309.EE1D11005CB@lists.intevation.de> References: <20061205072309.EE1D11005CB@lists.intevation.de> Message-ID: <20061205213513.47288f1c.hamish_nospam@yahoo.com> > this bug's URL: http://intevation.de/rt/webrt?serial_num=5367 > --------------------------------------------------------------------- > > Subject: 6.3 NVIZ: tcltk 8.3 incompatibilities > > Hi, > > in 6.3-cvs NVIZ, panel_rast.tcl and panel_main.tcl use "frame padx > pady" in a few places. This is incompatible with Tcl/Tk 8.3 and causes > a lock-up during the menu building. > > compare: > http://www.tcl.tk/man/tcl8.3/TkCmd/frame.htm > http://www.tcl.tk/man/tcl8.4/TkCmd/frame.htm can the padx,y be moved to the "pack" step? Hamish From spano at cli.di.unipi.it Tue Dec 5 09:45:35 2006 From: spano at cli.di.unipi.it (Davide Spano) Date: Tue Dec 5 09:45:56 2006 Subject: [GRASS-dev] Re: v.in.gpsbabel bug? (with es file) In-Reply-To: <200612041626.35122.lami@faunalia.it> References: <200612041615.03970.lami@faunalia.it> <200612041626.35122.lami@faunalia.it> Message-ID: <1165308335.5327.13.camel@davideDesktop> Il giorno lun, 04/12/2006 alle 16.26 +0100, Leonardo Lami ha scritto: > Hi all, > I'm testing v.in.gpsbabel but I found a not corrspondence between tha datas > associated to the point in gps and the datas associated to the new vector. > > If I use a gps Garmin 12 (not Etrex) the label associated to the points > (second column in the file > gps.csv, download by gpstrans) is not present in the table associated to > the vector (gpsbabel.dbf). > > If I use gps Garmin 12 Etrex it works well (gpsbabel_etrex.dbf). > > Does someone know this bug? > > Thank you for help > > Regards > Leonardo > Hi all, I think that the field is not correctly recognized by gpsbabel, the script make only textual manipulation on his output... It can be that gpsbabel download the column with a different tag from the other garmin gps, and this tag is not included in csv stylesheet... If the problem is only on one gps receiver model, I think it his hard to fix (we had to download a meaningless column for all others gps receivers), but if it is common problem, we had to fix it. Leonardo, please try watching on temporary files to see if I'm right. PS Please report if it happens on other receivers... Davide From hamish_nospam at yahoo.com Tue Dec 5 10:14:00 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 5 10:16:15 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: References: <20061128130030.7721b544.hamish_nospam@yahoo.com> Message-ID: <20061205221400.50b281c2.hamish_nospam@yahoo.com> Michael Barton wrote: > I took out the scale panel. It had no functionality at all. It was > just a set of widgets that didn't do anything. In the docs it is > listed as not implemented. note: the nviz docs are notoriously out of date, don't take their word for it that something is or isn't implemented. I'm playing around with adapting the north arrow code, but I see in the code comments that there is a TODO for better scaling. I don't want to enable a scale which is known to be incorrect. (see attached patch [crude, using north arrow Tcl controls to draw it. "Nset_Narrow" C code will be the same, so reused it (need to migrate to wrapper fn)]) > I also took out the label sites panel. It has some related code, but > it is not functional. In the docs it is listed as not implemented. > Looking at the code, it seems to apply to the old sites format. I > don't know what it would take to make it work with current vector > formats. It would be nice to be able to label vector points, I suggest v.label as an easy method of doing this. > I kept all other panels, but split some up (e.g., separated labels and > legend into separate panels). I took out a very few non-functional > widgets: the clear screen checkbutton on the main panel, the lower > entry in the fringe panel, and I think one other (can't remember right > now). None of these had any functional commands attached. I kept in > the z-coord slider for the cutting planes. It doesn't seem to do > anything, but it has code attached. Maybe I should have cut it out > too. > > Having an interface with a bunch of controls that do nothing is really > frustrating. So I tried to avoid this. NVIZ does a lot anyway. Taking > out the non-functional parts helps people make better use of the parts > that do work. ok. > I also got the auto draw toggle checkbox to actually work in most > panels. where's that? ah I see, top right pulldown menu from the main controls some comments/suggestions: * "Visualize->Volumes" is confusing as vector volumes can exist too (watertower, dinosaur) * make the green text of "DRAW", DRAW CURRENT darker. It's hard to read against the grey window background. the NSEW placement arrow isn't as bad, but I'd still make it and the blue text a bit less bright. * In Vis->Vect points get rid of the empty space when no map is loaded. when a map is loaded, have the thematic controls toggle down instead of always there. aka hide the advanced options so not to overwhelm the user with a 747 cockpit of controls. * Rast/Vol panels: don't bother with drop down menus for lists of 2 or 3 items (Drawmode, Style, Shading ; Vis type, Shading) You can have all opts on the main panel + a column title without losing much real estate. There's plenty of vertical space in those two panels to play with. * If you go Vis->Vector pts then Vis->Scaled diff, the points panel doesn't close automatically. Same with a number of other combinations of panels. * fringe: fix the positioning of the fringe corners. Setting the Raster fine resolution to "1" helps a bit. the error depends on that setting. * default Label text size is very small. Suggest default font size of 17? (16 doesn't exist for me "Cannot Load Font\nTrying default Font") thanks for the updats, NVIZ has long lingered in a semi-finished state, especially the various decorations. Hamish -------------- next part -------------- ? lib/ogsf/OBJ.i686-pc-linux-gnu ? include/config.h ? include/version.h ? include/winname.h ? include/Make/Grass.make ? include/Make/Platform.make ? visualization/nviz/src/OBJ.i686-pc-linux-gnu ? visualization/nviz/src/map_obj.c.WORKING Index: visualization/nviz/scripts/panel_arrow.tcl =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/scripts/panel_arrow.tcl,v retrieving revision 1.3 diff -u -r1.3 panel_arrow.tcl --- visualization/nviz/scripts/panel_arrow.tcl 28 Nov 2006 18:01:56 -0000 1.3 +++ visualization/nviz/scripts/panel_arrow.tcl 5 Dec 2006 09:03:31 -0000 @@ -43,9 +43,9 @@ set n_arrow_size 100 - set panel [St_create {window name size priority} $BASE "North arrow" 2 5] + set panel [St_create {window name size priority} $BASE "North arrow and Scalebar" 2 5] frame $BASE -relief flat -borderwidth 0 - Nv_mkPanelname $BASE "North Arrow Panel" + Nv_mkPanelname $BASE "North Arrow and Scalebar Panel" # This section contains widgets for placing the north arrow set rbase1 [frame $BASE.arrow] @@ -70,7 +70,8 @@ proc bind_mouse { W } { bind $W <1> { - place_narrow %W %x %y +# place_narrow %W %x %y + place_scalebar %W %x %y if {$Nauto_draw == 1} { #Nset_cancel 0 Ndraw_all @@ -102,13 +103,33 @@ #remove canvas binding bind $W <1> {} - } +########################### +proc place_scalebar {W x y} { +global Nv_ n_arrow n_arrow_size +global n_arrow_x n_arrow_y n_arrow_z +global Nauto_draw +set y [expr $Nv_(height) - $y] + +#Draw Scalebar at selected point + set curr [Nget_current surf] + if {$curr} { + set location [Nset_Narrow $x $y $curr $n_arrow_size] + set n_arrow_x [lindex $location 0] + set n_arrow_y [lindex $location 1] + set n_arrow_z [lindex $location 2] + Ndraw_ScaleBar $n_arrow_x $n_arrow_y $n_arrow_z $n_arrow_size + #set chuckbutton +# set n_arrow 1 + } +#remove canvas binding + bind $W <1> {} +} Index: lib/ogsf/gsd_objs.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/ogsf/gsd_objs.c,v retrieving revision 2.7 diff -u -r2.7 gsd_objs.c --- lib/ogsf/gsd_objs.c 5 May 2006 23:28:59 -0000 2.7 +++ lib/ogsf/gsd_objs.c 5 Dec 2006 09:03:32 -0000 @@ -1002,6 +1002,67 @@ return; } + +/************************************************************** + * Function to draw Scalebar takes OpenGL coords and size + * adapted from gsd_north_arrow Hamish Bowman Dec 2006 + *************************************************************/ +int gsd_scalebar (float *pos2, float len, GLuint fontbase) +{ + char *txt; + float base[4][3]; + float Ntop[] = { 0.0, 0.0, 1.0 }; + + + base[0][Z] = base[1][Z] = base[2][Z] = base[3][Z] = pos2[Z]; + + base[0][X] = base[3][X] = pos2[X] - len / 16.; + base[1][X] = base[2][X] = pos2[X] + len / 16.; + + base[0][Y] = base[1][Y] = pos2[Y] - len / 2.; + base[2][Y] = base[3][Y] = pos2[Y] + len / 2.; + + + /* make sure we are drawing in front buffer */ + GS_set_draw(GSD_FRONT); + + gsd_pushmatrix(); + gsd_do_scale(1); + + glNormal3fv(Ntop); + gsd_color_func(0x000000); + + gsd_bgnpolygon(); + glVertex3fv(base[0]); + glVertex3fv(base[1]); + glVertex3fv(base[2]); + glVertex3fv(base[3]); + glVertex3fv(base[0]); + gsd_endpolygon(); + +/* draw units */ +/* Need to pick a nice generic font */ +/* TODO -- project text position off bar bottom along azimuth */ + + gsd_color_func(0x000000); + txt = "n map units"; /* %g? G_format_res()? , len) */ + /* adjust position of N text */ + base[0][X] -= gsd_get_txtwidth(txt, 18) - 20.; + base[0][Y] -= gsd_get_txtheight(18) - 20. ; + + glRasterPos3fv(base[0]); + glListBase(fontbase); + glCallLists(strlen(txt), GL_BYTE, (GLubyte *) txt); + GS_done_draw(); + + gsd_popmatrix(); + gsd_flush(); + + return (1); +} + + + /* primitives only called after transforms */ /* center is actually center at base of 8 sided cone */ void primitive_cone(unsigned long col) Index: include/ogsf_proto.h =================================================================== RCS file: /home/grass/grassrepository/grass6/include/ogsf_proto.h,v retrieving revision 1.5 diff -u -r1.5 ogsf_proto.h --- include/ogsf_proto.h 21 Nov 2006 00:13:30 -0000 1.5 +++ include/ogsf_proto.h 5 Dec 2006 09:03:32 -0000 @@ -495,6 +495,7 @@ int gsd_arrow(float *, unsigned long, float, float *, float, geosurf *); int gsd_arrow_onsurf(float *, float *, unsigned long, int, geosurf *); void gsd_3darrow(float *, unsigned long, float, float, float *, float); +int gsd_scalebar (float *, float, GLuint); void primitive_cone(unsigned long); void primitive_cylinder(unsigned long, int); Index: visualization/nviz/src/draw.c =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/src/draw.c,v retrieving revision 1.10 diff -u -r1.10 draw.c --- visualization/nviz/src/draw.c 20 Nov 2006 18:54:44 -0000 1.10 +++ visualization/nviz/src/draw.c 5 Dec 2006 09:03:33 -0000 @@ -274,6 +274,38 @@ return (TCL_OK); } + + + + +/***************************************************** + * Ndraw_ScaleBar + * Draws the Scalebar. Adaped from Ndraw_Narrow_cmd() + *****************************************************/ +int Ndraw_ScaleBar_cmd(Nv_data * data, Tcl_Interp * interp, /* Current interpreter. */ + int argc, /* Number of arguments. */ + char **argv /* Argument strings. */ + ) +{ + float coords[3]; + double len; + + if (argc != 5) + return (TCL_ERROR); + coords[0] = (int) atof(argv[1]); /* X */ + coords[1] = (int) atof(argv[2]); /* Y */ + coords[2] = (int) atof(argv[3]); /* Z */ + len = (atof(argv[4])); + + FontBase = load_font(TOGL_BITMAP_HELVETICA_18); + if (FontBase) + gsd_scalebar(coords, (float) len, FontBase); + else + fprintf(stderr, "Unable to load font\n"); + + return (TCL_OK); +} + int Ndraw_line_on_surf_cmd(Nv_data * data, Tcl_Interp * interp, /* Current interpreter. */ Index: visualization/nviz/src/init_commands.c =================================================================== RCS file: /home/grass/grassrepository/grass6/visualization/nviz/src/init_commands.c,v retrieving revision 1.8 diff -u -r1.8 init_commands.c --- visualization/nviz/src/init_commands.c 18 Jun 2006 22:05:12 -0000 1.8 +++ visualization/nviz/src/init_commands.c 5 Dec 2006 09:03:33 -0000 @@ -73,6 +73,7 @@ Ndraw_X_cmd(), Nset_Narrow_cmd(), Ndraw_Narrow_cmd(), +Ndraw_ScaleBar_cmd(), Ndraw_legend_cmd(), Ndraw_fringe_cmd(), Nset_viewport_cmd(), @@ -282,6 +283,7 @@ Tcl_CreateCommand(interp, "Ndraw_X", (Tcl_CmdProc *)Ndraw_X_cmd, data, NULL); Tcl_CreateCommand(interp, "Nset_Narrow", (Tcl_CmdProc *)Nset_Narrow_cmd, data, NULL); Tcl_CreateCommand(interp, "Ndraw_Narrow", (Tcl_CmdProc *)Ndraw_Narrow_cmd, data, NULL); + Tcl_CreateCommand(interp, "Ndraw_ScaleBar", (Tcl_CmdProc *)Ndraw_ScaleBar_cmd, data, NULL); Tcl_CreateCommand(interp, "Ndraw_legend", (Tcl_CmdProc *)Ndraw_legend_cmd, data, NULL); Tcl_CreateCommand(interp, "Ndraw_fringe", (Tcl_CmdProc *)Ndraw_fringe_cmd, data, NULL); Tcl_CreateCommand(interp, "Nset_viewport", (Tcl_CmdProc *)Nset_viewport_cmd, data, NULL); From paul-grass at stjohnspoint.co.uk Tue Dec 5 10:17:03 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 5 10:29:14 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: <17777.51396.332236.298841@cerise.gclements.plus.com> References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> Message-ID: Hello Benjamin and Glynn, On Sat, 2 Dec 2006, Glynn Clements wrote: > > Benjamin Ducke wrote: > >> Bad news: >> it seems impossible to cross-compile the current GRASS 6.3.cvs version. >> >> Bsically, every module I try to compile for Win32 on my Linux box fails >> with sth. like this: >> >> *** No rule to make target >> `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so', >> needed by >> `/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe >> >> Obviously, it should not be looking for libgrass_vect.so but for >> libgrass_vect.dll ! >> >> I am still able to compile the same modules, using the same tools, in a >> GRASS 6.1.CVS tree! >> >> Maybe some change to the configure script or one of the GRASS makefiles >> broke something? > > Odd. > > AFAICT, cross-compiling shared libraries should never have worked. Actually, I broke that recently. It did seem to support it in a kind of hacky way but the problem was it assumed if you were compiling for MINGW that you were cross-compiling, which broke native compiling on Windows in a few places. So I changed SC_CONFIG_CFLAGS to include a MINGW section and removed most of the MINGW conditional bits from configure.in. > SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns > the build platform, not the host platform. > > It should be using either $host or the components $host_cpu, > $host_vendor, and $host_os. Will investigate using $host_os if I get a chance. There should be some documentation on the internet I would hope? Quite a few people have contributed sets of compiler flags for their platform (and I've added a good few myself too) since we took that SC_CONFIG* stuff out of Tcl, and I wouldn't want to scrap all the useful information in there. Paul From hamish_nospam at yahoo.com Tue Dec 5 10:33:29 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 5 10:33:48 2006 Subject: [GRASS-dev] Re: v.in.gpsbabel bug? (with es file) In-Reply-To: <1165308335.5327.13.camel@davideDesktop> References: <200612041615.03970.lami@faunalia.it> <200612041626.35122.lami@faunalia.it> <1165308335.5327.13.camel@davideDesktop> Message-ID: <20061205223329.66c24bec.hamish_nospam@yahoo.com> > Leonardo: > > Hi all, > > I'm testing v.in.gpsbabel but I found a not corrspondence between > > tha datas associated to the point in gps and the datas associated > > to the new vector. > > > > If I use a gps Garmin 12 (not Etrex) the label associated to the > > points (second column in the file > > gps.csv, download by gpstrans) is not present in the table > > associated to the vector (gpsbabel.dbf). > > > > If I use gps Garmin 12 Etrex it works well (gpsbabel_etrex.dbf). Davide: > I think that the field is not correctly recognized by gpsbabel, the > script make only textual manipulation on his output... > It can be that gpsbabel download the column with a different tag from > the other garmin gps, and this tag is not included in csv > stylesheet... If the problem is only on one gps receiver model, I > think it his hard to fix (we had to download a meaningless column for > all others gps receivers), but if it is common problem, we had to fix > it. > > Leonardo, please try watching on temporary files to see if I'm right. > > PS Please report if it happens on other receivers... All our Garmins are currently out in the field. I can help test whenever they get back. Note that "date" column is really just the comments field. It so happens that the default comment when you make a new waypoint is the current time and date. As the user can change it to anything, v.in.gpsbabel should not treat that field as a timestamp, just as a string comment. regards, Hamish From paul-grass at stjohnspoint.co.uk Tue Dec 5 11:32:40 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 5 11:32:45 2006 Subject: [GRASS-dev] creating new location in krovak projection In-Reply-To: <20061201090545.GC7696@localdomain> References: <20061128194254.GA9662@localdomain> <20061128195227.GA10864@bartok.itc.it> <20061201090545.GC7696@localdomain> Message-ID: Hello Jachym Those datum paramters are already in GRASS (and have been for several years). The datum short name is hermannskogel, not that obvious and a bit long, and not my choice but we can't change it now. Interestingly the Slovak parameters are (very slightly) different from my source - they must cover a slightly different part of the country or have a different accuracy or something. This would need to be confirmed and documented before adding them to the file. Hopefully the site you got them from has some information? Paul On Fri, 1 Dec 2006, Jachym Cepicky wrote: > hi, > together with Martin, we prepared this patch for 6.3. It itroduces new > geodetic datums for both - Czech and Slovak republic (previously, we had > to edit PROJ_INFO by hand and add "towgs84" parameter there). > > not sure, if this belongs to 6.2 too, but it would be nice to have it > there. > > Thanks > > Jachym > > On Tue, Nov 28, 2006 at 08:52:27PM +0100, Markus Neteler wrote: >> On Tue, Nov 28, 2006 at 08:42:54PM +0100, Jachym Cepicky wrote: >>> Hi, >>> I would like to define new Location using >>> >>> projection krovak >>> ellipsoid bessel >>> >>> when I come to question about projection, I specify "krovak" and hit >>> Return, GRASS jumps imidietly to DEFNE THE DEFAULT REGION form (for >>> defining boundary coordinates and resolution). >>> >>> When I try do specify new projection with g.setproj, it ends like this: >>> >>> GRASS 6.3.cvs (jtsk2):~ > g.setproj >>> >>> >>> Please specify projection name >>> Enter 'list' for the list of available projections >>> Hit RETURN to cancel request >>>> krovak >>> ERROR: Projection krovak is not specified in the table >>> GRASS 6.3.cvs (jtsk2):~ > >>> >>> >>> Howto define location using krovak projection? >> >> Hi Jachym: >> >> the Krovak projection is missing from: >> general/g.setproj/proj-parms.table >> >> I don't know how to add it there. It would be good to get >> general/g.setproj/README >> updated on how to add more projections. >> >> Markus >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > ----------------------------------------- > OFFICE: > Department of Geoinformation Technologies > Zemedelska 3 > 613 00, Brno > Czech Republick > e-mail: xcepicky@node.mendelu.cz > URL: http://mapserver.mendelu.cz > Tel.: +420 545 134 514 > From roberto at geomatica.como.polimi.it Tue Dec 5 11:47:44 2006 From: roberto at geomatica.como.polimi.it (Roberto Antolin) Date: Tue Dec 5 11:49:16 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.surf.rst limitations? In-Reply-To: <20061205142039.18b7b40b.hamish_nospam@yahoo.com> References: <20061204181537.18496.qmail@web36501.mail.mud.yahoo.com> <20061204211107.ir0iigv34koowskk@webmail.polimi.it> <20061205142039.18b7b40b.hamish_nospam@yahoo.com> Message-ID: <45754E50.7040600@geomatica.como.polimi.it> Hi all, you didn't update the CVS, did you? Don't do it. I uploaded it on my version and I'll send altogether today :) Hamish ha scritto: >Hi Roberto, > >here are some updates for v.surf.bspline vs. today's CVS. > >Hamish > Now one question. Due to allocation memory problems with raster on my pc some weeks ago, I introduced a limitation on the raster dimensions only in my v.surf.bspline version. So, the CVS wasn't updated. But yesterday, a user told me that he didn't have any problem at all using the no "limited" version on CVS. So, I decide to set a limitation in the number of raster cells: about 30mill. I think it is high enough. But, which is the best way to controll these kinds of things? Should I set a limitation in the number of cells? If afirmative, which one? Maybe, considering float cells instead double? As a possible thing I would like to allocate the whole raster (as It works now) instead of considering smaller rasters and merge them at the end. Cheers, Roberto. -- Roberto Antol?n S?nchez Politecnico di Milano ? Polo Regionale di Como (Laboratorio di Geomatica V2.8) Via Valleggio, 11 ? 22100 Como, Italy tel: +39 031 332 7533 || fax: +39 031 332 7519 email: roberto.antolin@polimi.it From paul-grass at stjohnspoint.co.uk Tue Dec 5 13:34:35 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 5 13:34:36 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl Message-ID: gis_set.tcl (the location and mapset browser that appears when GRASS is started in GUI mode) contains "exec ls" in a few places that stops it from working on native Windows without Msys. Has anybody done any work on it and would know how to fix those? I'm sure there must be a Tcl command to list a directory but I can't find it by searching on Google. Also gis_set.tcl seems to return the same exit status if either Enter GRASS or Exit is clicked - is this true? I was trying to check the %errorlevel% variable in a Windows batch script to avoid starting gis.m if enter was clicked, but it always seems to be 0. Paul From spano at cli.di.unipi.it Tue Dec 5 16:48:08 2006 From: spano at cli.di.unipi.it (Davide Spano) Date: Tue Dec 5 16:48:32 2006 Subject: [GRASS-dev] Re: v.in.gpsbabel bug? (with es file) In-Reply-To: <200612051453.58411.lami@faunalia.it> References: <200612041615.03970.lami@faunalia.it> <1165308335.5327.13.camel@davideDesktop> <20061205223329.66c24bec.hamish_nospam@yahoo.com> <200612051453.58411.lami@faunalia.it> Message-ID: <1165333688.5327.31.camel@davideDesktop> Il giorno mar, 05/12/2006 alle 14.53 +0100, Leonardo Lami ha scritto: > Hi > I make some tests and I send you the gpsbabel output files. > For every type of gps (garmin 12, garmin 12xl and garmin 12 etrex) I make two > file: > a gpx file create from gpsbabel by "gpsbabel -w -i garmin -f /dev/ttyUSB0 -o > gpx -F *.gpx" > a csv file create from v.in.gpsbabel using grass_write_ascii.style like in the > script > > You can see that for "garmin 12" and "garmin 12xl" v.in.gpsbabel does not > transfer the field "name" (present in the gpx files) in the csv files. > > Regards > Leonardo Hi all, the data is not downloaded because in the grass_write_ascii.style I did not put a field for that data (I believed that was only a progressive ID for the waypoint...) I propose to take a look at this page http://www.gpsbabel.org/htmldoc-1.3.2/style_define.html and tell me what fields are important to download, when we agree to the list, I'll fix the problem in the script. Davide From mlennert at club.worldonline.be Tue Dec 5 16:53:02 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Dec 5 16:51:52 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: References: Message-ID: <457595DE.7060508@club.worldonline.be> On 05/12/06 13:34, Paul Kelly wrote: > gis_set.tcl (the location and mapset browser that appears when GRASS is > started in GUI mode) contains "exec ls" in a few places that stops it > from working on native Windows without Msys. Has anybody done any work > on it and would know how to fix those? I'm sure there must be a Tcl > command to list a directory but I can't find it by searching on Google. How about 'glob' ? (http://www.tcl.tk/man/tcl8.4/TclCmd/glob.htm) Moritz From spano at cli.di.unipi.it Tue Dec 5 19:20:06 2006 From: spano at cli.di.unipi.it (Davide Spano) Date: Tue Dec 5 19:20:21 2006 Subject: [GRASS-dev] Re: v.in.gpsbabel bug? (with es file) In-Reply-To: <200612051753.04540.lami@faunalia.it> References: <200612041615.03970.lami@faunalia.it> <200612051453.58411.lami@faunalia.it> <1165333688.5327.31.camel@davideDesktop> <200612051753.04540.lami@faunalia.it> Message-ID: <1165342806.5327.35.camel@davideDesktop> Il giorno mar, 05/12/2006 alle 17.53 +0100, Leonardo Lami ha scritto: > But way the field is present in the case of garmin etrex also in the > grass_write_ascii.style? > Because for garmin etrex the NAME field was equal to COMMENT field (which is included in grass_write_ascii.style). I'll add the field as soon as I can Davide From michael.barton at asu.edu Tue Dec 5 22:15:23 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 5 22:15:31 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities In-Reply-To: <20061205213513.47288f1c.hamish_nospam@yahoo.com> Message-ID: On 12/5/06 1:35 AM, "Hamish" wrote: >> this bug's URL: http://intevation.de/rt/webrt?serial_num=5367 >> --------------------------------------------------------------------- >> >> Subject: 6.3 NVIZ: tcltk 8.3 incompatibilities >> >> Hi, >> >> in 6.3-cvs NVIZ, panel_rast.tcl and panel_main.tcl use "frame padx >> pady" in a few places. This is incompatible with Tcl/Tk 8.3 and causes >> a lock-up during the menu building. >> >> compare: >> http://www.tcl.tk/man/tcl8.3/TkCmd/frame.htm >> http://www.tcl.tk/man/tcl8.4/TkCmd/frame.htm > > > can the padx,y be moved to the "pack" step? > > I hope so. I'll check. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Tue Dec 5 22:25:46 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Dec 5 22:25:49 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: <20061205221400.50b281c2.hamish_nospam@yahoo.com> References: <20061128130030.7721b544.hamish_nospam@yahoo.com> <20061205221400.50b281c2.hamish_nospam@yahoo.com> Message-ID: <4575E3DA.2010706@o2.pl> Hamish wrote: > some comments/suggestions: > > * "Visualize->Volumes" is confusing as vector volumes can exist too > (watertower, dinosaur) Hmm, a possible source of confussion. Could these 2 things use different names? Eg. use '3D raster' consequently for raster volumes everywhere in GRASS, and keep 'volume' for vector volumes only? One note more: In past it was possible to change the value for any slider by entering the number and pressing Enter. Now it doesn't work. Try with eg. exag. > thanks for the updats, NVIZ has long lingered in a semi-finished state, > especially the various decorations. Yes it looks a way cleaner now. Cool. Maciek From paul-grass at stjohnspoint.co.uk Tue Dec 5 22:40:45 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 5 22:40:48 2006 Subject: [GRASS-dev] g.mapsets use of sleep() Message-ID: Since $(VASKLIB) was removed from the g.mapsets Makefile I get the following error on Windows: gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-run time-pseudo-reloc -L/c/grass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/ grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe OBJ.i686-pc-mingw32/main_cmd.o OBJ .i686-pc-mingw32/dsply_path.o OBJ.i686-pc-mingw32/dsply_maps.o OBJ.i686-pc-mingw 32/get_maps.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -l grass_datetime -lxdr -liberty -lws2_32 -lz -lxdr -liberty -lws2_32 -l z OBJ.i686-pc-mingw32/main_cmd.o(.text+0x427): In function `main': c:/grass/grass6/general/g.mapsets/main_cmd.c:128: undefined reference to `sleep' collect2: ld returned 1 exit status make: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe] Error 1 Not at all sure what's the most elegant way of fixing it??? Paul From paul-grass at stjohnspoint.co.uk Tue Dec 5 22:47:04 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 5 22:47:09 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: <4575E728.6020402@o2.pl> References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> <4503F1C0.2000605@o2.pl> <4575E170.70609@o2.pl> <4575E728.6020402@o2.pl> Message-ID: On Tue, 5 Dec 2006, Maciej Sieczka wrote: > Paul Kelly wrote: >> Hello Maciek >> We're talking about your example at >> http://grass.itc.it/pipermail/grass5/2006-September/025668.html, right? > > Right. > >> In that case both your co-ordinate systems are based on the same >> ellipsoid (WGS84) so it is normal and expected for the ellipsoidal >> height to stay the same. > > Sorry, but I'm quite a dummy as to ellipsoids vs height. So I should > expect a difference whether using the '-z' switch only when > reprojecting between 2 different ellipsoids, correct? Yes. It is really not a very useful feature at all, quite confusing actually, and that's why I thought it was important to make it optional. Ellipsoidal height is not very useful because you can't use it to work out e.g. if a ball is going to roll down a hill. In theory the ellipsoidal height of the bottom of a hill could be higher than the top of the hill - what is more important in a practical situation is the height above the geoid, which is what most vertical datums use. And that is totally separate from the 2-D re-projection that the [rv].proj modules do. We've talked about better vertical datum support in GRASS but it is so complicated and would just open up a whole can of worms that I don't want to get into right now... >> I'm not clear on what output you were expecting? > > Well, you wrote yourself "That is very strange. Can you post the output > from v.proj please to see if there are any clues?". So I did, and > waited for your response. Yes well I didn't quite pick up on that then either (the ellipsoids being the same). It is quite hard to get your head around it and understand it and I only saw that was the problem when looking at it afresh! Paul From maris.gis at gmail.com Tue Dec 5 23:01:11 2006 From: maris.gis at gmail.com (Maris Nartiss) Date: Tue Dec 5 23:01:15 2006 Subject: [GRASS-dev] Re: autoconf, LOC_CHECK_VERSION_INT In-Reply-To: <340505ef0609220442r54b7df33p49f67b1e1f2a1327@mail.gmail.com> References: <340505ef0609201003v2508cfa4ia3c9c610b7b26eb7@mail.gmail.com> <20060920194833.GB1806@bartok.itc.it> <340505ef0609220442r54b7df33p49f67b1e1f2a1327@mail.gmail.com> Message-ID: <2b3d8c1c0612051401y5e4e86adv3f175d9209269db3@mail.gmail.com> Hi, I was trying to emerge GRASS 6.1.0 and 6.2.0 on my freshly installed Gentoo ~x86 box, but it stopped on following error: ***** autoconf ***** configure.in:44: error: possibly undefined macro: AC_MSG_ERROR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. As Radim also had following problem, I wan to ask: 1) is autoconf-2.1x required to compile GRASS and autoconf-2.61 currently banned? 2) if it is fixed in 6.3, is possible to backport this fix before 6.2.1 release? 3) is easy to fix this autoconf problem? I mean like changing one line in configure from ebuild, if it is not fixed before 6.2.1 release. You may ask - why I use autoconf-2.61? My answer - it's just default on my Gentoo system :) WBR, Maris. 2006/9/22, Radim Blazek : > On 9/20/06, Markus Neteler wrote: > > On Wed, Sep 20, 2006 at 07:03:44PM +0200, Radim Blazek wrote: > > > Hi. > > > I cannot create configure with autoconf 2.59, error: > > > > > > configure.in:362: warning: AC_CANONICAL_HOST invoked multiple times > > > autoconf/specific.m4:363: AC_CYGWIN is expanded from... > > > configure.in:362: the top level > > > configure.in:44: error: possibly undefined macro: AC_MSG_ERROR > > > If this token and others are legitimate, please use > m4_pattern_allow. > > > See the Autoconf documentation. > > > > hi Radim, > > > > so far I always used autoconf-2.13 (which still works). > > Could you try that version as well? Or do you eed to > > use 2.59? > > Yes, I forgot that it must be 2.13. > > Radim > > > > > Markus > > > > > The reason I need to create configure is that macro > > > LOC_CHECK_VERSION_INT fails on crosscompiler, > > > patch is attached. > > > > > > Radim > > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > > Markus Neteler http://mpa.itc.it/markus/ > > ITC-irst - Centro per la Ricerca Scientifica e Tecnologica > > MPBA - Predictive Models for Biol. & Environ. Data Analysis > > Via Sommarive, 18 - 38050 Povo (Trento), Italy > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From tutey at o2.pl Tue Dec 5 23:15:09 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Dec 5 23:15:13 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> <4503F1C0.2000605@o2.pl> <4575E170.70609@o2.pl> <4575E728.6020402@o2.pl> Message-ID: <4575EF6D.7020603@o2.pl> Paul, Summarising: Could you please confirm/deny the 2 statemements below - so that I'm sure I'm not screwing/missunderstanding something: 1. The -z switch is not the default; but it *was* - before you made it and option few months ago. 2. One should use it only when his data is 3D, he is sure the Z coord is an an ellipsoidal height, and he is transforming between 2 different ellipsoids. 3. Even if the Z coord of my vector is an ellipsoidal height, using -z is not supposed to make any change when transformimg between eg. UTM/WGS84 and ll/WGS84; *it doesn't do any harm though*. I know I'm slow on this, but please bear with me :). I don't want to mess something up in future with my data or advise something stupid to others. Cheers, Maciek From michael.barton at asu.edu Tue Dec 5 23:16:57 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 5 23:17:03 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: <20061205221400.50b281c2.hamish_nospam@yahoo.com> Message-ID: On 12/5/06 2:14 AM, "Hamish" wrote: > Michael Barton wrote: >> I took out the scale panel. It had no functionality at all. It was >> just a set of widgets that didn't do anything. In the docs it is >> listed as not implemented. > > note: the nviz docs are notoriously out of date, don't take their word > for it that something is or isn't implemented. > > I'm playing around with adapting the north arrow code, but I see in the > code comments that there is a TODO for better scaling. I don't want to > enable a scale which is known to be incorrect. (see attached patch > [crude, using north arrow Tcl controls to draw it. "Nset_Narrow" C code > will be the same, so reused it (need to migrate to wrapper fn)]) > >> I also took out the label sites panel. It has some related code, but >> it is not functional. In the docs it is listed as not implemented. >> Looking at the code, it seems to apply to the old sites format. I >> don't know what it would take to make it work with current vector >> formats. > > It would be nice to be able to label vector points, I suggest v.label as > an easy method of doing this. > >> I kept all other panels, but split some up (e.g., separated labels and >> legend into separate panels). I took out a very few non-functional >> widgets: the clear screen checkbutton on the main panel, the lower >> entry in the fringe panel, and I think one other (can't remember right >> now). None of these had any functional commands attached. I kept in >> the z-coord slider for the cutting planes. It doesn't seem to do >> anything, but it has code attached. Maybe I should have cut it out >> too. >> >> Having an interface with a bunch of controls that do nothing is really >> frustrating. So I tried to avoid this. NVIZ does a lot anyway. Taking >> out the non-functional parts helps people make better use of the parts >> that do work. > > ok. > >> I also got the auto draw toggle checkbox to actually work in most >> panels. > > where's that? ah I see, top right pulldown menu from the main controls > > > > > some comments/suggestions: > > * "Visualize->Volumes" is confusing as vector volumes can exist too > (watertower, dinosaur) > > * make the green text of "DRAW", DRAW CURRENT darker. It's hard to read > against the grey window background. the NSEW placement arrow isn't as > bad, but I'd still make it and the blue text a bit less bright. > > * In Vis->Vect points get rid of the empty space when no map is loaded. > when a map is loaded, have the thematic controls toggle down instead of > always there. aka hide the advanced options so not to overwhelm the > user with a 747 cockpit of controls. > > * Rast/Vol panels: don't bother with drop down menus for lists of 2 or 3 > items (Drawmode, Style, Shading ; Vis type, Shading) You can have all > opts on the main panel + a column title without losing much real estate. > There's plenty of vertical space in those two panels to play with. > > * If you go Vis->Vector pts then Vis->Scaled diff, the points panel > doesn't close automatically. Same with a number of other combinations of > panels. > > * fringe: fix the positioning of the fringe corners. Setting the Raster > fine resolution to "1" helps a bit. the error depends on that setting. > > * default Label text size is very small. Suggest default font size of > 17? (16 doesn't exist for me "Cannot Load Font\nTrying default Font") > > > > thanks for the updats, NVIZ has long lingered in a semi-finished state, > especially the various decorations. > > Thanks for the suggestions. I'll look into these. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Dec 5 23:25:45 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 5 23:25:49 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities In-Reply-To: <20061205213513.47288f1c.hamish_nospam@yahoo.com> Message-ID: On 12/5/06 1:35 AM, "Hamish" wrote: >> this bug's URL: http://intevation.de/rt/webrt?serial_num=5367 >> --------------------------------------------------------------------- >> >> Subject: 6.3 NVIZ: tcltk 8.3 incompatibilities >> >> Hi, >> >> in 6.3-cvs NVIZ, panel_rast.tcl and panel_main.tcl use "frame padx >> pady" in a few places. This is incompatible with Tcl/Tk 8.3 and causes >> a lock-up during the menu building. >> >> compare: >> http://www.tcl.tk/man/tcl8.3/TkCmd/frame.htm >> http://www.tcl.tk/man/tcl8.4/TkCmd/frame.htm > > > can the padx,y be moved to the "pack" step? > This is fixed in the cvs now. Please test and let me know. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Wed Dec 6 00:49:07 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 00:49:56 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities In-Reply-To: References: <20061205213513.47288f1c.hamish_nospam@yahoo.com> Message-ID: <20061206124907.1838cc78.hamish_nospam@yahoo.com> > >> this bug's URL: http://intevation.de/rt/webrt?serial_num=5367 > >> --------------------------------------------------------------------- > >> > >> Subject: 6.3 NVIZ: tcltk 8.3 incompatibilities .. > >> in 6.3-cvs NVIZ, panel_rast.tcl and panel_main.tcl use "frame padx > >> pady" in a few places. This is incompatible with Tcl/Tk 8.3 and causes > >> a lock-up during the menu building. .. > > can the padx,y be moved to the "pack" step? > > This is fixed in the cvs now. Please test and let me know. there is still one in panel_main.tcl, line 222: nviz/scripts$ grep -n frame panel_main.tcl | grep pad 58: pack [frame $BASE.redrawf -bd 1 -relief flat ] -padx 3 -pady 5 -side top -fill x -expand 1 149: pack [frame $BASE.midt -relief flat -bd 0] -side top -expand 1 -fill x -padx 5 -pady 5 150: pack [frame $BASE.midf -relief flat -bd 0] -side left -expand 1 -padx 5 222: frame $BASE.bframe.cframe -relief flat -borderwidth 0 -pady 5 243: pack $BASE.bframe.cframe.pers $BASE.bframe.cframe.tw -side left -fill x -expand 1 -padx 3 244: pack $BASE.bframe -side top -fill x -expand 1 -padx 3 panel_surf.tcl is now ok. thanks, Hamish From glynn at gclements.plus.com Wed Dec 6 00:53:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Dec 6 00:53:28 2006 Subject: [GRASS-dev] current grass 6.3.cvs cross compilation In-Reply-To: References: <4571A92F.2000306@ufg.uni-kiel.de> <17777.51396.332236.298841@cerise.gclements.plus.com> Message-ID: <17782.1650.606915.604131@cerise.gclements.plus.com> Paul Kelly wrote: > > SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns > > the build platform, not the host platform. > > > > It should be using either $host or the components $host_cpu, > > $host_vendor, and $host_os. > > Will investigate using $host_os if I get a chance. There should be some > documentation on the internet I would hope? Quite a few people have > contributed sets of compiler flags for their platform (and I've added a > good few myself too) since we took that SC_CONFIG* stuff out of Tcl, and I > wouldn't want to scrap all the useful information in there. We can keep the variable settings, if we can match up the platform names between autoconf and uname. You can get some information by analysing config.guess, but I doubt that there will be a 1:1 correspondence. -- Glynn Clements From michael.barton at asu.edu Wed Dec 6 01:03:35 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 01:05:22 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: <457595DE.7060508@club.worldonline.be> Message-ID: On 12/5/06 8:53 AM, "Moritz Lennert" wrote: > On 05/12/06 13:34, Paul Kelly wrote: >> gis_set.tcl (the location and mapset browser that appears when GRASS is >> started in GUI mode) contains "exec ls" in a few places that stops it >> from working on native Windows without Msys. Has anybody done any work >> on it and would know how to fix those? I'm sure there must be a Tcl >> command to list a directory but I can't find it by searching on Google. > > How about 'glob' ? > (http://www.tcl.tk/man/tcl8.4/TclCmd/glob.htm) > This seems to work. I've replaced all exec ls with glob and some other tcltk syntax. It works OK on my Mac/x11 system. I just put it into the CVS. Please try on other systems and on Windows. This doesn't seem to break anything. Keep you fingers crossed. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Dec 6 01:14:27 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 01:15:17 2006 Subject: [GRASS-dev] [bug #5367] (grass) 6.3 NVIZ: tcltk 8.3 incompatibilities In-Reply-To: <20061206124907.1838cc78.hamish_nospam@yahoo.com> Message-ID: On 12/5/06 4:49 PM, "Hamish" wrote: > > there is still one in panel_main.tcl, line 222: > > nviz/scripts$ grep -n frame panel_main.tcl | grep pad > 58: pack [frame $BASE.redrawf -bd 1 -relief flat ] -padx 3 -pady 5 -side > top -fill x -expand 1 > 149: pack [frame $BASE.midt -relief flat -bd 0] -side top -expand 1 -fill x > -padx 5 -pady 5 > 150: pack [frame $BASE.midf -relief flat -bd 0] -side left -expand 1 -padx > 5 > 222: frame $BASE.bframe.cframe -relief flat -borderwidth 0 -pady 5 > 243: pack $BASE.bframe.cframe.pers $BASE.bframe.cframe.tw -side left -fill > x -expand 1 -padx 3 > 244: pack $BASE.bframe -side top -fill x -expand 1 -padx 3 > > > panel_surf.tcl is now ok. > > I fixed and committed it. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Wed Dec 6 01:16:47 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Dec 6 01:16:49 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: References: Message-ID: <17782.3055.550218.547043@cerise.gclements.plus.com> Paul Kelly wrote: > Since $(VASKLIB) was removed from the g.mapsets Makefile I get the > following error on Windows: > gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-run > time-pseudo-reloc -L/c/grass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/ > grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe OBJ.i686-pc-mingw32/main_cmd.o OBJ > .i686-pc-mingw32/dsply_path.o OBJ.i686-pc-mingw32/dsply_maps.o OBJ.i686-pc-mingw > 32/get_maps.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -l > grass_datetime -lxdr -liberty -lws2_32 -lz -lxdr -liberty -lws2_32 -l > z > OBJ.i686-pc-mingw32/main_cmd.o(.text+0x427): In function `main': > c:/grass/grass6/general/g.mapsets/main_cmd.c:128: undefined reference to `sleep' > > collect2: ld returned 1 exit status > make: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe] Error 1 > > Not at all sure what's the most elegant way of fixing it??? - sprintf (command, "ls -C %s/%s 1>&2", G_gisdbase(), G_location()); + sprintf (command, "ls -C %s/%s 1>&2 ; sleep 3", G_gisdbase(), G_location()); system (command); - sleep (3); ? OK, so it's not exactly "elegant", but assuming the existence of a "sleep" command doesn't seem to be any more of a Unix-ism than assuming the existence of an "ls" command. Alternatively, use G_sleep() instead: >From lib/gis/sleep.c: unsigned int G_sleep (unsigned int seconds) { #ifdef __MINGW32__ /* TODO: no sleep for now */ return 0; #else /* __MINGW32__ */ return sleep(seconds); #endif /* __MINGW32__ */ } On MinGW, it doesn't actually sleep, but at least you don't get a link error. -- Glynn Clements From glynn at gclements.plus.com Wed Dec 6 01:25:50 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Dec 6 01:25:54 2006 Subject: [GRASS-dev] Re: autoconf, LOC_CHECK_VERSION_INT In-Reply-To: <2b3d8c1c0612051401y5e4e86adv3f175d9209269db3@mail.gmail.com> References: <340505ef0609201003v2508cfa4ia3c9c610b7b26eb7@mail.gmail.com> <20060920194833.GB1806@bartok.itc.it> <340505ef0609220442r54b7df33p49f67b1e1f2a1327@mail.gmail.com> <2b3d8c1c0612051401y5e4e86adv3f175d9209269db3@mail.gmail.com> Message-ID: <17782.3598.965865.978492@cerise.gclements.plus.com> Maris Nartiss wrote: > I was trying to emerge GRASS 6.1.0 and 6.2.0 on my freshly installed > Gentoo ~x86 box, but it stopped on following error: > ***** autoconf ***** > > configure.in:44: error: possibly undefined macro: AC_MSG_ERROR > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > > As Radim also had following problem, I wan to ask: > 1) is autoconf-2.1x required to compile GRASS and autoconf-2.61 > currently banned? GRASS' configure.in script assumes 2.13. However, we keep the generated configure script in CVS, so you don't need to run autoconf as part of the build process. You only need to run autoconf if you modify the configure.in script, in which case you need to use 2.13. > 2) if it is fixed in 6.3, is possible to backport this fix before 6.2.1 release? > 3) is easy to fix this autoconf problem? I mean like changing one line > in configure from ebuild, if it is not fixed before 6.2.1 release. > > You may ask - why I use autoconf-2.61? My answer - it's just default > on my Gentoo system :) On Gentoo, the auto* commands are symlinks to ac-wrapper.sh. This uses $WANT_AUTOCONF to determine which version to use. If it's unset, if configure already exists and was built with 2.13 then it uses 2.13, otherwise it defaults to a newer version. -- Glynn Clements From michael.barton at asu.edu Wed Dec 6 02:01:52 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 02:01:58 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: <20061205221400.50b281c2.hamish_nospam@yahoo.com> Message-ID: On 12/5/06 2:14 AM, "Hamish" wrote: Here are some initial comments and questions before I start working on these... > > some comments/suggestions: > > * "Visualize->Volumes" is confusing as vector volumes can exist too > (watertower, dinosaur) I thought about this too. There is no separate vector volumes panel (it might be nice though), which is why I went with the simpler 'Volumes'. Maybe call this one... Raster volumes Voxels Grid 3D volumes other? > > * make the green text of "DRAW", DRAW CURRENT darker. It's hard to read > against the grey window background. the NSEW placement arrow isn't as > bad, but I'd still make it and the blue text a bit less bright. I'll see if I can find a darker color that still looks sort of green. The idea is to make the "draw" button stand out. > > * In Vis->Vect points get rid of the empty space when no map is loaded. > when a map is loaded, have the thematic controls toggle down instead of > always there. aka hide the advanced options so not to overwhelm the > user with a 747 cockpit of controls. I'd like to have this one close too. I might have figured out how to do it in the volume control panel, but I'm not sure. I'll see. Same with the controls. This is doable but complicated. What makes it worse is that the code is so old and convoluted. > > * Rast/Vol panels: don't bother with drop down menus for lists of 2 or 3 > items (Drawmode, Style, Shading ; Vis type, Shading) You can have all > opts on the main panel + a column title without losing much real estate. > There's plenty of vertical space in those two panels to play with. I agree. I want to keep some consistency among panels, but it is good to save space--especially with the very large volume panel. I want to do some other things to tighten this on up if I can. > > * If you go Vis->Vector pts then Vis->Scaled diff, the points panel > doesn't close automatically. Same with a number of other combinations of > panels. To be frank, I don't know what makes some panels close and others stay open. The best would be for panels to stay open until a certain cumulative vertical size is reached and then close. > > * fringe: fix the positioning of the fringe corners. Setting the Raster > fine resolution to "1" helps a bit. the error depends on that setting. This is a togl issue that Bob is working on. Might not be fixable. > > * default Label text size is very small. Suggest default font size of > 17? (16 doesn't exist for me "Cannot Load Font\nTrying default Font") > Is the same on all systems? I didn't change the defaults because of this very problem you mention. Any way to find out which sizes might be standard on most systems? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Wed Dec 6 02:43:44 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 02:44:00 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <17782.3055.550218.547043@cerise.gclements.plus.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> Message-ID: <20061206144344.4250858b.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Paul Kelly wrote: > > > Since $(VASKLIB) was removed from the g.mapsets Makefile I get the > > following error on Windows: > > gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-run > > time-pseudo-reloc -L/c/grass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/ > > grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe OBJ.i686-pc-mingw32/main_cmd.o OBJ > > .i686-pc-mingw32/dsply_path.o OBJ.i686-pc-mingw32/dsply_maps.o OBJ.i686-pc-mingw > > 32/get_maps.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -l > > grass_datetime -lxdr -liberty -lws2_32 -lz -lxdr -liberty -lws2_32 -l > > z > > OBJ.i686-pc-mingw32/main_cmd.o(.text+0x427): In function `main': > > c:/grass/grass6/general/g.mapsets/main_cmd.c:128: undefined reference to `sleep' > > > > collect2: ld returned 1 exit status > > make: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe] Error 1 > > > > Not at all sure what's the most elegant way of fixing it??? > > - sprintf (command, "ls -C %s/%s 1>&2", G_gisdbase(), G_location()); > + sprintf (command, "ls -C %s/%s 1>&2 ; sleep 3", G_gisdbase(), G_location()); > system (command); > - sleep (3); > > ? > > OK, so it's not exactly "elegant", but assuming the existence of a > "sleep" command doesn't seem to be any more of a Unix-ism than > assuming the existence of an "ls" command. so #include is no good in windows? isn't the system("ls") going to be a problem as well? > Alternatively, use G_sleep() instead: > > >>From lib/gis/sleep.c: > > unsigned int G_sleep (unsigned int seconds) > { > #ifdef __MINGW32__ > /* TODO: no sleep for now */ > return 0; > #else /* __MINGW32__ */ > return sleep(seconds); > #endif /* __MINGW32__ */ > } > > On MinGW, it doesn't actually sleep, but at least you don't get a link > error. AFAIR, Paul's error is exactly why Radim added G_sleep(). and finally, WRT g.mapsets, sleep isn't really needed*, so why not: [*] not followed by a clear screen command. - sleep(3); - exit(1); + G_fatal_error(""); or + G_fatal_error("Available mapsets:\n%s", mapset_string); Hamish From hmitaso at unity.ncsu.edu Wed Dec 6 03:01:48 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Wed Dec 6 03:01:54 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: References: Message-ID: <6E522814-F918-40C6-B5B5-C5D704CF0FB0@unity.ncsu.edu> On Dec 5, 2006, at 8:01 PM, Michael Barton wrote: > On 12/5/06 2:14 AM, "Hamish" wrote: > > Here are some initial comments and questions before I start working on > these... > >> >> some comments/suggestions: >> >> * "Visualize->Volumes" is confusing as vector volumes can exist too >> (watertower, dinosaur) just a note - there is a difference - 3D rasters represent trivariate functions so at each point in 3D space you can have a different value - I think calling this a volume is quite intuitive watertower, dinosaur - 3D vector surfaces are quite different - if you try to represent it by a volume you would have it filled with just 1 and no-data. So I don't think that 3D surfaces or 3D vectors should be called volumes - you essentially have 3D points, lines and areas. Helena P.S. I am working on the GRASSbook 3rd edition and I have a list of terminology troubles that we have in the manual pages and other documentation. I will bring it up for discussion when I feel I have most of them to make the discussion most efficient and get the big picture too. > > I thought about this too. There is no separate vector volumes panel > (it > might be nice though), which is why I went with the simpler > 'Volumes'. Maybe > call this one... > > Raster volumes > Voxels > Grid 3D volumes > > other? > >> >> * make the green text of "DRAW", DRAW CURRENT darker. It's hard to >> read >> against the grey window background. the NSEW placement arrow isn't as >> bad, but I'd still make it and the blue text a bit less bright. > > I'll see if I can find a darker color that still looks sort of > green. The > idea is to make the "draw" button stand out. > >> >> * In Vis->Vect points get rid of the empty space when no map is >> loaded. >> when a map is loaded, have the thematic controls toggle down >> instead of >> always there. aka hide the advanced options so not to overwhelm the >> user with a 747 cockpit of controls. > > I'd like to have this one close too. I might have figured out how > to do it > in the volume control panel, but I'm not sure. I'll see. Same with the > controls. This is doable but complicated. What makes it worse is > that the > code is so old and convoluted. > >> >> * Rast/Vol panels: don't bother with drop down menus for lists of >> 2 or 3 >> items (Drawmode, Style, Shading ; Vis type, Shading) You can have all >> opts on the main panel + a column title without losing much real >> estate. >> There's plenty of vertical space in those two panels to play with. > > I agree. I want to keep some consistency among panels, but it is > good to > save space--especially with the very large volume panel. I want to > do some > other things to tighten this on up if I can. > >> >> * If you go Vis->Vector pts then Vis->Scaled diff, the points panel >> doesn't close automatically. Same with a number of other >> combinations of >> panels. > > To be frank, I don't know what makes some panels close and others > stay open. > The best would be for panels to stay open until a certain cumulative > vertical size is reached and then close. > >> >> * fringe: fix the positioning of the fringe corners. Setting the >> Raster >> fine resolution to "1" helps a bit. the error depends on that >> setting. > > This is a togl issue that Bob is working on. Might not be fixable. > >> >> * default Label text size is very small. Suggest default font size of >> 17? (16 doesn't exist for me "Cannot Load Font\nTrying default >> Font") >> > > Is the same on all systems? I didn't change the defaults because of > this > very problem you mention. Any way to find out which sizes might be > standard > on most systems? > > Michael > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Wed Dec 6 03:14:06 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 03:14:10 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <17782.3055.550218.547043@cerise.gclements.plus.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> Message-ID: <20061206151406.6aa1acf7.hamish_nospam@yahoo.com> Glynn Clements wrote: > > OBJ.i686-pc-mingw32/main_cmd.o(.text+0x427): In function `main': > > c:/grass/grass6/general/g.mapsets/main_cmd.c:128: undefined reference to `sleep' > > > > collect2: ld returned 1 exit status > > make: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/g.mapsets.exe] Error 1 > > > > Not at all sure what's the most elegant way of fixing it??? The sleep() is not needed here so I've removed them in CVS. Still to be done- get rid of hardcoded `ls`: the module already has two fns, get_available_mapsets(); display_available_mapsets(0); so use them instead of UNIXy `ls`. display_available_mapsets() would need to be passed a new option for target: display_available_mapsets(0, stderr); Hamish From hamish_nospam at yahoo.com Wed Dec 6 03:19:33 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 03:19:37 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: References: Message-ID: <20061206151933.5c56faaa.hamish_nospam@yahoo.com> Paul Kelly wrote: > Also gis_set.tcl seems to return the same exit status if either Enter > GRASS or Exit is clicked - is this true? both are successful, the program did what you asked it to. > I was trying to check the %errorlevel% variable in a Windows batch > script to avoid starting gis.m if enter was clicked, but it always > seems to be 0. I don't understand what you are trying to do. You want: the GUI startup screen -> [Enter GRASS] -> DOS prompt ??? ? Hamish From paul-grass at stjohnspoint.co.uk Wed Dec 6 03:34:33 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 6 03:34:38 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: <20061206151933.5c56faaa.hamish_nospam@yahoo.com> References: <20061206151933.5c56faaa.hamish_nospam@yahoo.com> Message-ID: On Wed, 6 Dec 2006, Hamish wrote: > Paul Kelly wrote: >> Also gis_set.tcl seems to return the same exit status if either Enter >> GRASS or Exit is clicked - is this true? > > both are successful, the program did what you asked it to. > >> I was trying to check the %errorlevel% variable in a Windows batch >> script to avoid starting gis.m if enter was clicked, but it always >> seems to be 0. > > I don't understand what you are trying to do. > You want: the GUI startup screen -> [Enter GRASS] -> DOS prompt ??? Sorry, should have read over that before sending, meant to say "if exit was clicked"... I'm calling it from a batch file, snippet: ================================= 1|"%WINGISBASE%\etc\gis_set.tcl" 2| 3|rem if return ok, gis.m start: 4|if %errorlevel% == 1 exit /b 5| 6|"%WINGISBASE%\etc\gm\gm.tcl" 7| 8|"%WINGISBASE%\etc\clean_temp" > NUL: ================================== so line 4 should detect if Exit was clicked and exit the batch file straight away, thus not starting gis.m. I can't see how Init.sh handles this. gis_set.tcl has puts stdout "exit" but not sure how to detect that. I guess I'll eventually work it out though! Paul From glynn at gclements.plus.com Wed Dec 6 06:12:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Dec 6 06:12:38 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <20061206144344.4250858b.hamish_nospam@yahoo.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> <20061206144344.4250858b.hamish_nospam@yahoo.com> Message-ID: <17782.20780.708791.698009@cerise.gclements.plus.com> Hamish wrote: > > OK, so it's not exactly "elegant", but assuming the existence of a > > "sleep" command doesn't seem to be any more of a Unix-ism than > > assuming the existence of an "ls" command. > > so #include is no good in windows? No; the header exists, but it doesn't declare sleep(). The header declares _sleep(), although apparently this is deprecated (it exists in the MSVCRT DLL, but isn't listed in the documentation index) in favour of Sleep(). > isn't the system("ls") going to be a problem as well? Only if you don't have "ls" ;) A lot of the [G_]system and [G_]popen calls in GRASS (I count 105) will be similarly problematic. Some will be calling GRASS programs, but a lot use Unix commands. -- Glynn Clements From hamish_nospam at yahoo.com Wed Dec 6 07:28:27 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 07:28:44 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <17782.20780.708791.698009@cerise.gclements.plus.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> <20061206144344.4250858b.hamish_nospam@yahoo.com> <17782.20780.708791.698009@cerise.gclements.plus.com> Message-ID: <20061206192827.19a9c510.hamish_nospam@yahoo.com> Glynn Clements wrote: > > so #include is no good in windows? > > No; the header exists, but it doesn't declare sleep(). The > header declares _sleep(), although apparently this is deprecated (it > exists in the MSVCRT DLL, but isn't listed in the documentation index) > in favour of Sleep(). sleep() is POSIX.1. Bad Microsoft. > > isn't the system("ls") going to be a problem as well? > > Only if you don't have "ls" ;) > > A lot of the [G_]system and [G_]popen calls in GRASS (I count 105) > will be similarly problematic. Some will be calling GRASS programs, > but a lot use Unix commands. 105 really isn't that many. for the ones that are unix commands, the vast majority are just ls, cp, mv, rm? step 1: define portable tcl and C replacements (e.g. glob, unlink()) for the common ones. (eg with Paul's new G_convert_dirseps_to_host()) step 2: fix it for some high profile module and let folks know that's the reference way to do it. Maybe add to SUBMITTING or a wiki page how to do that well. Putting it in SUBMITTING makes sure that grass devels should know about doing it, putting it in the wiki might help external folks doing a web search. step 3: we fix them as we find them. e.g. if we guess "ls" is the most common unix-ism, AFAICT in the C code that is just 5 files for [G_]system: imagery/i.ortho.photo/libes/ls_cameras.c imagery/i.ortho.photo/libes/ls_elev.c lib/imagery/ls_groups.c these two are really bad: lib/fonts/for_grass/try.c: system ("cd fonts; ls *.hmp | sed 's/.hmp//' | fmt"); lib/fonts/for_grass/fontmap.c: system ("cd ../fonts; ls *.hmp | sed 's/.hmp//' | fmt"); if steps 1 & 2 above could be solved, I think step 3 could happen very quickly. At least we could make a start with the libraries... for popen, lib/gis/error.c and lib/gis/home.c (pwd) look like places to start. Hamish From glynn at gclements.plus.com Wed Dec 6 07:53:36 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Dec 6 07:54:00 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <20061206192827.19a9c510.hamish_nospam@yahoo.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> <20061206144344.4250858b.hamish_nospam@yahoo.com> <17782.20780.708791.698009@cerise.gclements.plus.com> <20061206192827.19a9c510.hamish_nospam@yahoo.com> Message-ID: <17782.26864.605059.391925@cerise.gclements.plus.com> Hamish wrote: > > A lot of the [G_]system and [G_]popen calls in GRASS (I count 105) > > will be similarly problematic. Some will be calling GRASS programs, > > but a lot use Unix commands. > > 105 really isn't that many. > > for the ones that are unix commands, the vast majority are just ls, cp, > mv, rm? I'm not saying it's difficult, just a lot of donkey-work. Although, there are a few non-trivial cases; e.g. replacing "rm -rf" isn't simple, and getting it wrong can be quite disastrous. But we already have a replacement in lib/init/clean_temp.c. rename() is ANSI C, although (on Unix, at least) it only works if the source and destination paths are on the same filesystem (partition), otherwise you have to copy the file then delete the original. Windows has CopyFile(); Unix doesn't have any equivalent (the notion of copying is ambiguous when the destination exists). > step 1: define portable tcl and C replacements (e.g. glob, unlink()) > for the common ones. (eg with Paul's new G_convert_dirseps_to_host()) remove() (ANSI C) is preferable to unlink() (POSIX) for files, although Windows requires using rmdir() (POSIX) for directories. MinGW provides an opendir/readdir/closedir implementation, or you can use FindFirstFile/FindNextFile/FindClose. > these two are really bad: > > lib/fonts/for_grass/try.c: system ("cd fonts; ls *.hmp | sed 's/.hmp//' | fmt"); > lib/fonts/for_grass/fontmap.c: system ("cd ../fonts; ls *.hmp | sed 's/.hmp//' | fmt"); "try" is just a debugging utility. It doesn't get built as part of the normal build process. Also, that section of fontmap.c appears to be for debugging; it only gets called if you specify "ls" as an argument to splitfont. -- Glynn Clements From neteler at itc.it Wed Dec 6 10:31:11 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Dec 6 10:31:16 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: <20061201153951.GF16862@bartok.itc.it> Message-ID: <20061206093111.GA24258@bartok.itc.it> Hi, I have now: - renamed the script 'r.out.gdal' to 'r.out.gdal.sh' - added the 'superseded' therein - activated the C version of r.out.gdal in the Makefile This will also solve the problem that the latest QGIS Windows test built fails on the r.out.gdal[.sh] script as it is lacking gdal_translate in the install package. Many thanks to Vytautas V. for writing the C implementation which is region sensitive and FAST! For the common r.out.gdal basically nothing changes except for the region thing and speed. Markus On Fri, Dec 01, 2006 at 06:30:30PM +0100, Martin Landa wrote: > Hi, > > +1 for r.out.gdal2 -> r.out.gdal(C) > > maybe it could be safer to rename the r.out.gdal(script) to > r.out.gdal2 or r.out.gdal.sh and to add an appropriate warning, e.g. > > WARNING: This module is superseded and will be removed in future > versions of GRASS. Use r.out.gdal instead. > > Martin > > 2006/12/1, Markus Neteler : > >hi, > > > >are there objections to rename r.out.gdal2 to > >r.out.gdal and remove the now obsolete > >scripts/r.out.gdal/ > >? > > > >I have used the C version quite a bit successfully. > > > >Markus > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From hamish_nospam at yahoo.com Wed Dec 6 13:27:35 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 6 13:27:51 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <17782.26864.605059.391925@cerise.gclements.plus.com> References: <17782.3055.550218.547043@cerise.gclements.plus.com> <20061206144344.4250858b.hamish_nospam@yahoo.com> <17782.20780.708791.698009@cerise.gclements.plus.com> <20061206192827.19a9c510.hamish_nospam@yahoo.com> <17782.26864.605059.391925@cerise.gclements.plus.com> Message-ID: <20061207012735.3a2bfbe1.hamish_nospam@yahoo.com> Glynn Clements wrote: > I'm not saying it's difficult, just a lot of donkey-work. well, this is for Windows after all. ;) Hamish From tutey at o2.pl Wed Dec 6 19:04:29 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Dec 6 19:04:33 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: References: Message-ID: <4577062D.4050105@o2.pl> Michael Barton wrote: > On 12/6/06 12:56 AM, "Hamish" wrote: >> Maciej Sieczka wrote: >>> In past it was possible to change the value for any slider by entering >>> the number and pressing Enter. Now it doesn't work. Try with eg. exag. >> works for me (main panel) > Works for me too Indeed, most sliders do work. Here are those which don't fo sure: Vector Points: icon size Raster Surfaces: resolution, both coarse and fine Vector Lines/3D Polygons: line width Do you confirm? I don't know for other 'Visualize' entries as I'm not using them, worthy of checking too I guess. Maciek From jachym.cepicky at centrum.cz Wed Dec 6 19:26:30 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Dec 6 19:26:35 2006 Subject: [GRASS-dev] creating new location in krovak projection In-Reply-To: References: <20061128194254.GA9662@localdomain> <20061128195227.GA10864@bartok.itc.it> <20061201090545.GC7696@localdomain> Message-ID: <20061206182630.GG6576@localdomain> hi Paul, On Tue, Dec 05, 2006 at 10:32:40AM +0000, Paul Kelly wrote: > Hello Jachym > Those datum paramters are already in GRASS (and have been for several > years). The datum short name is hermannskogel, not that obvious and a bit > long, and not my choice but we can't change it now. > > Interestingly the Slovak parameters are (very slightly) different from my > source - they must cover a slightly different part of the country or have a > different accuracy or something. This would need to be confirmed and > documented before adding them to the file. Hopefully the site you got them > from has some information? > > Paul these parameters are from Radim's old GRASS-Krovak page, we have just copied those parameters from that page to our wiki. This means, that we are all adding towgs84 parameter by hand since many years, while we just could add hermannskogel datum :-( That is life. Anyway, do you think, patch for general/g.setproj/proj-parms.table is ok and can be applyed? It worked for me and for Martin, how desired. Howto setup Location with Krovak projection could look like follows: 1 - Press "d" for "Other Projection" 2 - Specify "krovak" for projection name 3 - Press "y", that you want to specify gedetic datum for this location 4 - Choose "hermannskogel" from list of datum names 5 - Choose "2" for Czech republic or 3 for Slovak republic from list of avaliable parameter sets 6 - Plural form of units: meters 7 - Specify default region for your location Does this look ok? thank you Jachym > > On Fri, 1 Dec 2006, Jachym Cepicky wrote: > > >hi, > >together with Martin, we prepared this patch for 6.3. It itroduces new > >geodetic datums for both - Czech and Slovak republic (previously, we had > >to edit PROJ_INFO by hand and add "towgs84" parameter there). > > > >not sure, if this belongs to 6.2 too, but it would be nice to have it > >there. > > > >Thanks > > > >Jachym > > > >On Tue, Nov 28, 2006 at 08:52:27PM +0100, Markus Neteler wrote: > >>On Tue, Nov 28, 2006 at 08:42:54PM +0100, Jachym Cepicky wrote: > >>>Hi, > >>>I would like to define new Location using > >>> > >>>projection krovak > >>>ellipsoid bessel > >>> > >>>when I come to question about projection, I specify "krovak" and hit > >>>Return, GRASS jumps imidietly to DEFNE THE DEFAULT REGION form (for > >>>defining boundary coordinates and resolution). > >>> > >>>When I try do specify new projection with g.setproj, it ends like this: > >>> > >>>GRASS 6.3.cvs (jtsk2):~ > g.setproj > >>> > >>> > >>>Please specify projection name > >>>Enter 'list' for the list of available projections > >>>Hit RETURN to cancel request > >>>>krovak > >>>ERROR: Projection krovak is not specified in the table > >>>GRASS 6.3.cvs (jtsk2):~ > > >>> > >>> > >>>Howto define location using krovak projection? > >> > >>Hi Jachym: > >> > >>the Krovak projection is missing from: > >>general/g.setproj/proj-parms.table > >> > >>I don't know how to add it there. It would be good to get > >> general/g.setproj/README > >>updated on how to add more projections. > >> > >>Markus > >> > >>_______________________________________________ > >>grass-dev mailing list > >>grass-dev@grass.itc.it > >>http://grass.itc.it/mailman/listinfo/grass-dev > > > >-- > >Jachym Cepicky > >e-mail: jachym.cepicky@centrum.cz > >URL: http://les-ejk.cz > >GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > >----------------------------------------- > >OFFICE: > >Department of Geoinformation Technologies > >Zemedelska 3 > >613 00, Brno > >Czech Republick > >e-mail: xcepicky@node.mendelu.cz > >URL: http://mapserver.mendelu.cz > >Tel.: +420 545 134 514 > > -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/624552e5/attachment.bin From paul-grass at stjohnspoint.co.uk Wed Dec 6 19:43:14 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 6 19:43:18 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: <4575EF6D.7020603@o2.pl> References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> <4503F1C0.2000605@o2.pl> <4575E170.70609@o2.pl> <4575E728.6020402@o2.pl> <4575EF6D.7020603@o2.pl> Message-ID: On Tue, 5 Dec 2006, Maciej Sieczka wrote: > Paul, > > Summarising: > > Could you please confirm/deny the 2 statemements below - so that I'm > sure I'm not screwing/missunderstanding something: > > 1. The -z switch is not the default; but it *was* - before you made it > and option few months ago. Yes. There used to be no way to avoid that effect. Now you have to explicitly enable it. > 2. One should use it only when his data is 3D, he is sure the Z coord > is an an ellipsoidal height, and he is transforming between 2 different > ellipsoids. No - even then you should not use it. In fact I can't think of any reason why anybody would want to use it under normal circumstances, and IMHO it was a very serious bug that it was the default before. GPS receivers often output WGS84 ellipsoidal height. In general you want to keep the height in that datum rather than transfer it to another ellipsoid. Generally different ellipsoids are used only for 2-D projection and the height above the ellipsoid is not considered - a separate vertical datum, often based on sea level or something like that is used for height measurements. An example: in Northern Ireland the Ordnance Survey NI (national mapping agency) publishes a set of gridded values that represent the average height differential between WGS84 ellipsoidal height and Mean Sea Level Belfast (the common local vertical datum) at each point. This can thus be used to convert GPS measurements to the local geoid-based MSL Belfast vertical datum. Ellipsoidal height above the Modified Airy ellipsoid (used for Irish Grid 2-D positions) is not relevant at all. > 3. Even if the Z coord of my vector is an ellipsoidal height, using -z > is not supposed to make any change when transformimg between eg. > UTM/WGS84 and ll/WGS84; *it doesn't do any harm though*. No it shouldn't do any harm, although this is a matter/question for PROJ.4 and not for GRASS - GRASS just uses the PROJ pj_transform() function and the transformation happens in there. > I know I'm slow on this, but please bear with me :). I don't want to > mess something up in future with my data or advise something stupid to > others. I understand - this is an important issue and does not seem to be discussed very widely so it is good that we are doing so here. Paul From paul-grass at stjohnspoint.co.uk Wed Dec 6 19:50:24 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 6 19:50:27 2006 Subject: [GRASS-dev] creating new location in krovak projection In-Reply-To: <20061206182630.GG6576@localdomain> References: <20061128194254.GA9662@localdomain> <20061128195227.GA10864@bartok.itc.it> <20061201090545.GC7696@localdomain> <20061206182630.GG6576@localdomain> Message-ID: On Wed, 6 Dec 2006, Jachym Cepicky wrote: > hi Paul, > > On Tue, Dec 05, 2006 at 10:32:40AM +0000, Paul Kelly wrote: >> Hello Jachym >> Those datum paramters are already in GRASS (and have been for several >> years). The datum short name is hermannskogel, not that obvious and a bit >> long, and not my choice but we can't change it now. >> >> Interestingly the Slovak parameters are (very slightly) different from my >> source - they must cover a slightly different part of the country or have a >> different accuracy or something. This would need to be confirmed and >> documented before adding them to the file. Hopefully the site you got them >> from has some information? >> >> Paul > > these parameters are from Radim's old GRASS-Krovak page, we have just > copied those parameters from that page to our wiki. Oh OK. ISTR Radim did some detailed comparisons of datum shift errors using different parameters and produced some nice maps showing the distortion. It would definitely be worthwhile checking that out and why the parameters I got from that European co-ordinate conversion site are different, if anybody has time. > This means, that we are all adding towgs84 parameter by hand since many > years, while we just could add hermannskogel datum :-( That is life. > > Anyway, do you think, patch for > > general/g.setproj/proj-parms.table > > is ok and can be applyed? It worked for me and for Martin, how desired. Yes, please go ahead - I have not followed the recent modifications to g.setproj in much depth but it seems obvious to do. > > > Howto setup Location with Krovak projection could look like follows: > > 1 - Press "d" for "Other Projection" > 2 - Specify "krovak" for projection name > 3 - Press "y", that you want to specify gedetic datum for this location > 4 - Choose "hermannskogel" from list of datum names > 5 - Choose "2" for Czech republic or 3 for Slovak republic from list of > avaliable parameter sets > 6 - Plural form of units: meters > 7 - Specify default region for your location > > Does this look ok? Yes that's right. Paul From dylan.beaudette at gmail.com Wed Dec 6 20:34:51 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Wed Dec 6 20:03:42 2006 Subject: [GRASS-dev] g.mapsets use of sleep() In-Reply-To: <20061207012735.3a2bfbe1.hamish_nospam@yahoo.com> References: <17782.26864.605059.391925@cerise.gclements.plus.com> <20061207012735.3a2bfbe1.hamish_nospam@yahoo.com> Message-ID: <200612061134.51515.dylan.beaudette@gmail.com> On Wednesday 06 December 2006 04:27, Hamish wrote: > Glynn Clements wrote: > > I'm not saying it's difficult, just a lot of donkey-work. > > well, this is for Windows after all. ;) > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev nice- there should be a collection of these great snippets some where - something akin to the r 'fortunes' package. cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From tutey at o2.pl Wed Dec 6 20:19:26 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Dec 6 20:19:29 2006 Subject: [GRASS-dev] v.proj transforming z co-ordinates In-Reply-To: References: <20060830153110.GT1046@bartok.itc.it> <44FAC060.1010306@o2.pl> <4503F1C0.2000605@o2.pl> <4575E170.70609@o2.pl> <4575E728.6020402@o2.pl> <4575EF6D.7020603@o2.pl> Message-ID: <457717BE.3010009@o2.pl> Paul Kelly wrote: > this is an important issue and does not seem to be > discussed very widely so it is good that we are doing so here. Cheers Paul! Continuing this - can you please look at my post on a related issue from several months ago and let me know if I'm writing something wrong there?: http://www.nabble.com/-GRASSLIST%3A10786--Re%3A-SRTM-data-transformation-tf2068135.html#a5693757 Thanks! Maciek From michael.barton at asu.edu Wed Dec 6 21:01:04 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 21:01:11 2006 Subject: [GRASS-dev] more NVIZ updates In-Reply-To: <6E522814-F918-40C6-B5B5-C5D704CF0FB0@unity.ncsu.edu> Message-ID: On 12/5/06 7:01 PM, "Helena Mitasova" wrote: > > there is a difference - 3D rasters represent trivariate functions > so at each point in 3D space you can have a different value - I think > calling this a volume is quite intuitive > > watertower, dinosaur - 3D vector surfaces are quite different - if > you try to represent > it by a volume you would have it filled with just 1 and no-data. > So I don't think that 3D surfaces or 3D vectors should be called > volumes - you essentially have 3D points, lines and areas. Good points. Wish I could say I thought of this so clearly. Volumes *are* different from 3D surface features. Thanks for pointing this out. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Dec 6 21:06:19 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 21:06:24 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: Message-ID: On 12/5/06 7:34 PM, "Paul Kelly" wrote: > so line 4 should detect if Exit was clicked and exit the batch file > straight away, thus not starting gis.m. I can't see how Init.sh handles > this. gis_set.tcl has > puts stdout "exit" > but not sure how to detect that. I guess I'll eventually work it out > though! I'd like to sort this out too so that TclTk can also exit GRASS *if* a user wants to do so. There has already been some discussion along these lines a month back or so. When you exit the GIS Manager GUI it takes you back to the GRASS 'shell'. But I *think* the 'shell' AND gis_set.tcl is operated inside a loop in init.sh. When you type "exit" (or gis_set.tcl exits) it exits the loop and also exits the 'shell'. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From jachym.cepicky at centrum.cz Wed Dec 6 21:19:16 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Dec 6 21:17:55 2006 Subject: [GRASS-dev] creating new location in krovak projection In-Reply-To: References: <20061128194254.GA9662@localdomain> <20061128195227.GA10864@bartok.itc.it> <20061201090545.GC7696@localdomain> <20061206182630.GG6576@localdomain> Message-ID: <20061206201915.GA8161@localdomain> hallo, On Wed, Dec 06, 2006 at 06:50:24PM +0000, Paul Kelly wrote: > On Wed, 6 Dec 2006, Jachym Cepicky wrote: > > > Yes, please go ahead - I have not followed the recent modifications to > g.setproj in much depth but it seems obvious to do. patch commited, only general/g.setproj/proj-params.table modified > > > > > > >Howto setup Location with Krovak projection could look like follows: > > > >1 - Press "d" for "Other Projection" > >2 - Specify "krovak" for projection name > >3 - Press "y", that you want to specify gedetic datum for this location > >4 - Choose "hermannskogel" from list of datum names > >5 - Choose "2" for Czech republic or 3 for Slovak republic from list of > > avaliable parameter sets > >6 - Plural form of units: meters > >7 - Specify default region for your location > > > >Does this look ok? > > Yes that's right. > > Paul > thank you Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/5c059b46/attachment.bin From jachym.cepicky at centrum.cz Wed Dec 6 22:01:19 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Dec 6 21:59:55 2006 Subject: [GRASS-dev] gis.m notes Message-ID: <20061206210119.GC8161@localdomain> Hi, I had some courses with GRASS newbies and so I had opportunity to observe them and see, what kind of trouble they are having with gis.m and GRASS modules. First I have to say, that nobody seemed to have real problems using gis.m and get her/his map or perform some data analysis on it, so: great work Michael and others! The major problem was, that the users expected, that the icon in list of layers for current map display is active, so one can click on it and NOT the text (e.g. raster1). Even when the people knew allready, that they have to click on the text and not on the icon, firstly they tryed to click on the icon, which did not work. Would it be possible to make the icon active too? Second thing, if they start new map-display, their list of layers disappeared and they did not know, that the list of layers is somehow coresponding with (current) mapwindow. Maybe, it would be cool to add kind of tabs for each running display, so you would switch between map displays not only by clicking on them, but also in gis.m window just like e.g. firefox does. It would be cool, if the mapwindow would redraw after new map is added to list of layers (just like arcgis does it) or if there would be some kind of switch for doing this. And last thing, maybe I found some bug in new georectifier: mapset seems to be changed to source mapset (xy) after some conditions and GRASS has to be restarted. We reproduced this bug on 3 computers, but I did not have time to mark the steps, which are leading to this. I'll post some details in the future. I'm just writing this for the case, anybody else noticed this "feature". But as I said, it was great to see new people, who are able "just to work" with GRASS using the new GUI manager. Thanks a lot for your work! Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/d8809100/attachment.bin From tutey at o2.pl Wed Dec 6 22:17:56 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Dec 6 22:18:03 2006 Subject: [GRASS-dev] Re: [GRASS-user] flowdirection In-Reply-To: <20061206211106.644c4003.hamish_nospam@yahoo.com> References: <200612051251.53127.seeger@uni-trier.de> <20061206211106.644c4003.hamish_nospam@yahoo.com> Message-ID: <45773384.2090506@o2.pl> Hamish wrote: > Manuel Seeger wrote: >> another thing. when I use Terraflow with MFD, how are the >> flowdirections expressed in the flowdirection grid? I get values >> between -1 and 255, but I'm not really shure how to treat them/ what >> they express. > > M.D.F.= multi-dimensional flow > > MDF directions: > (based upon the rules in r.terraflow's findDominant() funtion in > direction.cc) > > 32 64 128 > 16 * 1 > 8 4 2 > > so a value of 255 is flow in all directions, a value of 3 is E and SE, a > value of 65 is E and N, etc. I'm not sure exactly what 0 and -1 > represent, hopefully that becomes obvious. > > The r.terraflow help page talks about MDF a bit, it should really have > this info too. Working on it. There was quite a bit to cleanup in the r.terraflow's description.html anyway. Could someone please say what 0 and -1 represent, which Hamish asks, so I include this in the manual? Is null possible? And how is the flow direction coded in case of SFD? Same as MFD, only no multiple directions, thus only 1,2,4,8,16,32,64,128 direction is possible? (that's what I assume...). Please find the attached description.html + pngs and comment them. Maciek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/description-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: rterraflow_codes.png Type: image/png Size: 413 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/rterraflow_codes-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: rterraflow_codes_mfd.png Type: image/png Size: 659 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/rterraflow_codes_mfd-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: rterraflow_codes_sfd.png Type: image/png Size: 568 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/rterraflow_codes_sfd-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: rterraflow_dir2.png Type: image/png Size: 403 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/rterraflow_dir2-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: rterraflow_dir3.png Type: image/png Size: 618 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061206/3614b8ee/rterraflow_dir3-0001.png From neteler at itc.it Wed Dec 6 22:36:47 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Dec 6 22:36:49 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published Message-ID: <20061206213647.GA28175@bartok.itc.it> Dear all, a first release candidate of the new 6.2.1 has been published today: http://grass.itc.it/grass62/source/ grass-6.2.1RC1.tar.gz (12M) A couple of things were fixed: * gis.m fixes for geo rectifier (Michael) * gis.m zoom fixes (Michael) * install of include files problem on Solaris (Glynn) * Handle non-standard ETRS_1989 datum name (Paul) * d.histogram: clear just the current frame, not the full screen (Hamish) * i.group: fix subgroup listing (Hamish) * ps.map: broken for named paper sizes (Hamish, Glynn) * gis.m: meaningful error messages on startup (Michael) * v.db.select: fix SQL where= option error (Hamish) * Add module r.to.rast3elev from Soeren * crash v.in.ogr with gcc4.1.x and non-C locale (Andrey Kiselev) * v.in.db: with where="condition" it copies the entire attribute table (Martin) See also: http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.1RC1 Please test this release candidate as much as possible. Thanks to all contributors and testers. Markus From michael.barton at asu.edu Wed Dec 6 23:31:26 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 6 23:31:34 2006 Subject: [GRASS-dev] gis.m notes In-Reply-To: <20061206210119.GC8161@localdomain> Message-ID: On 12/6/06 2:01 PM, "Jachym Cepicky" wrote: Jachym, Thanks for the feedback. Here are a couple of quick responses. Maybe more with some thought. > Hi, > > I had some courses with GRASS newbies and so I had opportunity to > observe them and see, what kind of trouble they are having with gis.m > and GRASS modules. > > First I have to say, that nobody seemed to have real problems using > gis.m and get her/his map or perform some data analysis on it, so: great > work Michael and others! Thanks. I'm glad to see that it is helping people be productive in GRASS. > > The major problem was, that the users expected, that the icon in > list of layers for current map display is active, so one can click on it and > NOT the > text (e.g. raster1). Even > when the people knew allready, that they have to click on the text and > not on the icon, firstly they tryed to click on the icon, which did not > work. Would it be possible to make the icon active too? This is a good idea. I don't know how hard it is to implement, but I'll see what I can do. > > Second thing, if they start new map-display, their list of layers > disappeared and they did not know, that the list of layers is somehow > coresponding with (current) mapwindow. Maybe, it would be cool to add kind of > tabs for each running display, so you would switch between map displays > not only by clicking on them, but also in gis.m window just like e.g. > firefox does. It would be nice to have some kind of visual indication that you've got a clean slate for each new display but any existing ones are still around. I tried to do as you suggest and was unsuccessful. I ran into underlying programmatic issues (or lack of ability). There is a notebook widget in bwidgets, but I couldn't get it to work correctly in this way automatically with switching displays. On the pragmatic side, the GIS Manager window is pretty small and might run out of room with more than a few displays open. On the other hand, maybe no one would want to open more than a few displays simultaneously. > > It would be cool, if the mapwindow would redraw after new map is added > to list of layers (just like arcgis does it) or if there would be some > kind of switch for doing this. I suggested this on the list and the majority opinion was to do the redraw manually so people wouldn't have to wait for each change or addition to update the display. > > And last thing, maybe I found some bug in new georectifier: mapset seems > to be changed to source mapset (xy) after some conditions and GRASS has to be > restarted. We > reproduced this bug on 3 computers, but I did not have time to mark the > steps, which are leading to this. I'll post some details in the future. > I'm just writing this for the case, anybody else noticed this "feature". In order to work correctly, the georectifier has to switch back and forth between the xy location and the 'working' location. It *should* do this seamlessly. I've run into problems when there is some kind of crash while it is operating in the xy location. I've tried to trap all the possibilities for this I've found. However, if you can document a place this is consistently a problem, I'll try to trap it too. > > But as I said, it was great to see new people, who are able "just to > work" with GRASS using the new GUI manager. Thanks a lot for your work! > > Jachym Thanks. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Thu Dec 7 04:14:02 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 04:14:10 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: References: Message-ID: <20061207161402.33af4fa2.hamish_nospam@yahoo.com> Paul wrote: > so line 4 should detect if Exit was clicked and exit the batch file > straight away, thus not starting gis.m. I can't see how Init.sh > handles this. gis_set.tcl has > puts stdout "exit" > but not sure how to detect that. I guess I'll eventually work it out > though! another thing to look at while we're here- Clicking [Exit] from the GUI startup does not close down cleanly, so does not remove /tmp/grass6-${USER}-$$/. I'm not sure but believe the same happens if you create a new location from EPSG code. (and with EPSG, is the restart *really* needed? It would be nice if we could code some sort of refresh) Hamish From hamish_nospam at yahoo.com Thu Dec 7 05:39:14 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 05:39:19 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061206213647.GA28175@bartok.itc.it> References: <20061206213647.GA28175@bartok.itc.it> Message-ID: <20061207173914.613a1631.hamish_nospam@yahoo.com> Markus Neteler wrote: > a first release candidate of the new 6.2.1 has been published > today: .. > See also: > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.1RC1 > > Please test this release candidate as much as possible. > Thanks to all contributors and testers. great. If there are no problems, will we skip more RCs and release 6.2.1 soon? Draft announcement and blurb now in CVS: http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass621.html?rev=HEAD http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/abstract_grass621.txt?rev=HEAD Hamish From hamish_nospam at yahoo.com Thu Dec 7 05:58:06 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 05:58:09 2006 Subject: [GRASS-dev] Help with gsd_color_func() for NVIZ Message-ID: <20061207175806.4cea5d0b.hamish_nospam@yahoo.com> Hi, I am trying to understand the OpenGL color setting code in NVIZ for changing the North Arrow text color. I am not very good with the bitwise/GL stuff, so can anyone give me a hand at understanding how to feed gsd_color_func() correctly? this is in lib/ogsf/gsd_objs.c and lib/ogsf/gsd_prim.c I was expecting 0x00000 to mean 0xRRGGBB, but it's backwards for me. The least significant pair comes first. (I'm running Pentium4 / 32bit / little endian) some experiments: gsd_color_func(0xFF0000); r=0 g=0 b=-1 a=0 gsd_color_func(0x00FF00); r=0 g=-1 b=0 a=0 gsd_color_func(0x0000FF); r=-1 g=0 b=0 a=0 gsd_color_func(0xFFFFFF); r=-1 g=-1 b=-1 a=0 gsd_color_func(0x00000000); r=0 g=0 b=0 a=0 gsd_color_func(0xFFFFFFFF); r=-1 g=-1 b=-1 a=-1 gsd_color_func(0xFF000000); r=0 g=0 b=0 a=-1 gsd_color_func(0x00FFFFFF); r=-1 g=-1 b=-1 a=0 gsd_color_func(0x000008); r=8 g=0 b=0 a=0 gsd_color_func(0x000010); r=16 g=0 b=0 a=0 gsd_color_func(0x000070); r=112 g=0 b=0 a=0 gsd_color_func(0x000080); r=-128 g=0 b=0 a=0 gsd_color_func(0x000090); r=-112 g=0 b=0 a=0 gsd_color_func(0x0000A0); r=-96 g=0 b=0 a=0 gsd_color_func(0x0000A8); r=-88 g=0 b=0 a=0 gsd_color_func(0x0000FE); r=-2 g=0 b=0 a=0 (am I doing %d with something that should be e.g. %c, %x?) relevant code from gsd_prim.c: #define RED_MASK 0x000000FF #define GRN_MASK 0x0000FF00 #define BLU_MASK 0x00FF0000 #define ALP_MASK 0xFF000000 #define INT_TO_RED(i, r) (r = (i & RED_MASK)) #define INT_TO_GRN(i, g) (g = (i & GRN_MASK) >> 8) #define INT_TO_BLU(i, b) (b = (i & BLU_MASK) >> 16) #define INT_TO_ALP(i, a) (a = (i & ALP_MASK) >> 24) /************************************************************************/ void gsd_color_func(unsigned int col) { GLbyte r, g, b, a; /* OGLXXX * cpack: if argument is not a variable * might need to be: * glColor4b(($1)&0xff, ($1)>>8&0xff, ($1)>>16&0xff, ($1)>>24&0xff) */ INT_TO_RED(col, r); INT_TO_GRN(col, g); INT_TO_BLU(col, b); INT_TO_ALP(col, a); glColor4ub(r, g, b, a); /* HB DEBUG */ fprintf(stderr, "gsd_color_func: r=%d g=%d b=%d a=%d\n", r, g, b, a); return; } /************************************************************************/ thanks, Hamish From hamish_nospam at yahoo.com Thu Dec 7 06:33:49 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 06:33:59 2006 Subject: [GRASS-dev] gis.m notes In-Reply-To: <20061206210119.GC8161@localdomain> References: <20061206210119.GC8161@localdomain> Message-ID: <20061207183349.747d3cf4.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > I had some courses with GRASS newbies and so I had opportunity to > observe them and see, what kind of trouble they are having with gis.m > and GRASS modules. was this with 6.2.0 or 6.3-cvs? (just wondering what's getting tested) > Second thing, if they start new map-display, their list of layers > disappeared and they did not know, that the list of layers is somehow > coresponding with (current) mapwindow. Maybe, it would be cool to add > kind of tabs for each running display, so you would switch between map > displays not only by clicking on them, but also in gis.m window just > like e.g. firefox does. I have suggested in the past, I found it a bit confusing too. If tabs are too hard, at minimum there could be a line of underlined text at the top of the command list which says "Map Display $n command list:" or something like that. Hamish From hamish_nospam at yahoo.com Thu Dec 7 06:39:08 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 06:41:36 2006 Subject: [GRASS-dev] gis.m notes In-Reply-To: References: <20061206210119.GC8161@localdomain> Message-ID: <20061207183908.2f3256df.hamish_nospam@yahoo.com> Michael Barton wrote: > It would be nice to have some kind of visual indication that you've > got a clean slate for each new display but any existing ones are still > around. I tried to do as you suggest and was unsuccessful. I ran into > underlying programmatic issues (or lack of ability). There is a > notebook widget in bwidgets, but I couldn't get it to work correctly > in this way automatically with switching displays. On the pragmatic > side, the GIS Manager window is pretty small and might run out of room > with more than a few displays open. On the other hand, maybe no one > would want to open more than a few displays simultaneously. doesn't help with automatically switching tabs, but see g.region GUI for tab code. I don't think we are too short on vertical space, so a fontsize=10 bold title at the top of the list wouldn't take too much space. I never have more than 3-4 maps in the list at one time. (but I do complicated map making from the command line..) > > It would be cool, if the mapwindow would redraw after new map is > > added to list of layers (just like arcgis does it) or if there would > > be some kind of switch for doing this. > > I suggested this on the list and the majority opinion was to do the > redraw manually so people wouldn't have to wait for each change or > addition to update the display. maybe add a checkbox for this? (default off) it'll be slower... Hamish From jachym.cepicky at centrum.cz Thu Dec 7 06:44:04 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Dec 7 06:44:08 2006 Subject: [GRASS-dev] gis.m notes In-Reply-To: <20061207183349.747d3cf4.hamish_nospam@yahoo.com> References: <20061206210119.GC8161@localdomain> <20061207183349.747d3cf4.hamish_nospam@yahoo.com> Message-ID: <20061207054404.GB20030@localdomain> hi, On Thu, Dec 07, 2006 at 06:33:49PM +1300, Hamish wrote: > Jachym Cepicky wrote: > > I had some courses with GRASS newbies and so I had opportunity to > > observe them and see, what kind of trouble they are having with gis.m > > and GRASS modules. > > was this with 6.2.0 or 6.3-cvs? (just wondering what's getting tested) it was about 3 weeks old version of 6.3 > > > Second thing, if they start new map-display, their list of layers > > disappeared and they did not know, that the list of layers is somehow > > coresponding with (current) mapwindow. Maybe, it would be cool to add > > kind of tabs for each running display, so you would switch between map > > displays not only by clicking on them, but also in gis.m window just > > like e.g. firefox does. > > I have suggested in the past, I found it a bit confusing too. If tabs > are too hard, at minimum there could be a line of underlined text at the > top of the command list which says "Map Display $n command list:" or > something like that. > > > Hamish Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061207/26bb7ad7/attachment.bin From glynn at gclements.plus.com Thu Dec 7 07:03:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Dec 7 07:03:29 2006 Subject: [GRASS-dev] r.resamp.stats error In-Reply-To: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> References: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <17783.44714.536653.86121@cerise.gclements.plus.com> Martin Wegmann wrote: > I found a weird behaviour in r.resamp.stats which causes a shift of the > resulting image but only on a large scale (subcontinental scale, shift to > south-west). > > I tried to reproduce it with the spearfish dataset but failed. > > Doing it on Africa srtm DEM (res based on gtopo30 DEM): > > g.region -g > ... > res=0.00083333 > .. > > g.region res=0.0083333 > r.resamp.stats input=dem output=dem_resampstats method=average > > produces this output of a small region with islands shown in the jpg (overlay > with original raster) > > any idea how to fix this? regards, Martin --- raster/r.resamp.stats/main.c 15 Nov 2006 03:57:24 -0000 1.8 +++ raster/r.resamp.stats/main.c 7 Dec 2006 05:59:11 -0000 @@ -80,13 +80,13 @@ for (col = 0; col <= dst_w.cols; col++) { double x = G_col_to_easting(col, &dst_w); - col_map[col] = (int) floor(G_easting_to_col(x + 0.5, &src_w)); + col_map[col] = (int) floor(G_easting_to_col(x, &src_w) + 0.5); } for (row = 0; row <= dst_w.rows; row++) { double y = G_row_to_northing(row, &dst_w); - row_map[row] = (int) floor(G_northing_to_row(y + 0.5, &src_w)); + row_map[row] = (int) floor(G_northing_to_row(y, &src_w) + 0.5); } Instead of adding half a cell (to locate the midpoint rather than the north-west corner), I was adding half a map unit. For a projected location, the offset was half a metre (or foot), which is negligible. For a lat-lon location, the offset was half a degree, which is rather more significant. Fixed in CVS. -- Glynn Clements From hamish_nospam at yahoo.com Thu Dec 7 08:52:37 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 08:52:42 2006 Subject: [GRASS-dev] new CVS wiki page Message-ID: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> Hi, I have started a new page on the wiki for CVS access & tips. I find the main grass website CVS help pages many, cluttered, complex, and confusing. So trying to start over here with a more concise help page: http://grass.gdf-hannover.de/wiki/Working_with_CVS Hamish From glynn at gclements.plus.com Thu Dec 7 08:54:22 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Dec 7 08:54:25 2006 Subject: [GRASS-dev] Help with gsd_color_func() for NVIZ In-Reply-To: <20061207175806.4cea5d0b.hamish_nospam@yahoo.com> References: <20061207175806.4cea5d0b.hamish_nospam@yahoo.com> Message-ID: <17783.51374.145968.13268@cerise.gclements.plus.com> Hamish wrote: > I am trying to understand the OpenGL color setting code in NVIZ for changing > the North Arrow text color. I am not very good with the bitwise/GL stuff, > so can anyone give me a hand at understanding how to feed gsd_color_func() > correctly? > > > this is in lib/ogsf/gsd_objs.c and lib/ogsf/gsd_prim.c > > I was expecting 0x00000 to mean 0xRRGGBB, but it's backwards for me. > The least significant pair comes first. > (I'm running Pentium4 / 32bit / little endian) That's how gsd_prim.c defines it: > #define RED_MASK 0x000000FF > #define GRN_MASK 0x0000FF00 > #define BLU_MASK 0x00FF0000 > #define ALP_MASK 0xFF000000 > some experiments: > > gsd_color_func(0xFF0000); r=0 g=0 b=-1 a=0 [snip] > (am I doing %d with something that should be e.g. %c, %x?) No; the variables: > GLbyte r, g, b, a; should be GLubyte; GLbyte is signed, i.e. 0xFF == -1. This won't matter to the glColor4ub() call, which will cast them to GLubyte, but it will matter to the fprintf() call, which will cast them to int. -- Glynn Clements From wegmann at biozentrum.uni-wuerzburg.de Thu Dec 7 08:52:58 2006 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Thu Dec 7 08:54:30 2006 Subject: [GRASS-dev] r.resamp.stats error In-Reply-To: <17783.44714.536653.86121@cerise.gclements.plus.com> References: <200612011734.14405.wegmann@biozentrum.uni-wuerzburg.de> <17783.44714.536653.86121@cerise.gclements.plus.com> Message-ID: <200612070852.58078.wegmann@biozentrum.uni-wuerzburg.de> great, very fast response time! thanks a lot! Martin On Thursday 07 December 2006 07:03, Glynn Clements wrote: > Martin Wegmann wrote: > > I found a weird behaviour in r.resamp.stats which causes a shift of the > > resulting image but only on a large scale (subcontinental scale, shift to > > south-west). > > > > I tried to reproduce it with the spearfish dataset but failed. > > > > Doing it on Africa srtm DEM (res based on gtopo30 DEM): > > > > g.region -g > > ... > > res=0.00083333 > > .. > > > > g.region res=0.0083333 > > r.resamp.stats input=dem output=dem_resampstats method=average > > > > produces this output of a small region with islands shown in the jpg > > (overlay with original raster) > > > > any idea how to fix this? regards, Martin > > --- raster/r.resamp.stats/main.c 15 Nov 2006 03:57:24 -0000 1.8 > +++ raster/r.resamp.stats/main.c 7 Dec 2006 05:59:11 -0000 > @@ -80,13 +80,13 @@ > for (col = 0; col <= dst_w.cols; col++) > { > double x = G_col_to_easting(col, &dst_w); > - col_map[col] = (int) floor(G_easting_to_col(x + 0.5, &src_w)); > + col_map[col] = (int) floor(G_easting_to_col(x, &src_w) + 0.5); > } > > for (row = 0; row <= dst_w.rows; row++) > { > double y = G_row_to_northing(row, &dst_w); > - row_map[row] = (int) floor(G_northing_to_row(y + 0.5, &src_w)); > + row_map[row] = (int) floor(G_northing_to_row(y, &src_w) + 0.5); > } > > Instead of adding half a cell (to locate the midpoint rather than the > north-west corner), I was adding half a map unit. > > For a projected location, the offset was half a metre (or foot), which > is negligible. For a lat-lon location, the offset was half a degree, > which is rather more significant. > > Fixed in CVS. From landa.martin at gmail.com Thu Dec 7 09:20:10 2006 From: landa.martin at gmail.com (Martin Landa) Date: Thu Dec 7 09:20:12 2006 Subject: [GRASS-dev] [bug #4451] (grass) New options for g.region In-Reply-To: References: <20061203210032.ED5891005BE@lists.intevation.de> <17779.29377.966414.414928@cerise.gclements.plus.com> Message-ID: Hi, 2006/12/4, Martin Landa : > I have updated the patch for the current CVS > > + reordering flags (Print) > + capitalize messages/warnings/ferrors > - removing size parameter > > Any objections? ok, commited to CVS. Martin > 2006/12/4, Glynn Clements : > > > > Markus Neteler via RT wrote: > > > > > can someone please review this g.region patch proposal? > > > > > > https://intevation.de/rt/webrt?serial_num=4451 > > > > I don't see any point in the size= option; I wouldn't expect it to be > > used much, and you can always just pass the same value to rows= and > > cols=. > > > > The rest of it seems fine. > > > > -- > > Glynn Clements > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From neteler at itc.it Thu Dec 7 09:26:15 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Dec 7 09:26:19 2006 Subject: [GRASS-dev] Unix-isms in gis_set.tcl In-Reply-To: <20061207161402.33af4fa2.hamish_nospam@yahoo.com> References: <20061207161402.33af4fa2.hamish_nospam@yahoo.com> Message-ID: <4577D027.5090805@itc.it> Hamish wrote on 12/07/2006 04:14 AM: > Paul wrote: > >> so line 4 should detect if Exit was clicked and exit the batch file >> straight away, thus not starting gis.m. I can't see how Init.sh >> handles this. gis_set.tcl has >> puts stdout "exit" >> but not sure how to detect that. I guess I'll eventually work it out >> though! >> > > > another thing to look at while we're here- > > Clicking [Exit] from the GUI startup does not close down cleanly, > so does not remove /tmp/grass6-${USER}-$$/. I'm not sure but believe the > same happens if you create a new location from EPSG code. (and with > EPSG, is the restart *really* needed? It would be nice if we could code > some sort of refresh) > I am also hoping that there is a refresh possibility to just re-read the directory (long term wish for a few years now). Then we could get rid of this annoying restart. lib/init/epsg_option.tcl.in, line 158. Markus From hamish_nospam at yahoo.com Thu Dec 7 09:28:11 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Dec 7 09:28:15 2006 Subject: [GRASS-dev] Re: [GRASS-user] 'ARNing: Cannot open driver 'dbf" In-Reply-To: <4577C941.7000507@itc.it> References: <20061207000222.0fac9d71.hamish_nospam@yahoo.com> <750967.20744.qm@web36105.mail.mud.yahoo.com> <20061207190509.7cb02b3b.hamish_nospam@yahoo.com> <4577C941.7000507@itc.it> Message-ID: <20061207212811.7cd96866.hamish_nospam@yahoo.com> Hamish: > > Can anyone else copy vector maps in windows? Markus: > in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special > treatment on Windows. See for example lib/gis/mapset_msc.c here I leave this bug- I leave Windows developement as a challenge for others to pursue. Hamish From neteler at itc.it Thu Dec 7 11:47:03 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Dec 7 11:47:06 2006 Subject: mkdir function - was: Re: [GRASS-dev] Re: [GRASS-user] 'ARNing: Cannot open driver 'dbf" In-Reply-To: <20061207212811.7cd96866.hamish_nospam@yahoo.com> References: <20061207000222.0fac9d71.hamish_nospam@yahoo.com> <750967.20744.qm@web36105.mail.mud.yahoo.com> <20061207190509.7cb02b3b.hamish_nospam@yahoo.com> <4577C941.7000507@itc.it> <20061207212811.7cd96866.hamish_nospam@yahoo.com> Message-ID: <4577F127.9000204@itc.it> Hamish wrote on 12/07/2006 09:28 AM: > Hamish: > >>> Can anyone else copy vector maps in windows? >>> > > Markus: > >> in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special >> treatment on Windows. See for example lib/gis/mapset_msc.c >> > > here I leave this bug- I leave Windows developement as a challenge for > others to pursue. > There are some candidates for this fix (contains some false positives): find . -type f -name "*.c" -exec grep -l mkdir {} \; ./general/manage/lib/do_copy.c ./raster/r.li/r.li.daemon/daemon.c ./raster/r.le/r.le.setup/main.c ./raster/r.le/r.le.patch/main.c ./raster/r.le/r.le.pixel/main.c ./lib/init/mke_mapset.c ./lib/init/mke_loc.c ./lib/db/dbmi_driver/d_mkdir.c ./lib/gis/make_mapset.c ./lib/gis/make_loc.c ./lib/gis/mapset_msc.c ./lib/gis/win32_pipes.c ./lib/gis/unix_socks.c ./lib/gis/paths.c ./lib/gis/user_config.c ./lib/raster/io_fifo.c ./lib/g3d/g3dwindowio.c ./gem/reg_entries.c ./gem/actions.c lib/gis/paths.c Probably a search/replace of ' mkdir' would do, using G_mkdir() from ./lib/gis/paths.c ? Or we need to modify G_mkdir() to accepts two parameters. Markus From glynn at gclements.plus.com Thu Dec 7 13:02:09 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Dec 7 13:02:11 2006 Subject: mkdir function - was: Re: [GRASS-dev] Re: [GRASS-user] 'ARNing: Cannot open driver 'dbf" In-Reply-To: <4577F127.9000204@itc.it> References: <20061207000222.0fac9d71.hamish_nospam@yahoo.com> <750967.20744.qm@web36105.mail.mud.yahoo.com> <20061207190509.7cb02b3b.hamish_nospam@yahoo.com> <4577C941.7000507@itc.it> <20061207212811.7cd96866.hamish_nospam@yahoo.com> <4577F127.9000204@itc.it> Message-ID: <17784.705.539266.65270@cerise.gclements.plus.com> Markus Neteler wrote: > >> in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special > >> treatment on Windows. See for example lib/gis/mapset_msc.c > >> > > > > here I leave this bug- I leave Windows developement as a challenge for > > others to pursue. > > There are some candidates for this fix (contains some false positives): > > find . -type f -name "*.c" -exec grep -l mkdir {} \; > ./general/manage/lib/do_copy.c > ./raster/r.li/r.li.daemon/daemon.c > ./raster/r.le/r.le.setup/main.c > ./raster/r.le/r.le.patch/main.c > ./raster/r.le/r.le.pixel/main.c > ./lib/init/mke_mapset.c > ./lib/init/mke_loc.c > ./lib/db/dbmi_driver/d_mkdir.c > ./lib/gis/make_mapset.c > ./lib/gis/make_loc.c > ./lib/gis/mapset_msc.c > ./lib/gis/win32_pipes.c > ./lib/gis/unix_socks.c > ./lib/gis/paths.c > ./lib/gis/user_config.c > ./lib/raster/io_fifo.c > ./lib/g3d/g3dwindowio.c > ./gem/reg_entries.c > ./gem/actions.c > lib/gis/paths.c > > Probably a search/replace of ' mkdir' would do, using G_mkdir() from > ./lib/gis/paths.c > ? Or we need to modify G_mkdir() to accepts two parameters. No, G_mkdir() is fine. On Unix, the mode argument should always be 0777, so the user has complete control of the permissions via their umask; anything which uses a more restrictive mode is second-guessing the user. The only programs which should be setting permissions explicitly are those which provide some other mechanism for the user to control the permissions. -- Glynn Clements From michael.barton at asu.edu Thu Dec 7 16:07:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Dec 7 16:08:15 2006 Subject: [GRASS-dev] gis.m notes In-Reply-To: <20061207183349.747d3cf4.hamish_nospam@yahoo.com> Message-ID: On 12/6/06 10:33 PM, "Hamish" wrote: > are too hard, at minimum there could be a line of underlined text at the > top of the command list which says "Map Display $n command list:" or > something like that. I'm pretty sure that this is easy to do. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From jachym.cepicky at centrum.cz Thu Dec 7 17:30:00 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Dec 7 17:30:05 2006 Subject: [GRASS-dev] v.to.db option=slope Message-ID: <20061207163000.GA28829@localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061207/e94ef854/attachment-0001.bin From neteler at itc.it Thu Dec 7 17:43:23 2006 From: neteler at itc.it (Markus Neteler) Date: Thu Dec 7 17:43:25 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061207163000.GA28829@localdomain> References: <20061207163000.GA28829@localdomain> Message-ID: <20061207164323.GB2732@bartok.itc.it> On Thu, Dec 07, 2006 at 05:30:00PM +0100, Jachym Cepicky wrote: > Hallo, > somebody asked on IRC, how to calculate slopes for vector lines. > > This patch should add new option "slope" to v.to.db module and calculate slope steepness > for each vector line > > What do you think, shall I commit this patch to cvs? > Hi Jachym, nice idea! Without inspecting the patch, does it work in LatLong? Markus From dylan.beaudette at gmail.com Thu Dec 7 17:48:11 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Thu Dec 7 17:48:14 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061207163000.GA28829@localdomain> References: <20061207163000.GA28829@localdomain> Message-ID: <3c5546140612070848v57f7f148s22a6b772246683ce@mail.gmail.com> Interesting patch Jachym! Out of curiosity, and not being able to extract it from the patch, how exactly does this approach work? Are you caclulating a slope between vertices of a 3D vector? Looking forward to learning more about it! Great job, Dylan On 12/7/06, Jachym Cepicky wrote: > Hallo, > somebody asked on IRC, how to calculate slopes for vector lines. > > This patch should add new option "slope" to v.to.db module and calculate slope steepness > for each vector line > > What do you think, shall I commit this patch to cvs? > > Jachym > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > ----------------------------------------- > OFFICE: > Department of Geoinformation Technologies > Zemedelska 3 > 613 00, Brno > Czech Republick > e-mail: xcepicky@node.mendelu.cz > URL: http://mapserver.mendelu.cz > Tel.: +420 545 134 514 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFFeEGIyKt0uAjU4I8RAnlMAJ0R7J0aHMDAQ9rLIO9Ch3tJw03UTwCgomsY > wa4JKzCgM8UPheYO55p3fA4= > =F/eE > -----END PGP SIGNATURE----- > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > > From jachym.cepicky at centrum.cz Thu Dec 7 18:17:01 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Dec 7 18:17:06 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061207164323.GB2732@bartok.itc.it> References: <20061207163000.GA28829@localdomain> <20061207164323.GB2732@bartok.itc.it> Message-ID: <20061207171701.GA29798@localdomain> hi, On Thu, Dec 07, 2006 at 05:43:23PM +0100, Markus Neteler wrote: > On Thu, Dec 07, 2006 at 05:30:00PM +0100, Jachym Cepicky wrote: > > Hallo, > > somebody asked on IRC, how to calculate slopes for vector lines. > > > > This patch should add new option "slope" to v.to.db module and calculate slope steepness > > for each vector line > > > > What do you think, shall I commit this patch to cvs? > > > > Hi Jachym, > > nice idea! Without inspecting the patch, does it work in LatLong? > > Markus no, it does not :-( it does not even work with option=length, because of Vect_cidx_get_num_unique_cats_by_index ( &Map, Vect_cidx_get_field_index(&Map, options.field ) ); in main.c returns 1634887471 of unique cats by index and v.to.db ends up with G_calloc error: could not allocat memory. I have no clue, how to fix this bug. Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061207/3063f836/attachment.bin From jachym.cepicky at centrum.cz Thu Dec 7 18:20:07 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Dec 7 18:20:11 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <3c5546140612070848v57f7f148s22a6b772246683ce@mail.gmail.com> References: <20061207163000.GA28829@localdomain> <3c5546140612070848v57f7f148s22a6b772246683ce@mail.gmail.com> Message-ID: <20061207172007.GB29798@localdomain> hi, On Thu, Dec 07, 2006 at 08:48:11AM -0800, Dylan Beaudette wrote: > Interesting patch Jachym! > > Out of curiosity, and not being able to extract it from the patch, how > exactly does this approach work? Are you caclulating a slope between > vertices of a 3D vector? it works very simply: (z_end - z_start)/length2d so you get _approximated_ slope for whole line. e.g. + + \ / \ / `---? would result into slope=0 > > Looking forward to learning more about it! > > Great job, just a small patch ;-) > > Dylan thanks jachym > > On 12/7/06, Jachym Cepicky wrote: > >Hallo, > >somebody asked on IRC, how to calculate slopes for vector lines. > > > >This patch should add new option "slope" to v.to.db module and calculate > >slope steepness > >for each vector line > > > >What do you think, shall I commit this patch to cvs? > > > >Jachym > >-- > >Jachym Cepicky > >e-mail: jachym.cepicky@centrum.cz > >URL: http://les-ejk.cz > >GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > >----------------------------------------- > >OFFICE: > >Department of Geoinformation Technologies > >Zemedelska 3 > >613 00, Brno > >Czech Republick > >e-mail: xcepicky@node.mendelu.cz > >URL: http://mapserver.mendelu.cz > >Tel.: +420 545 134 514 > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.3 (GNU/Linux) > > > >iD8DBQFFeEGIyKt0uAjU4I8RAnlMAJ0R7J0aHMDAQ9rLIO9Ch3tJw03UTwCgomsY > >wa4JKzCgM8UPheYO55p3fA4= > >=F/eE > >-----END PGP SIGNATURE----- > > > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@grass.itc.it > >http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061207/935a2fbc/attachment.bin From bcovill at tekmap.ns.ca Thu Dec 7 20:22:58 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Thu Dec 7 20:23:23 2006 Subject: [GRASS-dev] North Arrow updates Message-ID: <1165519378.16676.6.camel@linuxmain.localhost> Hamish & Michael, I have just applied a couple of changes to NVIZ to pick up some problems I was having with the new North Arrow args. I have added the updated arrow routine to togl_flythrough.c (it won't build without it) and I fixed the number of allowable argc in Ndraw_Narrow_cmd (draw.c). I have also removed a duplicate place_narrow procedure from panel_fringe.tcl which was calling Ndraw_Narrow with the old number of args. I also set the default arrow and text colors in panel_main.tcl to black (you might want to change these). Hopefully this has not broken anything you were trying to do. -- Bob From dylan.beaudette at gmail.com Thu Dec 7 21:23:09 2006 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Thu Dec 7 20:51:47 2006 Subject: [GRASS-dev] new CVS wiki page In-Reply-To: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> References: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> Message-ID: <200612071223.09879.dylan.beaudette@gmail.com> On Wednesday 06 December 2006 23:52, Hamish wrote: > Hi, > > I have started a new page on the wiki for CVS access & tips. I find the > main grass website CVS help pages many, cluttered, complex, and > confusing. So trying to start over here with a more concise help page: > > http://grass.gdf-hannover.de/wiki/Working_with_CVS > > > > Hamish > Hamish, This is a great asset for those of us (me) in the 'not quite ready for prime time' developer camp. Thanks! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From tutey at o2.pl Thu Dec 7 21:54:49 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Dec 7 21:54:55 2006 Subject: [GRASS-dev] new CVS wiki page In-Reply-To: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> References: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> Message-ID: <45787F99.7070107@o2.pl> Hamish wrote: > Hi, > > I have started a new page on the wiki for CVS access & tips. Excellent! Could someone please put an info there how to merge changes from HEAD into a release branch? Currently usually Markus does most of this, he could use some help I guess. And I could merge my fixes for manuals myself. Maciek From jachym.cepicky at centrum.cz Thu Dec 7 21:31:23 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Dec 7 22:02:38 2006 Subject: [GRASS-dev] fprintf in raster modules converted to G_message Message-ID: <20061207203123.GA6396@localdomain> Hallo, after some time, I hope, I (with help of Soeren and others) managed to convert (hopefuly) all fprintf(stderr functions to G_message, G_warning and G_fatal_error Most of the messages were also prepared for localisation, using _() macro. Actually, there are few modules, which are a bit complicated and I'm not able to find or distinguish between module outputs and module messages (e.g. new r.li modules). And sorry, my C-knowledge are poor and my C++-knowledge are sub-zero - r.terraflow is one big unknown. If anybody could fix it, would be cool. So, please test the r.* modules, check their verbosity level or just try to think, if some message is really necessary or if it could be removed. Next step could be update of vlib, and all v.* modules so that they react on --v/--q flags. I would also like to grep -r -i "not found" * and replace it for standard message (maybe defined in gis.h?), that "File not found". Thanks for your testing, hints and help. I hope, no module is broken now. Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061207/e742c649/attachment.bin From michael.barton at asu.edu Thu Dec 7 22:31:32 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Dec 7 22:31:37 2006 Subject: [GRASS-dev] where is GEM? Message-ID: GEM is included with the GRASS source, but doesn?t seem to build by default?nor can I find a switch in configure to make it build. How do is this done now? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061207/12fd2693/attachment.html From michael.barton at asu.edu Thu Dec 7 22:32:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Dec 7 22:32:58 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <1165519378.16676.6.camel@linuxmain.localhost> Message-ID: On 12/7/06 12:22 PM, "Bob Covill" wrote: > Hamish & Michael, > > I have just applied a couple of changes to NVIZ to pick up some problems > I was having with the new North Arrow args. I have added the updated > arrow routine to togl_flythrough.c (it won't build without it) and I > fixed the number of allowable argc in Ndraw_Narrow_cmd (draw.c). > > I have also removed a duplicate place_narrow procedure from > panel_fringe.tcl which was calling Ndraw_Narrow with the old number of > args. I also set the default arrow and text colors in panel_main.tcl to > black (you might want to change these). > > Hopefully this has not broken anything you were trying to do. > > -- > Bob > I just committed my changes from last night and this morning and am compiling it all. So I can test in a few minutes. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-bugs at intevation.de Thu Dec 7 22:48:56 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Dec 7 22:48:59 2006 Subject: [GRASS-dev] [bug #5371] (grass) Create new location from EPSG code is problematic Message-ID: <20061207214856.7F49D1006C1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5371 ------------------------------------------------------------------------- Subject: Create new location from EPSG code is problematic Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.2.0 tcl-8.4.13 "Path to new location" - Browse button is useless as it's impossible to choose directory; "EPSG code" -> "Browse" - I don't see my selection and thus can not understand, that I can Crtl+C to copy code, I can't select code in any other way. It needs atleast one sentence at top of list like "write down number on peace of paper for later use..."; I pasted EPSG number using middle mouse button but GUI button "Define location" was inactive. Typing in code by keyboard fixed problem. When startup screen pops up, it has hilited new location, but it's not selected - there are no mapsets shown, altough "Enter GRASS" button is active (but it shouldn't). There is also error message in xterm "ERROR: LOCATION << /home/ddd/tmp/3302.tmp >> not available" Location's name should be "newLocation" and not "3302.tmp". Pressing "Enter GRASS" results in failure - "PERMANENT is not a valid mapset". .grassrc6 content after creating new location from EPSG code: LOCATION_NAME: 3302.tmp MAPSET: PERMANENT DIGITIZER: none GISDBASE: /home/ddd/tmp Clicking on hilited "newLocation" fixes problem and I can start GRASS as expected. -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Dec 7 22:59:27 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Dec 7 22:59:28 2006 Subject: [GRASS-dev] [bug #5372] (grass) Create new location from georeferenced file fails at first run Message-ID: <20061207215927.161D51006C1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5372 ------------------------------------------------------------------------- Subject: Create new location from georeferenced file fails at first run Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 tcl-8.4.13 Start GRASS for first time (no .grasrc file), at startup screen choose "Create new location from georeferenced file". "Browse" button at "Path to new location" is useless, as I can not choose direcotry in any way (it has "Open" button, that just opens directory); Choose georeferenced file (i.e. r/v.out.glad/ogr export from Spearfish), click on "Define location" and it fails with error: access: No such file or directory ERROR: LOCATION << /home/ddd/ >> not available ERROR: g.proj exited abnormally. Press to continue. and GRASS exits with message about restart for new location. Creating new location based on Georeferenced file, if I have already started GRASS (i.e. by creating new location by EPSG code) works as charm (except that "Browse" problem). -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Dec 7 23:07:48 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Dec 7 23:07:50 2006 Subject: [GRASS-dev] [bug #5373] (grass) Create new location from EPSG code accpts garbage as code Message-ID: <20061207220748.BEDC41006C1@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5373 ------------------------------------------------------------------------- Subject: Create new location from EPSG code accpts garbage as code Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 Create new location from EPSG code will accept any garbage as EPSG code and pass it for location creation. Next message from GRASS will not indicate any problems (like wrong EPSG code). After GRASS restart (click on OK at popuped rstart dialog) there is new location "randomnubmer.tmp" with mapset PERMANENT, but it is not valid mapset (as it should be). 1) If EPSG code can be only number, it's easy to catch user error before pasing it for processing; 2) There should be some notification to user if creaton of new location has failed. -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Thu Dec 7 23:14:17 2006 From: michael.barton at asu.edu (Michael Barton) Date: Thu Dec 7 23:14:22 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <1165519378.16676.6.camel@linuxmain.localhost> Message-ID: On 12/7/06 12:22 PM, "Bob Covill" wrote: > Hamish & Michael, > > I have just applied a couple of changes to NVIZ to pick up some problems > I was having with the new North Arrow args. I have added the updated > arrow routine to togl_flythrough.c (it won't build without it) and I > fixed the number of allowable argc in Ndraw_Narrow_cmd (draw.c). > > I have also removed a duplicate place_narrow procedure from > panel_fringe.tcl which was calling Ndraw_Narrow with the old number of > args. I also set the default arrow and text colors in panel_main.tcl to > black (you might want to change these). > > Hopefully this has not broken anything you were trying to do. > > -- > Bob > I just updated and compiled GRASS 6.3 from the cvs. I don't see any visual change in the arrow panel. Is the new code not implemented yet? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From maris.gis at gmail.com Thu Dec 7 23:25:02 2006 From: maris.gis at gmail.com (Maris Nartiss) Date: Thu Dec 7 23:25:04 2006 Subject: [GRASS-dev] How to reproduce RT Ticket 5328 Message-ID: <2b3d8c1c0612071425p7ebc039bve994bbd731631dd7@mail.gmail.com> Hi all, I could not find how to post response in RT, so I emailed it. Reproduction of Ticket 5328 is peace of cake if you are n00b ;) 1) rm .grassrc6; 2) Start grass and type something in "Create new mapset" -> babah. Error1; 3) Choose any dir as location, type something into "Create new mapset" -> babah. Error2 (as reported). Error messages attached for record. Error1: couldn't change working directory to "/home/ddd/": no such file or directory couldn't change working directory to "/home/ddd/": no such file or directory while executing "cd $dir" (procedure "CheckLocation" line 9) invoked from within "CheckLocation" invoked from within ".frame0.frameNMS.third.button invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tk::ButtonUp" line 22) invoked from within "tk::ButtonUp .frame0.frameNMS.third.button" (command bound to event) Error 2: couldn't change working directory to "##ERROR##": no such file or directory couldn't change working directory to "##ERROR##": no such file or directory while executing "cd $location" invoked from within ".frame0.frameNMS.third.button invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tk::ButtonUp" line 22) invoked from within "tk::ButtonUp .frame0.frameNMS.third.button" (command bound to event) Easiest way to fix it - check if there exists subdirectory for "location" dir named "PERMANENT", as it should be in all valid locations. Maris. PS. I know, it's easy to talk, hard to do :) From hamish_nospam at yahoo.com Fri Dec 8 00:30:39 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 8 00:34:12 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: References: <1165519378.16676.6.camel@linuxmain.localhost> Message-ID: <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> > > I have just applied a couple of changes to NVIZ to pick up some > > problems I was having with the new North Arrow args. I have added > > the updated arrow routine to togl_flythrough.c (it won't build > > without it) and I fixed the number of allowable argc in > > Ndraw_Narrow_cmd (draw.c). thanks. I've now done the same for the new scalebar code as well. > > I also set the default arrow and text colors in > > panel_main.tcl to black (you might want to change these). I changed the default text color to white as the two are drawn on top of each other. Note the text color is ignored. I will look into this next. > > Hopefully this has not broken anything you were trying to do. on the contrary, thanks for filling in bits I missed. > I just updated and compiled GRASS 6.3 from the cvs. I don't see any > visual change in the arrow panel. Is the new code not implemented yet? No, Bob's changes didn't add to the panel, just finished the job I started yesterday. You will need to add in the color selection code to panel_arrow.tcl (I suggest copying it from panel_fringe.tcl). For the scalebar panel I think we should wait until the arrow panel is finalized, then just copy it vs. duplicating changes during development. How do folks like the new shape of the north arrow? To me it looks a bit like an arrowhead or spear. (shrug) Hamish From hamish_nospam at yahoo.com Fri Dec 8 01:25:48 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 8 01:27:13 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> References: <1165519378.16676.6.camel@linuxmain.localhost> <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> Message-ID: <20061208132548.40ce414c.hamish_nospam@yahoo.com> Hamish wrote: > > > I also set the default arrow and text colors in > > > panel_main.tcl to black (you might want to change these). > > I changed the default text color to white as the two are drawn > on top of each other. Note the text color is ignored. I will look > into this next. A bit stuck... The north arrow "North" text uses basically the same method as the panel_label.tcl text (which works), but "North" always comes out white. If I add: gsd_colormode(CM_COLOR); before the gl commands I get the color through, but then the 3D surface goes all black. If after the gl calls I add: gsd_colormode(CM_AD); it mostly gets back to normal, but looks a bit washed out.* The 3D surface stays black if I do: gsd_colormode(CM_DIFFUSE); instead of CM_AD. (I don't know what the colormodes do, I'm just trying things here) [*] bug #4238 ? I'm not sure if the bug is really in my video card driver, as no one else has reported the same problem AFAIK. https://intevation.de/rt/webrt?serial_num=4238 here's some of the code: ======================================= lib/ogsf/gsd_objs.c gsd_north_arrow() : gsd_color_func(text_clr); txt = "North"; ... glRasterPos3fv(base[0]); glListBase(fontbase); glCallLists(strlen(txt), GL_BYTE, (GLubyte *) txt); GS_done_draw(); gsd_popmatrix(); gsd_flush(); ======================================= panel_label.tcl leads to: lib/ogsf/gsd_label.c: /* Set text color */ gsd_color_func(color); do_label_display(fontbase, labpt, text); lib/ogsf/gsd_fonts.c /*****************************************/ void do_label_display(GLuint fontbase, float *lab_pos, char *txt) { glRasterPos2f(lab_pos[X], lab_pos[Y]); glListBase(fontbase); glCallLists(strlen(txt), GL_BYTE, (GLubyte *) txt); return; } ======================================= I don't see the difference. (beyond 2D/3D placement) ? Hamish From bcovill at tekmap.ns.ca Fri Dec 8 01:55:12 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Fri Dec 8 01:55:37 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061208132548.40ce414c.hamish_nospam@yahoo.com> References: <1165519378.16676.6.camel@linuxmain.localhost> <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> <20061208132548.40ce414c.hamish_nospam@yahoo.com> Message-ID: <1165539312.6558.8.camel@linuxmain.localhost> Hamish, For me the text color is working. The default color is set in panel_main.tcl is where the color is currently being set (initialized). For example if you change the value for arw_text_clr to 0xFF0000 you should see a red "North". Presumably this will eventually be a user controlled option in the arrow panel. Did you intend the text "North" color to be changed differently? -- Bob On Fri, 2006-12-08 at 13:25 +1300, Hamish wrote: > Hamish wrote: > > > > I also set the default arrow and text colors in > > > > panel_main.tcl to black (you might want to change these). > > > > I changed the default text color to white as the two are drawn > > on top of each other. Note the text color is ignored. I will look > > into this next. > > A bit stuck... > > The north arrow "North" text uses basically the same method as the > panel_label.tcl text (which works), but "North" always comes out white. > > If I add: > gsd_colormode(CM_COLOR); > before the gl commands I get the color through, but then the 3D surface > goes all black. If after the gl calls I add: > gsd_colormode(CM_AD); > it mostly gets back to normal, but looks a bit washed out.* > > The 3D surface stays black if I do: > gsd_colormode(CM_DIFFUSE); > instead of CM_AD. > > (I don't know what the colormodes do, I'm just trying things here) > > > [*] bug #4238 ? I'm not sure if the bug is really in my video card driver, > as no one else has reported the same problem AFAIK. > https://intevation.de/rt/webrt?serial_num=4238 > > > here's some of the code: > > ======================================= > > lib/ogsf/gsd_objs.c gsd_north_arrow() : > gsd_color_func(text_clr); > txt = "North"; > ... > glRasterPos3fv(base[0]); > glListBase(fontbase); > glCallLists(strlen(txt), GL_BYTE, (GLubyte *) txt); > GS_done_draw(); > > gsd_popmatrix(); > gsd_flush(); > > ======================================= > > panel_label.tcl leads to: > > lib/ogsf/gsd_label.c: > /* Set text color */ > gsd_color_func(color); > do_label_display(fontbase, labpt, text); > > > lib/ogsf/gsd_fonts.c > /*****************************************/ > void do_label_display(GLuint fontbase, float *lab_pos, char *txt) > { > glRasterPos2f(lab_pos[X], lab_pos[Y]); > glListBase(fontbase); > glCallLists(strlen(txt), GL_BYTE, (GLubyte *) txt); > > return; > } > > ======================================= > > > I don't see the difference. (beyond 2D/3D placement) > > > ? > Hamish From hamish_nospam at yahoo.com Fri Dec 8 01:58:13 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 8 01:58:19 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061208132548.40ce414c.hamish_nospam@yahoo.com> References: <1165519378.16676.6.camel@linuxmain.localhost> <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> <20061208132548.40ce414c.hamish_nospam@yahoo.com> Message-ID: <20061208135813.6c89d1eb.hamish_nospam@yahoo.com> some NVIZ compiler warnings that might be worth looking into: -o OBJ.i686-pc-linux-gnu/site_attr_commands.o -c site_attr_commands.c site_attr_commands.c: In function `Nsite_attr_get_fields_name_cmd': site_attr_commands.c:336: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `Nsite_attr_get_fields_type_cmd': site_attr_commands.c:369: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `Nsite_attr_get_fields_name_and_type_cmd': site_attr_commands.c:404: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `Nsite_attr_get_field_values_cmd': site_attr_commands.c:459: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `Nsite_attr_get_field_not_emtpy_cats_cmd': site_attr_commands.c:506: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `Nsite_attr_get_record_values_cmd': site_attr_commands.c:562: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `site_attr_close_map': site_attr_commands.c:628: warning: passing arg 1 of `G_sites_close' from incompatible pointer type site_attr_commands.c: In function `site_attr_set': site_attr_commands.c:662: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_attr_commands.c:663: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_attr_commands.c:678: warning: passing arg 5 of `site_attr_set_size' from incompatible pointer type site_attr_commands.c:678: warning: passing arg 6 of `site_attr_set_size' from incompatible pointer type site_attr_commands.c:687: warning: passing arg 5 of `site_attr_set_color' from incompatible pointer type site_attr_commands.c:687: warning: passing arg 6 of `site_attr_set_color' from incompatible pointer type site_attr_commands.c: In function `Nget_interpolated_values_cmd': site_attr_commands.c:915: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_attr_commands.c:916: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_attr_commands.c:921: warning: passing arg 2 of `attr_interp_colors' from incompatible pointer type site_attr_commands.c:921: warning: passing arg 3 of `attr_interp_colors' from incompatible pointer type site_attr_commands.c:924: warning: passing arg 2 of `attr_interp_entries' from incompatible pointer type site_attr_commands.c:924: warning: passing arg 3 of `attr_interp_entries' from incompatible pointer type site_attr_commands.c:930: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type gcc -I/usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -I/usr/include/tcl8.3 -I/usr/include/tcl8.3 -I/usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/include -I/usr/include -I/usr/X11R6/include -DPACKAGE=\""grassmods"\" -I/usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/include \ -o OBJ.i686-pc-linux-gnu/site_highlight_commands.o -c site_highlight_commands.c site_highlight_commands.c: In function `Nsite_highlight_list_cmd': site_highlight_commands.c:386: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_highlight_commands.c:393: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:399: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:405: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:410: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:414: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:418: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c: In function `Nsite_unhighlight_list_cmd': site_highlight_commands.c:465: warning: passing arg 4 of `Tcl_SplitList' from incompatible pointer type site_highlight_commands.c:469: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:472: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:475: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type site_highlight_commands.c:478: warning: passing arg 2 of `site_highlight_loop' from incompatible pointer type ? Hamish From hamish_nospam at yahoo.com Fri Dec 8 02:43:45 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Dec 8 02:44:52 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <1165539312.6558.8.camel@linuxmain.localhost> References: <1165519378.16676.6.camel@linuxmain.localhost> <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> <20061208132548.40ce414c.hamish_nospam@yahoo.com> <1165539312.6558.8.camel@linuxmain.localhost> Message-ID: <20061208144345.3c1ea87c.hamish_nospam@yahoo.com> Bob Covill wrote: > For me the text color is working. That's good news. > The default color is set in panel_main.tcl is where the color is > currently being set (initialized). For example if you change the value > for arw_text_clr to 0xFF0000 you should see a red "North". It's always white for me no matter what I change arw_text_clr to. I have to call gsd_colormode(CM_COLOR); to get the color to change. (but that then messes up the lighting for everything else) so more likely: > > [*] bug #4238 ? I'm not sure if the bug is really in my video card > > driver, as no one else has reported the same problem AFAIK. > > https://intevation.de/rt/webrt?serial_num=4238 ? > Presumably this will eventually be a user controlled option in the > arrow panel. yes. > Did you intend the text "North" color to be changed differently? as you've stated above. Hamish From michael.barton at asu.edu Fri Dec 8 02:51:56 2006 From: michael.barton at asu.edu (Michael Barton) Date: Fri Dec 8 02:52:12 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061208133009.191f1000.hbowman@albers.otago.ac.nz> Message-ID: On 12/7/06 5:30 PM, "M. Hamish Bowman" wrote: > some NVIZ compiler warnings that might be worth looking into: > > -o OBJ.i686-pc-linux-gnu/site_attr_commands.o -c site_attr_commands.c > site_attr_commands.c: In function `Nsite_attr_get_fields_name_cmd': > site_attr_commands.c:336: warning: passing arg 1 of `G_sites_close' from > incompatible pointer type I don't understand this. I did make some changes to panel_sites.tcl and sites_attr.tcl, but didn't do anything to the C-code for these panels. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Fri Dec 8 03:09:28 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Dec 8 03:09:30 2006 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <457882F8.2020001@o2.pl> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> Message-ID: <17784.51544.421727.643216@cerise.gclements.plus.com> [CC'd to grass-dev] Maciej Sieczka wrote: > > Is this a problem with large files that I will just have to work around or > > is it something to do with my setup? > > Propably the same, very old issue: > http://intevation.de/rt/webrt?serial_num=241 I looked into this a while ago. Unfortunately, you can't use rowio (or a home-grown equivalent), as libgis doesn't allow the projection to be changed while maps are open. So, you have to read the entire input map, close it, change the projection, then write the output map. To get around the memory issues, you would first need to copy the relevant portion of the input map to a temporary file, then use a cache backed by that file. The segment library would do the job, although it could add a significant performance overhead. -- Glynn Clements From glynn at gclements.plus.com Fri Dec 8 03:25:06 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Dec 8 03:25:08 2006 Subject: [GRASS-dev] new CVS wiki page In-Reply-To: <45787F99.7070107@o2.pl> References: <20061207205237.3ff4815e.hamish_nospam@yahoo.com> <45787F99.7070107@o2.pl> Message-ID: <17784.52482.666541.249222@cerise.gclements.plus.com> Maciej Sieczka wrote: > > I have started a new page on the wiki for CVS access & tips. > > Excellent! Could someone please put an info there how to merge changes > from HEAD into a release branch? Currently usually Markus does most of > this, he could use some help I guess. And I could merge my fixes for > manuals myself. This is easier said than done. The trick with merging is figuring out what you want to merge, rather than how to achieve it. In general terms, merging is performed by first using "cvs update" with two "-j" switches, then committing the merged version. Commits always go to the current branch, so you need to have a checked-out copy of the release branch in order to be able to merge changes into it. The key point is that you need to pass the correct revisions to the -j switches. If multiple commits have been made since the branch occurred, and you only want to commit some of them, you need to identify the "before" and "after" revisions corresponding to the changes which you wish to merge. When dealing with multiple files, it's usually necessary to specify a revision as a branch tag and a date. Note that specifying a branch tag alone refers to the latest common ancestor of the branch and the working copy, usually the "root" of the branch, not the head of the branch. -- Glynn Clements From glynn at gclements.plus.com Fri Dec 8 03:40:12 2006 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Dec 8 03:41:20 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061208132548.40ce414c.hamish_nospam@yahoo.com> References: <1165519378.16676.6.camel@linuxmain.localhost> <20061208123039.3a1c9ad1.hamish_nospam@yahoo.com> <20061208132548.40ce414c.hamish_nospam@yahoo.com> Message-ID: <17784.53388.485777.480828@cerise.gclements.plus.com> Hamish wrote: > Hamish wrote: > > > > I also set the default arrow and text colors in > > > > panel_main.tcl to black (you might want to change these). > > > > I changed the default text color to white as the two are drawn > > on top of each other. Note the text color is ignored. I will look > > into this next. > > A bit stuck... > > The north arrow "North" text uses basically the same method as the > panel_label.tcl text (which works), but "North" always comes out white. > > If I add: > gsd_colormode(CM_COLOR); > before the gl commands I get the color through, but then the 3D surface > goes all black. If after the gl calls I add: > gsd_colormode(CM_AD); > it mostly gets back to normal, but looks a bit washed out.* > > The 3D surface stays black if I do: > gsd_colormode(CM_DIFFUSE); > instead of CM_AD. > > (I don't know what the colormodes do, I'm just trying things here) After gsd_init_lightmodel(), the state will initially be equivalent to CM_NULL, although it may subsequently be changed, possibly to a state which doesn't correspond to anything which can be achieved through gsd_colormode(). For safety, I suggest using glPushAttrib(GL_LIGHTING_BIT) and glPopAttrib() to save and restore the lighting state. -- Glynn Clements From jachym.cepicky at centrum.cz Fri Dec 8 09:20:52 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Fri Dec 8 09:21:01 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion Message-ID: <20061208082052.GA11461@localdomain> Hi, I started Wiki page, which should specify future tool, which would replace current v.digit module [1]. IMHO future v.digit should be based on v.edit module for geometry operations and db.* modules for database management. Current version of v.edit supports only two operations: add and delete. In the wiki, I tryed to define desired behavior of the module, so it would be usable for real editing of vector data. Help with this documentation and with coding welcome! Wolf, initial author of v.edit, did great job. v.edit has IMHO nice design. Most of the functions can be adopted from v.in.ascii. Please add your notes or completions to Wiki and if you can, drop some pieces of code to vector/v.edit/* ;-) Jachym [1] http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061208/45f6444d/attachment.bin From neteler at itc.it Fri Dec 8 17:16:47 2006 From: neteler at itc.it (Markus Neteler) Date: Fri Dec 8 17:16:48 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061207173914.613a1631.hamish_nospam@yahoo.com> References: <20061206213647.GA28175@bartok.itc.it> <20061207173914.613a1631.hamish_nospam@yahoo.com> Message-ID: <20061208161647.GC19448@bartok.itc.it> On Thu, Dec 07, 2006 at 05:39:14PM +1300, Hamish wrote: > Markus Neteler wrote: > > a first release candidate of the new 6.2.1 has been published > > today: > .. > > See also: > > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.1RC1 > > > > Please test this release candidate as much as possible. > > Thanks to all contributors and testers. > > great. > > If there are no problems, will we skip more RCs and release 6.2.1 soon? That's fine. But so far we had zero feedback if 6.2.1RC1 works. Especially the gis.m needs a test. > Draft announcement and blurb now in CVS: > > http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/announce_grass621.html?rev=HEAD > http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/web/announces/abstract_grass621.txt?rev=HEAD > > Hamish Thanks for putting the text together. Markus From neteler.osgeo at gmail.com Fri Dec 8 18:12:21 2006 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Fri Dec 8 18:12:28 2006 Subject: [GRASS-dev] Legal document adopted by PSC Message-ID: <86782b610612080912l48c73744s10929e317c8ab37b@mail.gmail.com> We had positive dicussions on the legal document which defines aspects of code contributions, so we hereby declare the current document as adopted (GRASS 6-CVS-HEAD, rfc/RFC2_PSC.dox at http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/rfc/RFC2_PSC.dox?rev=1.2 ). I'll work on getting these documents out as HTML files on the grass Web site. thanks, Markus On 11/28/06, Massimiliano Cannata wrote: > Really clear and exhaustive! > Well done. > Massimiliano > > Michael Barton wrote: > > I'm not any kind of legal expert, but this looks very good. Thanks for doing > > it Markus. > > > > Michael > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics and Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > > >> From: Markus Neteler > >> Date: Tue, 28 Nov 2006 18:16:19 +0100 > >> To: GRASS-PSC > >> Subject: Legal document - was: Re: [GRASS-PSC] Request: CVS Write Access to > >> Serena Pallecchi > >> > >> On 11/28/06, Brad Douglas wrote: > >> > >>> On Tue, 2006-11-28 at 13:02 +1300, Hamish wrote: > >>> > >>>> Brad Douglas wrote: > >>>> > >>>>> Looks good. My only comment is to provide a physical address that is > >>>>> associated with GRASS. This is probably required for legality, but > >>>>> specifically to allow copyright holders to remove themselves as stated > >>>>> in the new documents. > >>>>> > >>>>> I would suggest that the address correspond to the PSC lead. > >>>>> > >>>> GRASS> g.version -c > >>>> GRASS 6.3.cvs (2006) > >>>> > >>>> Copyright and License Statement > >>>> > >> ... > >> > >>>> Questions regarding GRASS GIS should be directed to the > >>>> GRASS Development Team at the following address: > >>>> > >>>> GRASS Development Team > >>>> ITC-Irst > >>>> c/o M. Neteler > >>>> SSI/MPA > >>>> Via Sommarive, 18 > >>>> 38050 Trento (Povo) > >>>> Italy > >>>> neteler@itc.it > >>>> > >>> IMHO, this should be copied into documentation or at least referenced. > >>> > >> I have merged in Hamish's modified sentence and added the address > >> plus Web reference. See attached "grass_code_contribution_v3.txt'. > >> > >> While I don't think that I am official PSC chair (am I?), I have added our > >> address here to save time to get the document done. > >> > >> Please look at attached document again. If ok, we should upload it > >> to the GRASS-CVS and then tell the other developers about it for > >> their comments. > >> > >> Best, > >> Markus > >> _______________________________________________ > >> grass-psc mailing list > >> grass-psc@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-psc > >> > > > > _______________________________________________ > > grass-psc mailing list > > grass-psc@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-psc > > > -- > > Dr. Eng. Massimiliano Cannata > Responsabile Area Geomatica > Istituto Scienze della Terra > Scuola Universitaria Professionale della Svizzera Italiana > Via Trevano, c.p. 72 > CH-6952 Canobbio-Lugano > Tel: +41 (0)58 666 62 14 > Fax +41 (0)58 666 62 09 From tutey at o2.pl Fri Dec 8 20:12:06 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Dec 8 20:12:15 2006 Subject: [GRASS-dev] Re: [GRASS-user] v.build.polylines strange behaviour In-Reply-To: <45794E3E.8050807@amu.edu.pl> References: <45794E3E.8050807@amu.edu.pl> Message-ID: <4579B906.9070107@o2.pl> Jaros?aw Jasiewicz wrote: > Hi > When v.build.polylines is splied on file with islands ie: small areas > inside lareger ones: > > > _________ > | ___ | > | | | | > | |__| | > |________| > > the boundary of island doubles. This is a known long standing bug. Please see: v.build.polylines: fails to build a polyline out of a closed boundary http://intevation.de/rt/webrt?serial_num=424 It happens only when the input closed boundary already has only 2 nodes (IOW when it is already a closed polyline). If there are more than two nodes in the input closed boundary, the bug will not crop out. However, under any circumstanses, v.build.polylines always outputs doubled vertices at each input node, which is another bug: http://intevation.de/rt/webrt?serial_num=4249 A workaround is 'v.clean tool=prune thresh=0'. I wish somebody could try fixing these for incoming 6.2.1. Rather serious bugs... Maciek From grass-bugs at intevation.de Fri Dec 8 21:36:41 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Dec 8 21:36:43 2006 Subject: [GRASS-dev] [bug #5375] (grass) Canadian Pharrmacy,MR J G ROSS Message-ID: <20061208203641.674DF101EE6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5375 ------------------------------------------------------------------------- Peace on earth, good will to men http://newforholiday.com --------------------------------------------------------------------------------------------------------------------------------------------- DEMANDTEC EMAIL NOTICE: NOTICE: This email transmission and all attached files contain information intended for the designated individual or entity to whom it is addressed and may contain information that is proprietary, privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this email or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately by replying to this message and please delete the original message without making any copies. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. Although we have taken reasonable precautions to ensure that this email and all attachments are free from viruses, we accept no liability for any loss or damage arising from the use of this email or its attachments. Linda Gilchick V PARAMASIVAM rajesh r shah amanda ruble N. Sanjeev --- Headers Follow --- >From plqjyj@bpig.com Fri Dec 8 21:36:41 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 06C1A101EE2 for ; Fri, 8 Dec 2006 21:36:41 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id D7DF719FD2F for ; Fri, 8 Dec 2006 21:36:40 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 8E52D19FDB5 for ; Fri, 8 Dec 2006 21:36:40 +0100 (CET) Received: from smtp.consolidatedlabel.com (smtp.consolidatedlabel.com [207.59.44.5]) by kolab.intevation.de (Postfix) with SMTP id BEF5C19FD2F for ; Fri, 8 Dec 2006 21:36:33 +0100 (CET) Received: from root by smtp.consolidatedlabel.com (Postfix) with SMTP id uQ1t66R7tCl5 for ; Fri, 08 Dec 2006 15:01:15 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker:DKSLD== X-IronPort-AV:i="1.98,322,3293821909"; d="scan'544"; a="2138989:sNHT858557586" Message-ID: From: Florian Mueller To: grass-bugs Subject: Canadian Pharrmacy,MR J G ROSS Date: Fri, 08 Dec 2006 14:52:12 -0500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: plqjyj X-AIMC-MAILFROM: plqjyj@bpig.com X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=0.9 tagged_above=-999 required=3 tests=[BAYES_50=0.9] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From soerengebbert at gmx.de Sat Dec 9 01:56:39 2006 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Sat Dec 9 01:56:41 2006 Subject: [GRASS-dev] Re: [Qgis-developer] QGIS Windows Snapshot - with WMS and SPIT In-Reply-To: References: Message-ID: <20061209005639.218120@gmx.net> Hi Tim, thanks great work! I have checked the grass modules with the grass-test-suite. The result is available here: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_win32/ Here are some screenshots of the qgis-grass shell with some test-suite run results: http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_general_db.png http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_rast3d_vector.png http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_raster.png Most of the modules are working well, only r3.info seems to have problems with windows. Best regards Soeren -------- Original-Nachricht -------- Datum: Fri, 8 Dec 2006 17:01:59 -0600 Von: "Tim Sutton" An: qgis-developer , qgis-user Betreff: [Qgis-developer] QGIS Windows Snapshot - with WMS and SPIT > Hi > > I've uploaded a new snapshot of QGIS for windows with WMS raster > support and SPIT plugint: > > http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe > > > Regards > > -- > -- > Tim Sutton > > Visit http://qgis.org for a great Open Source GIS > Home Page: http://linfiniti.com > Skype: timlinux > MSN: tim_bdworld@msn.com > Yahoo: tim_bdworld@yahoo.com > Jabber: timlinux > Irc: timlinux on #qgis at freenode.net > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.qgis.org > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer -- "Ein Herz f?r Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankesch?n: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! From tim at linfiniti.com Sat Dec 9 02:50:06 2006 From: tim at linfiniti.com (Tim Sutton) Date: Sat Dec 9 06:42:19 2006 Subject: [GRASS-dev] Re: [Qgis-developer] QGIS Windows Snapshot - with WMS and SPIT In-Reply-To: <20061209005639.218120@gmx.net> References: <20061209005639.218120@gmx.net> Message-ID: Hi Soren Thanks very much for the useful feedback. At this point I am still using the grass modules from crosscompiled grass. Until I can get grass to build natively under msys it will be difficult for me to resolve these. Currently grass configure fails to find XDR rpc lib even though I have sucessfully build and installed XDR. I'll try to work something out for though.... Regards Tim On 12/8/06, "S?ren Gebbert" wrote: > Hi Tim, > thanks great work! > > I have checked the grass modules with the grass-test-suite. > The result is available here: > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_win32/ > > Here are some screenshots of the qgis-grass shell with some test-suite run results: > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_general_db.png > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_rast3d_vector.png > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/Qgis_0_8_Grass_6_3_Mingw_TestSuite_raster.png > > Most of the modules are working well, only r3.info seems to have > problems with windows. > > Best regards > Soeren > > > -------- Original-Nachricht -------- > Datum: Fri, 8 Dec 2006 17:01:59 -0600 > Von: "Tim Sutton" > An: qgis-developer , qgis-user > Betreff: [Qgis-developer] QGIS Windows Snapshot - with WMS and SPIT > > > Hi > > > > I've uploaded a new snapshot of QGIS for windows with WMS raster > > support and SPIT plugint: > > > > http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe > > > > > > Regards > > > > -- > > -- > > Tim Sutton > > > > Visit http://qgis.org for a great Open Source GIS > > Home Page: http://linfiniti.com > > Skype: timlinux > > MSN: tim_bdworld@msn.com > > Yahoo: tim_bdworld@yahoo.com > > Jabber: timlinux > > Irc: timlinux on #qgis at freenode.net > > _______________________________________________ > > Qgis-developer mailing list > > Qgis-developer@lists.qgis.org > > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer > > -- > "Ein Herz f?r Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de > Unser Dankesch?n: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! > -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From gnelson at uiuc.edu Fri Dec 8 17:17:18 2006 From: gnelson at uiuc.edu (Gerald Nelson) Date: Sat Dec 9 06:43:40 2006 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set Message-ID: <20061208101718.AGN31413@expms1.cites.uiuc.edu> I was able to use gdalwarp successfully. I exported the file as a geotiff, warped it and then imported the new geotif. Thanks for the tip on that. Whoever came up with the names for the options was not into readability! Is there any possibility that r.proj could become a front end for gdalwarp; essentially doing the steps I did manually behind the scenes? Thanks, Jerry ---- Original message ---- >Date: Fri, 8 Dec 2006 02:09:28 +0000 >From: Glynn Clements >Subject: Re: [GRASS-user] problems using r.proj with large data set >To: Maciej Sieczka >Cc: JerryNelson , grassuser@grass.itc.it, grass-dev@grass.itc.it > > >[CC'd to grass-dev] > >Maciej Sieczka wrote: > >> > Is this a problem with large files that I will just have to work around or >> > is it something to do with my setup? >> >> Propably the same, very old issue: >> http://intevation.de/rt/webrt?serial_num=241 > >I looked into this a while ago. Unfortunately, you can't use rowio (or >a home-grown equivalent), as libgis doesn't allow the projection to be >changed while maps are open. So, you have to read the entire input >map, close it, change the projection, then write the output map. > >To get around the memory issues, you would first need to copy the >relevant portion of the input map to a temporary file, then use a >cache backed by that file. > >The segment library would do the job, although it could add a >significant performance overhead. > >-- >Glynn Clements Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From grass-bugs at intevation.de Sat Dec 9 08:58:33 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Dec 9 08:58:36 2006 Subject: [GRASS-dev] [bug #5376] (grass) =?utf-8?b?woHCnMKOZMKOwpbCi0HCgsOowoLDicKW?= =?utf-8?b?wrPCl8K/woLDhcKKw7HCgsOowpPCucKBw4vCgXnCiXfCkU/CgsOFwpBs?= =?utf-8?b?wo3DiMKCw4bCkcOSwo3Ch8KCw63CgsK5woLDhMKDesKDZcKDwovCgsOW?= =?utf-8?b?wpLCvMKNc8KBeg==?= Message-ID: <20061209075833.81B0E1006AE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5376 ------------------------------------------------------------------------- **************************************************** “–ƒTƒCƒg‚Í40‘ã`50‘ã‚Ì“÷‘ÌŠÖŒW‚ð‹‚ß‚Ä‚¢‚élÈEn— ‚ªW‚Ü‚é“ú–{Å‘å‚Ì“÷‘ÌŠÖŒWƒRƒ~ƒ…ƒjƒeƒB[ƒTƒCƒg‚Å‚·B **************************************************** s‚²—˜—p‚ÉŠÖ‚µ‚Ä‚Ì‚²’ˆÓt------------------------------- ‡T@‚²—˜—p‚Í’j—‹¤‚É40ΈÈã‚Ì•û‚Ì‚Ý‚Æ‚³‚¹‚Ä’¸‚«‚Ü‚·B ‡U@’j—‹¤‚É‚¨‘ŠŽè‚É—v‹‚·‚鎖‚Í“÷‘ÌŠÖŒW‚Ì‚Ý‚Å‚·B ‡V@ƒzƒeƒ‹‘ã‚ÉŠÖ‚µ‚Ä‚Í‚¨ŒÝ‚¢‚ÅŒˆ‚߂ĉº‚³‚¢B s‚²—˜—p•û–@‚ɂ‚¢‚Ät----------------------------------- ‡T@‚²Šó–]‚Ì’nˆæEƒ[ƒ‹ƒAƒhƒŒƒXEƒpƒXƒ[ƒh‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡U@ŽŸ‚ÉŠÈ’P‚ÈŽ©ŒÈPR‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡V@“÷‘ÌŠÖŒW‚ðŠó–]‚·‚邨‘ŠŽè‚ðŒŸõ‚µ‚Ä’¸‚«‚Ü‚·B ‡W@‚²—˜—p‚³‚ê‚Ä‚¢‚élÈEn—‚³‚ñ‚Í‘S‚ÄŽ©ŒÈPR“à‚ÉŒg‘єԆ–”‚Í @@’¼ƒAƒhƒŒƒX‚ª•\Ž¦‚³‚ê‚Ä‚¨‚è‚Ü‚·‚Ì‚Å‚»‚ÌŽž“_‚Å’¼Ú‚²˜A—‚ð @@‚µ‚Ä’¸‚¢‚Ä‚àŒ‹\‚Å‚·‚µAƒTƒCƒg“à‚©‚çƒ[ƒ‹‚ɂĘA—‚ðŽæ‚é @@Ž–‚à‰Â”\‚Å‚·‚Ì‚Å‚¨D‚«‚ȘA—•û–@‚ÅŒð‚µ‚ĉº‚³‚¢B y’ˆÓzŽ©ŒÈPR“à‚ɘA—æ‚Ì•\Ž¦‚ª–³‚¢lÈEn—‚³‚ñ‚Í @@@@Œð‚ª¬—§‚µ“÷‘ÌŠÖŒW’†‚Å‚·‚̂ŘA—æ‚Ì•\Ž¦‚ª @@@@•œŠˆŒãAÄ“xŒðÂ‚ð‚¨Šè‚¢’v‚µ‚Ü‚·B ************************************************************** œ–{“úAn‚ꂽlÈEn—‚Æ“÷‘ÌŠÖŒW‚ðŠó–]‚³‚ê‚é40ΈÈã‚Ì’j«‚Í @http://cocomtv.com:112/ddd/40-navi/ œ–{“úA‰ÎÆ‚Á‚½‘Ì‚ð–ž‚½‚µ‚Ä—~‚µ‚¢40ΈÈã‚Ì—«‚Í @http://95216.com:112/ddd/40-navi/ ************************************************************** š‘Ò‡‚킹‚ÌêŠ‚ðƒŠƒAƒ‹ƒ^ƒCƒ€‚Å‚â‚èŽæ‚èŠm”F‚³‚ꂽ‚¢•û‚Í @ƒ‚ƒoƒCƒ‹iŒg‘Ñ“d˜bj‚Å‚ÌÝ’è‚ðƒIƒXƒXƒ’v‚µ‚Ü‚·B ************************************************************** --- Headers Follow --- >From miho3211@enet.com.cn Sat Dec 9 08:58:33 2006 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (aktaia [212.95.126.10]) by lists.intevation.de (Postfix) with ESMTP id 279D91005D2 for ; Sat, 9 Dec 2006 08:58:33 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id C47AD1A24FA for ; Sat, 9 Dec 2006 08:58:32 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 9D2081A3110 for ; Sat, 9 Dec 2006 08:58:32 +0100 (CET) Received: from mail (unknown [211.115.228.84]) by kolab.intevation.de (Postfix) with ESMTP id 159871A24FA for ; Sat, 9 Dec 2006 08:58:31 +0100 (CET) Received: by mail (Postfix, from userid 48) id 6BDE568EC2C; Sun, 10 Dec 2006 02:04:05 +0900 (KST) To: grass-bugs@intevation.de Subject: =?ISO-2022-JP?B?gZyOZI6Wi0GC6ILJlrOXv4LFivGC6JO5gcuBeYl3kU+CxZBsjciCxpHSjYeC7YK5gsSDeoNlg4uC1pK8jXOBeg===?= From: Resent-Sender: miho3211@enet.com.cn Message-ID: <20061210020405.31949@enet.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Resent-Message-Id: <20061209170405.6BDE568EC2C@mail> Resent-Date: Sun, 10 Dec 2006 02:04:05 +0900 (KST) Resent-From: miho3211@enet.com.cn (Apache) X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=1.416 tagged_above=-999 required=3 tests=[DATE_IN_FUTURE_06_12=1.3, NO_REAL_NAME=0.007, WEIRD_PORT=0.109] X-Spam-Level: * -------------------------------------------- Managed by Request Tracker From soerengebbert at gmx.de Sat Dec 9 11:42:03 2006 From: soerengebbert at gmx.de (=?UTF-8?B?U8O2cmVuIEdlYmJlcnQ=?=) Date: Sat Dec 9 11:42:08 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061206213647.GA28175@bartok.itc.it> References: <20061206213647.GA28175@bartok.itc.it> Message-ID: <457A92FB.7010401@gmx.de> Hi Markus, the lates grass-test-suite results for grass-6.2.1RC1 are available here: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ A test for r.to.rast3elev was added. No errors found. :) Best regards Soeren Markus Neteler schrieb: > Dear all, > > a first release candidate of the new 6.2.1 has been published > today: > http://grass.itc.it/grass62/source/ > grass-6.2.1RC1.tar.gz (12M) > > A couple of things were fixed: > * gis.m fixes for geo rectifier (Michael) > * gis.m zoom fixes (Michael) > * install of include files problem on Solaris (Glynn) > * Handle non-standard ETRS_1989 datum name (Paul) > * d.histogram: clear just the current frame, not the full screen (Hamish) > * i.group: fix subgroup listing (Hamish) > * ps.map: broken for named paper sizes (Hamish, Glynn) > * gis.m: meaningful error messages on startup (Michael) > * v.db.select: fix SQL where= option error (Hamish) > * Add module r.to.rast3elev from Soeren > * crash v.in.ogr with gcc4.1.x and non-C locale (Andrey Kiselev) > * v.in.db: with where="condition" it copies the entire attribute table (Martin) > > See also: > http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#6.2.1RC1 > > Please test this release candidate as much as possible. > Thanks to all contributors and testers. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From rez at touchofmadness.com Sat Dec 9 15:26:11 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Dec 9 15:26:16 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <457A92FB.7010401@gmx.de> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> Message-ID: <1165674371.21250.34.camel@devel> On Sat, 2006-12-09 at 11:42 +0100, S?ren Gebbert wrote: > Hi Markus, > the lates grass-test-suite results for grass-6.2.1RC1 are available here: > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ > > A test for r.to.rast3elev was added. > No errors found. :) I cannot speak highly enough of the test suite. It lends credibility and saves time. Markus, I also built successfully. You may no longer make claims of lacking feedback. :-) -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From neteler at itc.it Sat Dec 9 16:06:28 2006 From: neteler at itc.it (Markus Neteler) Date: Sat Dec 9 16:06:30 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <1165674371.21250.34.camel@devel> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> Message-ID: <20061209150628.GA27879@bartok.itc.it> On Sat, Dec 09, 2006 at 06:26:11AM -0800, Brad Douglas wrote: > On Sat, 2006-12-09 at 11:42 +0100, S?ren Gebbert wrote: > > Hi Markus, > > the lates grass-test-suite results for grass-6.2.1RC1 are available here: > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ > > > > A test for r.to.rast3elev was added. > > No errors found. :) > > I cannot speak highly enough of the test suite. It lends credibility > and saves time. > > Markus, > > I also built successfully. You may no longer make claims of lacking > feedback. :-) Excellent! Now we only need to receive a quick test of gis.m. Markus From maris.gis at gmail.com Sat Dec 9 16:11:54 2006 From: maris.gis at gmail.com (Maris Nartiss) Date: Sat Dec 9 16:11:57 2006 Subject: [GRASS-dev] Re: fprintf in raster modules converted to G_message In-Reply-To: <20061207203123.GA6396@localdomain> References: <20061207203123.GA6396@localdomain> Message-ID: <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> Hi, last night I was cleaning up GRASS translation and found GRASS error messages very inconsistent. I.e. "Map not found" can be as "[%s] - map not found", "Map '%s' not found", "Map <%s> not found", "Map <%s@%s> not found" etc. It would be realy nice to set up some common error messages for usage in code like: G_err_rnf(map,mapset) -> "Raster map <%s@%s> was not found." etc. for most common error messages like "Raster not found", "Vector not found", "Could not write to raster" etc. It would make translators life more easy and improve usability - one type of error, one message in all places for that error. Just my 0.002 cents (equals 0.002 dollars by Verizon) Maris. 2006/12/7, Jachym Cepicky : > > I would also like to grep -r -i "not found" * and replace it for > standard message (maybe defined in gis.h?), that "File not found". > > Thanks for your testing, hints and help. I hope, no module is broken > now. > > Jachym > -- > Jachym Cepicky > From rez at touchofmadness.com Sun Dec 10 14:17:29 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Dec 10 14:17:36 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061209150628.GA27879@bartok.itc.it> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> Message-ID: <1165756649.21250.121.camel@devel> On Sat, 2006-12-09 at 16:06 +0100, Markus Neteler wrote: > On Sat, Dec 09, 2006 at 06:26:11AM -0800, Brad Douglas wrote: > > On Sat, 2006-12-09 at 11:42 +0100, S?ren Gebbert wrote: > > > Hi Markus, > > > the lates grass-test-suite results for grass-6.2.1RC1 are available here: > > > http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ > > > > > > A test for r.to.rast3elev was added. > > > No errors found. :) > > > > I cannot speak highly enough of the test suite. It lends credibility > > and saves time. > > > > Markus, > > > > I also built successfully. You may no longer make claims of lacking > > feedback. :-) > > Excellent! > Now we only need to receive a quick test of gis.m. I spent 5-10 minutes testing gis.m. It appears in working order, but I only tested basics. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From rez at touchofmadness.com Sun Dec 10 15:04:11 2006 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Dec 10 15:04:16 2006 Subject: [GRASS-dev] Re: fprintf in raster modules converted to G_message In-Reply-To: <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> References: <20061207203123.GA6396@localdomain> <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> Message-ID: <1165759451.21250.164.camel@devel> On Sat, 2006-12-09 at 17:11 +0200, Maris Nartiss wrote: > Hi, > > last night I was cleaning up GRASS translation and found GRASS error > messages very inconsistent. > I.e. "Map not found" can be as "[%s] - map not found", "Map '%s' not > found", "Map <%s> not found", "Map <%s@%s> not found" etc. > It would be realy nice to set up some common error messages for usage > in code like: > G_err_rnf(map,mapset) -> "Raster map <%s@%s> was not found." etc. for > most common error messages like "Raster not found", "Vector not > found", "Could not write to raster" etc. > It would make translators life more easy and improve usability - one > type of error, one message in all places for that error. I've thought about this, too, but have other priorities. :( The best idea I can come up with is a sparse series of macros for the most common messages: #define MSG_RASTER_OPEN_FILE "Unable to find raster [%s]" #define MSG_RASTER_OPEN_FILE_MAPSET "Unable to find raster <%s@%s>" #define MSG_RASTER_WRITE_FILE "Unable to write to raster [%s]" ... This is the madness to my method: MSG -> to be used with messaging functions (G_warning()/G_fatal_error()) RASTER -> operating on OPEN -> operation WRITE -> another operation FILE -> argument MAPSET -> argument Everything after the operation are arguments for "easy" recognition of what to pass in. Then use the message functions: G_fatal_error (MSG_RASTER_OPEN_FILE, raster_map); Okay, we now have a standard set of messages, but now locale macros need to be dealt with. There's a few ways to deal with it, but none of them seem trivial to me. I can see this quickly becoming unwieldy, too. Others may have better ideas. > Just my 0.002 cents (equals 0.002 dollars by Verizon) > Maris. Apparently, 5th grade math isn't a requirement for management. ;-) -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Mon Dec 11 02:24:30 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 02:25:43 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: References: <20061210001349.0586d7d7.hamish_nospam@yahoo.com> Message-ID: <20061211142430.45dd944a.hamish_nospam@yahoo.com> is it possible to have the "Place Arrow" button change the mouse cursor to crosshairs when in the the nviz canvas? I have been thinking about making a polygon "N" for the north arrow, that would get around text placement & color issues. (below arrow, same width, same color) Text placement & color issues would still remain for the scalebar of course. Hamish From hamish_nospam at yahoo.com Mon Dec 11 04:41:26 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 04:41:34 2006 Subject: [GRASS-dev] Re: fprintf in raster modules converted to G_message In-Reply-To: <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> References: <20061207203123.GA6396@localdomain> <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> Message-ID: <20061211164126.01c0a8e7.hamish_nospam@yahoo.com> Maris Nartiss wrote: > last night I was cleaning up GRASS translation and found GRASS error > messages very inconsistent. In the past when adding i18n macros to modules I have used this method: #search for messages already in use: grass-src$ cd raster raster$ grep -rI -A5 G_find_cell2 * | grep fatal this gives a list of messages already used for that function (here G_find_cell2()), then I just reuse the nicest message from that list (prefer "raster map" to "cell file", <%s> brackets around map names, square brackets around values (invalid color [%s]), etc). A centralized list would be a nice idea, but I would modify Brad's macro names, -MSG_* +ERR_MSG_* +WRN_MSG_* (and formalize usage of <> vs [], etc) Brad: > Okay, we now have a standard set of messages, but now locale macros > need to be dealt with. There's a few ways to deal with it, but none > of them seem trivial to me. #define ERRMSG_RASTER_OPEN_FILE _("Unable to find raster map <%s>") #define ERRMSG_RASTER_OPEN_FILE_MAPSET _("Unable to find raster map <%s@%s>") #define ERRMSG_RASTER_WRITE_FILE _("Unable to write to raster map <%s>") ... ? but these should probably live in a .h file, and would #include at the top of that enough to get them translated at run time? (I assume not?) Hamish From hamish_nospam at yahoo.com Mon Dec 11 04:49:36 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 04:49:40 2006 Subject: [GRASS-dev] Re: fprintf in raster modules converted to G_message In-Reply-To: <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> References: <20061207203123.GA6396@localdomain> <2b3d8c1c0612090711t28c11238me6b65924c3397156@mail.gmail.com> Message-ID: <20061211164936.44975314.hamish_nospam@yahoo.com> Maris Nartiss wrote: > last night I was cleaning up GRASS translation and found GRASS error > messages very inconsistent. another point re. rationalized error messages. Sometimes a module uses the same fn call for two different maps, and the error messages are slightly different (e.g. "<%s> base map not found" and "<%s> cover map not found"). In that case it is best to keep the existing (cleaned) error messages. Similar to the use of G_define_option() versus G_define_standard_option(). [but slightly different, with G_define_standard_option() you can follow it with e.g. a single change, e.g. opt->description="text"] Hamish From oliver4grass at gmail.com Mon Dec 11 06:44:36 2006 From: oliver4grass at gmail.com (Vytautas V) Date: Mon Dec 11 06:44:39 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: <20061206093111.GA24258@bartok.itc.it> References: <20061201153951.GF16862@bartok.itc.it> <20061206093111.GA24258@bartok.itc.it> Message-ID: Hi, glad to hear about new r.out.gdal being normally named and included in the Makefile. I also wanted to inform that new r.out.gdal also supports multiband rasters! It is able to export group to multiband raster, if you enter group's name as input (this can be useful when you need to export image from GRASS). But users are not informed about this capability nor GUI informs it. I'm also thinking about adding flag -g to force group, if there is individual raster and group with the same name (r.out.gdal first searches individual raster, if not found - group with a given input name). Vytautas From hamish_nospam at yahoo.com Mon Dec 11 07:45:16 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 07:45:25 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: <20061201153951.GF16862@bartok.itc.it> <20061206093111.GA24258@bartok.itc.it> Message-ID: <20061211194516.6546fa6f.hamish_nospam@yahoo.com> Vytautas V wrote: > I'm also thinking about adding flag -g to force group, if there is > individual raster and group with the same name that is a good idea. > (r.out.gdal first searches individual raster, if not found - group > with a given input name). I'm not sure, maybe input= should be for raster maps only? (pulldown menus, etc) group != raster map (the way a reclass raster map ~= raster map) Hamish From cavallini at faunalia.it Mon Dec 11 09:05:52 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Dec 11 09:05:56 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <20061208082052.GA11461@localdomain> References: <20061208082052.GA11461@localdomain> Message-ID: <457D1160.2030204@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How will this relate to current "q.digit" (v.digit in qgis)? We find it far easier to use than the tcltk version. It would be a pity to miss it in the future development. pc Jachym Cepicky ha scritto: > Hi, > I started Wiki page, which should specify future tool, which would > replace current v.digit module [1]. > > IMHO future v.digit should be based on v.edit module for geometry > operations and db.* modules for database management. Current version of > v.edit supports only two operations: add and delete. In the wiki, I > tryed to define desired behavior of the module, so it would be usable > for real editing of vector data. > > Help with this documentation and with coding welcome! Wolf, initial > author of v.edit, did great job. v.edit has IMHO nice design. Most of > the functions can be adopted from v.in.ascii. > > Please add your notes or completions to Wiki and if you can, drop some > pieces of code to vector/v.edit/* ;-) > > Jachym > > [1] http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfRFg/NedwLUzIr4RAjB2AKCct1jenjpyw2omzZm1uXVk9mLlKQCfT5aB IoIusSqWrdEGpV9qBhLulxA= =Xfoq -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Mon Dec 11 11:15:39 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Dec 11 11:14:23 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <1165756649.21250.121.camel@devel> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <1165756649.21250.121.camel@devel> Message-ID: <457D2FCB.6010000@club.worldonline.be> On 10/12/06 14:17, Brad Douglas wrote: > On Sat, 2006-12-09 at 16:06 +0100, Markus Neteler wrote: >> On Sat, Dec 09, 2006 at 06:26:11AM -0800, Brad Douglas wrote: >>> On Sat, 2006-12-09 at 11:42 +0100, S?ren Gebbert wrote: >>>> Hi Markus, >>>> the lates grass-test-suite results for grass-6.2.1RC1 are available here: >>>> http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/ >>>> >>>> A test for r.to.rast3elev was added. >>>> No errors found. :) >>> I cannot speak highly enough of the test suite. It lends credibility >>> and saves time. >>> >>> Markus, >>> >>> I also built successfully. You may no longer make claims of lacking >>> feedback. :-) >> Excellent! >> Now we only need to receive a quick test of gis.m. > > I spent 5-10 minutes testing gis.m. It appears in working order, but I > only tested basics. Same here: compilation and basic testing of gis.m did not show any problems. Anything special to test particularly ? Moritz From jachym.cepicky at centrum.cz Mon Dec 11 11:21:51 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Dec 11 11:21:56 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <457D1160.2030204@faunalia.it> References: <20061208082052.GA11461@localdomain> <457D1160.2030204@faunalia.it> Message-ID: <20061211102151.GD6934@localdomain> hi, On Mon, Dec 11, 2006 at 09:05:52AM +0100, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > How will this relate to current "q.digit" (v.digit in qgis)? > We find it far easier to use than the tcltk version. > It would be a pity to miss it in the future development. > pc QGIS is using different code for vector editing. Target of new v.digit & v.edit is to get rid of dependancy on X-driver, rather then add new features (in first step). As side effect, GRASS will get new tool for non-interactive vector editing (v.edit). This could enable us, use GRASS as background tool for web-based applications. Jachym > > Jachym Cepicky ha scritto: > > Hi, > > I started Wiki page, which should specify future tool, which would > > replace current v.digit module [1]. > > > > IMHO future v.digit should be based on v.edit module for geometry > > operations and db.* modules for database management. Current version of > > v.edit supports only two operations: add and delete. In the wiki, I > > tryed to define desired behavior of the module, so it would be usable > > for real editing of vector data. > > > > Help with this documentation and with coding welcome! Wolf, initial > > author of v.edit, did great job. v.edit has IMHO nice design. Most of > > the functions can be adopted from v.in.ascii. > > > > Please add your notes or completions to Wiki and if you can, drop some > > pieces of code to vector/v.edit/* ;-) > > > > Jachym > > > > [1] http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > - -- > Paolo Cavallini > email+jabber: cavallini@faunalia.it > www.faunalia.it > Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFfRFg/NedwLUzIr4RAjB2AKCct1jenjpyw2omzZm1uXVk9mLlKQCfT5aB > IoIusSqWrdEGpV9qBhLulxA= > =Xfoq > -----END PGP SIGNATURE----- -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061211/891d6915/attachment.bin From hamish_nospam at yahoo.com Mon Dec 11 11:40:02 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 11:40:06 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061209150628.GA27879@bartok.itc.it> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> Message-ID: <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> > Now we only need to receive a quick test of gis.m. Hi, * 6.2.1rc1 built cleanly on Debian/Stable ia32. * "GRASS_WISH=wish8.3 gis.m" works fine (light testing); georectifier works; non-GUI r.digit/r.support work from the menu. * gis.m fails with a nice message if g.region or libgdal is missing. - not familiar enough with Zooming issues to test that. * ps.map + "paper a4" works. * v.db.select where= works. - r.to.rast3elev added to menu.tcl in 6.2-cvs (+ in 6.3-cvs, where there are now THREE (3) menu.tcls to sync. PITA.) * d.histogram in a frame works. * i.group seems to work. * `nviz vol=` gives a warning that it won't work Hamish From hamish_nospam at yahoo.com Mon Dec 11 12:15:38 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 12:15:49 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <20061211102151.GD6934@localdomain> References: <20061208082052.GA11461@localdomain> <457D1160.2030204@faunalia.it> <20061211102151.GD6934@localdomain> Message-ID: <20061212001538.7f0b49bc.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > I started Wiki page, which should specify future tool, which would > replace current v.digit module [1]. .. > http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool IMO all new GUI work should be done using wxPython. Hamish From hamish_nospam at yahoo.com Mon Dec 11 12:19:05 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Dec 11 12:19:30 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <20061211102151.GD6934@localdomain> References: <20061208082052.GA11461@localdomain> <457D1160.2030204@faunalia.it> <20061211102151.GD6934@localdomain> Message-ID: <20061212001905.088f0644.hamish_nospam@yahoo.com> > > How will this relate to current "q.digit" (v.digit in qgis)? > > We find it far easier to use than the tcltk version. > > It would be a pity to miss it in the future development. by all means reuse their design ideas and format if you like. but we do ned our own digitizer unless we are deciding to make qgis our primary GUI. The r.in.poly format is very close the ascii vector format, so it shouldn't be hard to build in a r.digit replacement as an export option. Hamish From cavallini at faunalia.it Mon Dec 11 12:54:10 2006 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Dec 11 12:54:13 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <20061212001905.088f0644.hamish_nospam@yahoo.com> References: <20061208082052.GA11461@localdomain> <457D1160.2030204@faunalia.it> <20061211102151.GD6934@localdomain> <20061212001905.088f0644.hamish_nospam@yahoo.com> Message-ID: <457D46E2.2000300@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hamish ha scritto: > by all means reuse their design ideas and format if you like. but we do ^^^^^ > ned our own digitizer unless we are deciding to make qgis our primary ^^^^^^^ I do not see the two project as so separated, and I think it is unfortunate influential grass developers do (but of course, this is not to blame anyone, just my point of view). pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfUbi/NedwLUzIr4RAn/dAJwOexer2eSyheOl2ef6mjmEVnxjnQCeKhSn R5PoWlzoe8nWQ1tmWYF8bxU= =gm+8 -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Mon Dec 11 13:38:29 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Dec 11 13:37:14 2006 Subject: [GRASS-dev] v.digit and v.edit wiki discussion In-Reply-To: <457D46E2.2000300@faunalia.it> References: <20061208082052.GA11461@localdomain> <457D1160.2030204@faunalia.it> <20061211102151.GD6934@localdomain> <20061212001905.088f0644.hamish_nospam@yahoo.com> <457D46E2.2000300@faunalia.it> Message-ID: <457D5145.7060102@club.worldonline.be> On 11/12/06 12:54, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Hamish ha scritto: > > by all means reuse their design ideas and format if you like. but we do > ^^^^^ >> ned our own digitizer unless we are deciding to make qgis our primary > ^^^^^^^ > > I do not see the two project as so separated, and I think it is > unfortunate influential grass developers do (but of course, this is not > to blame anyone, just my point of view). They are two seperate projects, with a bridge between the two built by Radim. I think we have had this discussion before and came to the conclusion that GRASS needs its own GUI independently from QGIS. In my opinion QGIS is a great piece of software with much potential, but for my use I don't see any added value of using it instead of a much more lightweight internal GUI. Moritz From bcovill at tekmap.ns.ca Mon Dec 11 15:12:20 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Mon Dec 11 15:12:49 2006 Subject: [GRASS-dev] NVIZ startup Message-ID: <1165846340.10249.13.camel@linuxmain.localhost> Hello, I have updated NVIZ so that it is now started via a script (still called nviz). This update should improve the TCL error catching of NVIZ. TCL errors should now be printed to stderr. The previous version would hang or dump the user out without any indication of the TCL error causing the problem. The un-installed script can be found in nviz/scripts. Please check it out and see if any improvements can be made. This update also includes modifications to the nviz Makefile. The script is currently being installed in $GISBASE/bin, but it should probably be installed in $GISBASE/scripts. Unfortunately I do not know how to remove the old nviz in $GISBASE/bin before installing the script in $GISBASE/scripts. There is also a couple lines in Makefile to handle moving the binary nvwish to $GISBASE/etc/nviz2.2/. Please check this section to ensure that is is correct (particularly Windows developers). -- Bob From mlennert at club.worldonline.be Mon Dec 11 16:18:05 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Dec 11 16:16:50 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> Message-ID: <457D76AD.3050407@club.worldonline.be> Hello Paul, (cc'ing this to the list, so that Paul is not alone...) On 09/12/06 15:56, Paul Kelly wrote: > Hello Moritz > > On Fri, 8 Dec 2006, Moritz Lennert wrote: > >> Hello Paul, >> >> I'm finally sitting in front of a Windows computer trying to compile >> GRASS >> myself. >> >> On Thu, November 23, 2006 12:38, Paul Kelly wrote: >>> >>> I had a look at that site; certainly lots of useful information on >>> building there. E.g. I don't expect they will have the stripped-down XDR >>> or GDAL or PROJ, and they were the biggest challenges to build properly >>> anyway. >> >> At this stage I just used ./configure;make;make install, just to see >> whether everything seems to work. >> I imagine I will need to do some more tweaking, would happen to have >> recorded your configure settings somewhere ? > > For the other software, no net yet. Some of it I think I just used the > Makefiles as the configure script wasn't working on Windows. But I > intend to re-build it all from scratch very soon and will take proper > notes then. I've tried to build GRASS having just compiled the other libraries with configure&make&make install. I get the following error: c:/Moritz/gdal-cvs-2006.12.07/libgdal.la: file not recognized: File format not recognized collect2: ld returned 1 exit status make[2]: *** [/c/moritz/grass6/dist.i686-pc-mingw32/lib/libgrass_gproj.6.3.cvs.dll] Error 1 and c:/Moritz/gdal-cvs-2006.12.07/libgdal.la: file not recognized: File format not recognized collect2: ld returned 1 exit status make[3]: *** [/c/moritz/grass6/dist.i686-pc-mingw32/lib/libgrass_vect.6.3.cvs.dll] Error 1 which then obviously leads to many errors afterwards. I have attached the entire make log and the libgdal.la file. Any ideas of what is wrong with the .la file ? Also, I've seen some debate on cross-compiling lately. If this is reasonably easy, it would make life easier for me as I would not have to wait for my colleague's windows machine to be free... Moritz -------------- next part -------------- # libgdal.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.2 (1.1220.2.60 2004/01/25 12:25:08) Debian: 192 $ # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='../bin/libgdal-1.dll' # Names of this library. library_names='libgdal.dll.a' # The name of the static archive. old_library='libgdal.a' # Libraries that this one depends upon. dependency_libs=' -lpng -lz' # Version information for libgdal. current=12 age=11 revision=0 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/local/lib' -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log.gz Type: application/x-gzip Size: 64989 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061211/40d5425b/make.log-0001.gz From paul-grass at stjohnspoint.co.uk Mon Dec 11 16:19:39 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Dec 11 16:19:42 2006 Subject: [GRASS-dev] NVIZ startup In-Reply-To: <1165846340.10249.13.camel@linuxmain.localhost> References: <1165846340.10249.13.camel@linuxmain.localhost> Message-ID: Hello Bob I don't have time to look in detail at a better way of doing this for now but just to point out that it won't work on Native Windows GRASS for 3 reasons (indeed I can confirm that the "start NVIZ with these display settings" button in gis.m now reports that it can't find nviz....): 1. It needs a shell script interpreter (e.g. Msys) - I'm trying to get WinGRASS so that as much of it as possible runs without shell scripting availability. Nviz was included in that up to now. 2. The Msys exec command uses Msys paths (i.e. starting like /c/grass/grass6) while $GISBASE will be a Windows-style path with forward slashes (i.e. like c:/grass/grass6) and Msys will try and interpret this as relevant to its installation directory, and fail. 3. To run scripts at all from gis.m they need to have a .bat, .com or .exe ending (this is a bug/feature in Tcl). If you use the proper "script" Makefile rule to install the script in the scripts directory then it will also create a .bat wrapper script in the bin directory to call the original script using the user's preferred interpreter (most likely Msys bash), but this isn't happening here. Yes the gis.m startup script doesn't work either but it only needs to be called once at the start and I have instead been starting gm.tcl directly from a Windows batch file. An idea I did have though, was to allow each script directory to, if contributed, have both bourne shell and Windows batch versions. If the batch version was there it would then get installed on Windows in preference to creating a batch wrapper script that invoked the bourne shell interpreter on the original script (as at present). But there's a lot of issues there and as I said am a wee bit too busy to get stuck into any of them right now. Paul On Mon, 11 Dec 2006, Bob Covill wrote: > Hello, > > I have updated NVIZ so that it is now started via a script (still called > nviz). This update should improve the TCL error catching of NVIZ. TCL > errors should now be printed to stderr. The previous version would hang > or dump the user out without any indication of the TCL error causing the > problem. > > The un-installed script can be found in nviz/scripts. Please check it > out and see if any improvements can be made. > > This update also includes modifications to the nviz Makefile. The script > is currently being installed in $GISBASE/bin, but it should probably be > installed in $GISBASE/scripts. Unfortunately I do not know how to remove > the old nviz in $GISBASE/bin before installing the script in > $GISBASE/scripts. There is also a couple lines in Makefile to handle > moving the binary nvwish to $GISBASE/etc/nviz2.2/. Please check this > section to ensure that is is correct (particularly Windows developers). You can put $(EXE) at the end of an executable file name in a GRASS Makefile. It will be empty on Unix and contain ".exe" on Windows. You are better using $(INSTALL) here as well instead of mv I think. > > -- > Bob > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From paul-grass at stjohnspoint.co.uk Mon Dec 11 16:24:02 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Dec 11 16:24:05 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <457D76AD.3050407@club.worldonline.be> References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> Message-ID: Hello Moritz I know I got this working but to be honest I'm not completely sure how. I've made a start on re-doing everything from scratch and making proper notes now that I know it's possible. I would say you could try configuring GDAL --without-libtool perhaps. Also some very promising looking hints and tips on libtool on here: http://gnuwin32.sourceforge.net/compile.html Paul On Mon, 11 Dec 2006, Moritz Lennert wrote: > Hello Paul, > (cc'ing this to the list, so that Paul is not alone...) > > On 09/12/06 15:56, Paul Kelly wrote: >> Hello Moritz >> >> On Fri, 8 Dec 2006, Moritz Lennert wrote: >> >>> Hello Paul, >>> >>> I'm finally sitting in front of a Windows computer trying to compile GRASS >>> myself. >>> >>> On Thu, November 23, 2006 12:38, Paul Kelly wrote: >>>> >>>> I had a look at that site; certainly lots of useful information on >>>> building there. E.g. I don't expect they will have the stripped-down XDR >>>> or GDAL or PROJ, and they were the biggest challenges to build properly >>>> anyway. >>> >>> At this stage I just used ./configure;make;make install, just to see >>> whether everything seems to work. >>> I imagine I will need to do some more tweaking, would happen to have >>> recorded your configure settings somewhere ? >> >> For the other software, no net yet. Some of it I think I just used the >> Makefiles as the configure script wasn't working on Windows. But I intend >> to re-build it all from scratch very soon and will take proper notes then. > > I've tried to build GRASS having just compiled the other libraries with > configure&make&make install. > > I get the following error: > > c:/Moritz/gdal-cvs-2006.12.07/libgdal.la: file not recognized: File format > not recognized > collect2: ld returned 1 exit status > make[2]: *** > [/c/moritz/grass6/dist.i686-pc-mingw32/lib/libgrass_gproj.6.3.cvs.dll] Error > 1 > > and > > c:/Moritz/gdal-cvs-2006.12.07/libgdal.la: file not recognized: File format > not recognized > collect2: ld returned 1 exit status > make[3]: *** > [/c/moritz/grass6/dist.i686-pc-mingw32/lib/libgrass_vect.6.3.cvs.dll] Error 1 > > which then obviously leads to many errors afterwards. > > I have attached the entire make log and the libgdal.la file. > > Any ideas of what is wrong with the .la file ? > > Also, I've seen some debate on cross-compiling lately. If this is reasonably > easy, it would make life easier for me as I would not have to wait for my > colleague's windows machine to be free... > > Moritz > From smitch at mac.com Mon Dec 11 16:45:41 2006 From: smitch at mac.com (Scott Mitchell) Date: Mon Dec 11 16:45:50 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061208161647.GC19448@bartok.itc.it> References: <20061206213647.GA28175@bartok.itc.it> <20061207173914.613a1631.hamish_nospam@yahoo.com> <20061208161647.GC19448@bartok.itc.it> Message-ID: On 8 Dec 2006, at 08:16, Markus Neteler wrote: > But so far we had zero feedback if 6.2.1RC1 works. > Especially the gis.m needs a test. I am travelling, making detailed testing awkward, but so far: - on MacOS X 10.4.8 (Intel): - built cleanly - gis.m starts up fine, displays raster and vector maps as expected, quick test of thematic maps fine, legends find, sketchy random tests of running miscellaneous modules fine, random help links OK too - nviz passes light testing - on MacOSX Server 10.4.8 (PPC): - builds fine - no further testing yet - on Fedora Core 5 (Intel): - builds fine, gis.m starts up fine, but slow speed of connection between hotel and lab preventing proper testing of GUI stuff - on Debian (stable) (Intel): - still building (old, slow machine) I could do more targeted testing on the machine I have with me tonight/tomorrow, but as a mostly command line user, hints as to what is most useful to test in gis.m would help. Scott From mlennert at club.worldonline.be Mon Dec 11 16:49:13 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Dec 11 16:47:57 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> Message-ID: <457D7DF9.9050804@club.worldonline.be> On 11/12/06 16:24, Paul Kelly wrote: > Hello Moritz > I know I got this working but to be honest I'm not completely sure how. > I've made a start on re-doing everything from scratch and making proper > notes now that I know it's possible. > > I would say you could try configuring GDAL --without-libtool perhaps. > Also some very promising looking hints and tips on libtool on here: > http://gnuwin32.sourceforge.net/compile.html Yes, I read this, especially the section on dynamic libraries, but I have the feeling that most of what they recommend is already present, i.e. .dll files and the mention of libfoo.dll.a in the .la file... Maybe it's a question of the libtool version... Moritz From jachym.cepicky at centrum.cz Mon Dec 11 18:53:57 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Dec 11 18:54:02 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061207163000.GA28829@localdomain> References: <20061207163000.GA28829@localdomain> Message-ID: <20061211175357.GA24372@localdomain> hi, since nobody really complained, I commited the patch. v.to.db has new option "slope" now jachym On Thu, Dec 07, 2006 at 05:30:00PM +0100, Jachym Cepicky wrote: > Hallo, > somebody asked on IRC, how to calculate slopes for vector lines. > > This patch should add new option "slope" to v.to.db module and calculate slope steepness > for each vector line > > What do you think, shall I commit this patch to cvs? > > Jachym > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > ----------------------------------------- > OFFICE: > Department of Geoinformation Technologies > Zemedelska 3 > 613 00, Brno > Czech Republick > e-mail: xcepicky@node.mendelu.cz > URL: http://mapserver.mendelu.cz > Tel.: +420 545 134 514 > Index: vector/v.to.db/global.h > =================================================================== > RCS file: /grassrepository/grass6/vector/v.to.db/global.h,v > retrieving revision 1.8 > diff -u -r1.8 global.h > --- vector/v.to.db/global.h 9 Feb 2006 03:09:07 -0000 1.8 > +++ vector/v.to.db/global.h 7 Dec 2006 16:21:18 -0000 > @@ -13,7 +13,7 @@ > /* for sides set to 2, if more than 1 area category was found, */ > /* including no category (cat = -1)! */ > int i1,i2; /* values; i1: query (result int), sides; i2: sides */ > - double d1,d2,d3; /* values (length, area, x/y/z, query) */ > + double d1,d2,d3,d4; /* values (length, area, x/y/z, query, slope) */ > char *str1; /* string value (query) */ > int *qcat; /* array query categories */ > int nqcats; /* number of query cats */ > @@ -65,6 +65,8 @@ > > #define O_START 10 /* line/boundary starting point */ > #define O_END 11 /* line/boundary end point */ > + > +#define O_SLOPE 12 /* Line slope */ > > #define U_ACRES 1 > #define U_HECTARES 2 > Index: vector/v.to.db/lines.c > =================================================================== > RCS file: /grassrepository/grass6/vector/v.to.db/lines.c,v > retrieving revision 1.8 > diff -u -r1.8 lines.c > --- vector/v.to.db/lines.c 9 Feb 2006 03:09:07 -0000 1.8 > +++ vector/v.to.db/lines.c 7 Dec 2006 16:21:18 -0000 > @@ -48,7 +48,7 @@ > > /* > * Read: - points/centroids : cat,count,coor > - * - lines/boundaries : cat,count,length > + * - lines/boundaries : cat,count,length,slope > */ > > int > @@ -58,7 +58,7 @@ > register int line_num; > struct line_pnts *Points; > struct line_cats *Cats, *LCats, *RCats; > - double len; > + double len,slope; > > /* Initialize the Point struct */ > Points = Vect_new_line_struct(); > @@ -137,7 +137,13 @@ > > read_side_cats ( LCats, &(Values[idx].i1), &(Values[idx].count1) ); > read_side_cats ( RCats, &(Values[idx].i2), &(Values[idx].count2) ); > + } else if ( options.option == O_SLOPE && (type & GV_LINES) ) { > + /* Calculate line slope */ > + len = length (Points->n_points, Points->x, Points->y); > + slope = (Points->z[Points->n_points-1] - Points->z[0])/len; > + Values[idx].d1 += slope; > } > + > found = 1; > } > } > @@ -167,7 +173,13 @@ > } else if ( options.option == O_SIDES && type == GV_BOUNDARY ) { > read_side_cats ( LCats, &(Values[idx].i1), &(Values[idx].count1) ); > read_side_cats ( RCats, &(Values[idx].i2), &(Values[idx].count2) ); > - } > + } else if ( options.option == O_SLOPE && (type & GV_LINES) ) { > + /* Calculate line slope */ > + len = length (Points->n_points, Points->x, Points->y); > + slope = (Points->z[Points->n_points-1] - Points->z[0])/len; > + Values[idx].d1 += slope; > + } > + > } > } > > Index: vector/v.to.db/parse.c > =================================================================== > RCS file: /grassrepository/grass6/vector/v.to.db/parse.c,v > retrieving revision 1.19 > diff -u -r1.19 parse.c > --- vector/v.to.db/parse.c 21 Sep 2006 12:50:39 -0000 1.19 > +++ vector/v.to.db/parse.c 7 Dec 2006 16:21:18 -0000 > @@ -48,7 +48,7 @@ > parms.option->type = TYPE_STRING; > parms.option->required = YES; > parms.option->multiple = NO; > - parms.option->options = "cat,area,compact,perimeter,length,count,coor,start,end,sides,query"; > + parms.option->options = "cat,area,compact,perimeter,length,count,coor,start,end,sides,query,slope"; > parms.option->description = _("Value to upload"); > parms.option->descriptions = > "cat;insert new row for each category if doesn't exist yet;" > @@ -64,7 +64,8 @@ > "sides;categories of areas on the left and right side of the boundary, " > "'qlayer' is used for area category;" > "query;result of a database query for all records of the geometry" > - "(or geometries) from table specified by 'qlayer' option"; > + "(or geometries) from table specified by 'qlayer' option;" > + "slope;slope steepness of vector line or boundary"; > > parms.units = G_define_option(); > parms.units->key = "units"; > @@ -100,7 +101,7 @@ > > flags.t = G_define_flag(); > flags.t->key = 'c'; > - flags.t->description = _("In print mode prints totals for options: length,area,count"); > + flags.t->description = _("In print mode prints totals for options: length,area"); > > if (G_parser(argc,argv)) exit(EXIT_FAILURE); > > @@ -132,7 +133,7 @@ > } > > if ( options.option == O_AREA || options.option == O_LENGTH || options.option == O_COUNT > - || options.option == O_QUERY || options.option == O_COMPACT || options.option == O_PERIMETER) /* one column required */ > + || options.option == O_QUERY || options.option == O_COMPACT || options.option == O_PERIMETER || options.option == O_SLOPE ) /* one column required */ > { > if ( ncols != 1 ) { > G_fatal_error ( _("This option requires one column") ); > @@ -187,6 +188,7 @@ > else if (strcmp (s, "query") == 0) x = O_QUERY; > else if (strcmp (s, "compact") == 0) x = O_COMPACT; > else if (strcmp (s, "perimeter") == 0) x = O_PERIMETER; > + else if (strcmp (s, "slope") == 0) x = O_SLOPE; > > return x; > } > Index: vector/v.to.db/report.c > =================================================================== > RCS file: /grassrepository/grass6/vector/v.to.db/report.c,v > retrieving revision 1.11 > diff -u -r1.11 report.c > --- vector/v.to.db/report.c 9 Feb 2006 03:09:07 -0000 1.11 > +++ vector/v.to.db/report.c 7 Dec 2006 16:21:18 -0000 > @@ -66,6 +66,13 @@ > for ( i = 0; i < vstat.rcat; i++ ) > fprintf (stdout, "%d|%.15g\n", Values[i].cat, Values[i].d1); > } > + break; > + case O_SLOPE: > + fprintf (stdout,"cat|slope\n"); > + for ( i = 0; i < vstat.rcat; i++ ) > + fprintf (stdout, "%d|%.15g\n", Values[i].cat, Values[i].d1); > + > + > break; > > case O_COOR: > Index: vector/v.to.db/update.c > =================================================================== > RCS file: /grassrepository/grass6/vector/v.to.db/update.c,v > retrieving revision 1.17 > diff -u -r1.17 update.c > --- vector/v.to.db/update.c 9 Feb 2006 03:09:07 -0000 1.17 > +++ vector/v.to.db/update.c 7 Dec 2006 16:21:18 -0000 > @@ -49,6 +49,7 @@ > case O_QUERY: > case O_COMPACT: > case O_PERIMETER: > + case O_SLOPE: > sprintf (buf1, "update %s set %s =", Fi->table, options.col[0]); > break; > case O_COOR: > @@ -79,6 +80,7 @@ > case O_AREA: > case O_COMPACT: > case O_PERIMETER: > + case O_SLOPE: > sprintf (buf2, "%s %f where %s = %d", buf1, Values[i].d1, Fi->key, Values[i].cat); > break; > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061211/d1db5b78/attachment.bin From neteler at itc.it Mon Dec 11 18:58:36 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Dec 11 18:58:38 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211175357.GA24372@localdomain> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> Message-ID: <20061211175836.GF5184@bartok.itc.it> On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > hi, > > since nobody really complained, I commited the patch. v.to.db has new > option "slope" now hi jachym, does it now work for LatLong? I guess I overlooked some email. Markus From tutey at o2.pl Mon Dec 11 19:02:14 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Dec 11 19:02:20 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> Message-ID: <457D9D26.9030708@o2.pl> Hamish wrote: > * gis.m fails with a nice message if g.region or libgdal is missing. > > - not familiar enough with Zooming issues to test that. One bug remainning in gis.m AFAIK is that in the constrained zoom mode the region aspect ratio is not preserved during single-click zoom in/out (and the aspect ratio must be preserved, because it is the *constrained zoom mode*). Other zooming issues I used to complain about seem to have been fixed by Michael. Great. > * `nviz vol=` gives a warning that it won't work There is still a bug in NVIZ, that usually after adding a vector point layer, removing it, and adding a new one, artifacts are displayed, including: 1. different icons then the chosen one, for some points 2. some points are displayed with random colors, not the one specified 3. line artifact happen to pop up See the attached screendump (spearfish: elevation.10m + archsites) and latest remarks in the http://intevation.de/rt/webrt?serial_num=4492. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: archsites.jpg Type: image/jpeg Size: 26921 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061211/30f49332/archsites-0001.jpg From jachym.cepicky at centrum.cz Mon Dec 11 19:05:01 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Dec 11 19:05:05 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211175836.GF5184@bartok.itc.it> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> Message-ID: <20061211180501.GA25251@localdomain> hi Markus, On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: > On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > > hi, > > > > since nobody really complained, I commited the patch. v.to.db has new > > option "slope" now > > hi jachym, > > does it now work for LatLong? I guess I overlooked some email. > > Markus > yes, I was writing about this: no, it does not :-( it does not even work with option=length, because of Vect_cidx_get_num_unique_cats_by_index ( &Map, Vect_cidx_get_field_index(&Map, options.field ) ); in main.c returns 1634887471 of unique cats by index and v.to.db ends up with G_calloc error: could not allocat memory. I have no clue, how to fix this bug. Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061211/62f0ea8f/attachment.bin From paul-grass at stjohnspoint.co.uk Mon Dec 11 20:01:21 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Dec 11 20:01:28 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211180501.GA25251@localdomain> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> Message-ID: Hello Jachym Just a little comment below: On Mon, 11 Dec 2006, Jachym Cepicky wrote: > On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: >> On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: >>> hi, >>> >>> since nobody really complained, I commited the patch. v.to.db has new >>> option "slope" now >> >> hi jachym, >> >> does it now work for LatLong? I guess I overlooked some email. >> [...] > no, it does not :-( it does not even work with option=length, because of > > > Vect_cidx_get_num_unique_cats_by_index ( &Map, > Vect_cidx_get_field_index(&Map, options.field ) ); > > in main.c returns 1634887471 of unique cats by index and v.to.db ends up > with G_calloc error: could not allocat memory. > > I have no clue, how to fix this bug. I (maybe others) interpreted this as you admitting that the patch was not yet ready/good enough to commit to CVS! So maybe that's why nobody complained - Is it true that wrong results will be given in a lat/long location with no warning? If so, then something should be changed. If not, and I've misunderstood, then it's all OK! Paul From michael.barton at asu.edu Mon Dec 11 20:48:49 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Dec 11 20:50:21 2006 Subject: [GRASS-dev] NVIZ startup In-Reply-To: <1165846340.10249.13.camel@linuxmain.localhost> Message-ID: Given Paul Kelly's reply, we might want to revert this until the Windows issues are sorted out. Thanks for trying to help with debugging though. Michael On 12/11/06 7:12 AM, "Bob Covill" wrote: > Hello, > > I have updated NVIZ so that it is now started via a script (still called > nviz). This update should improve the TCL error catching of NVIZ. TCL > errors should now be printed to stderr. The previous version would hang > or dump the user out without any indication of the TCL error causing the > problem. > > The un-installed script can be found in nviz/scripts. Please check it > out and see if any improvements can be made. > > This update also includes modifications to the nviz Makefile. The script > is currently being installed in $GISBASE/bin, but it should probably be > installed in $GISBASE/scripts. Unfortunately I do not know how to remove > the old nviz in $GISBASE/bin before installing the script in > $GISBASE/scripts. There is also a couple lines in Makefile to handle > moving the binary nvwish to $GISBASE/etc/nviz2.2/. Please check this > section to ensure that is is correct (particularly Windows developers). > > -- > Bob > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Mon Dec 11 21:30:46 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Dec 11 21:30:48 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: <20061211194516.6546fa6f.hamish_nospam@yahoo.com> References: <20061201153951.GF16862@bartok.itc.it> <20061206093111.GA24258@bartok.itc.it> <20061211194516.6546fa6f.hamish_nospam@yahoo.com> Message-ID: On Mon, 11 Dec 2006, Hamish wrote: > Vytautas V wrote: >> I'm also thinking about adding flag -g to force group, if there is >> individual raster and group with the same name > > that is a good idea. > >> (r.out.gdal first searches individual raster, if not found - group >> with a given input name). > > I'm not sure, maybe input= should be for raster maps only? (pulldown menus, etc) > > group != raster map (the way a reclass raster map ~= raster map) Yes, while in a way kind of neat the way it currently is, I think the most elegant way to handle this would be to have two separate input parameters: "input" for a raster map and "group" for an imagery group. And some sanity checks could be included in the module to exit with an error if both were specified by accident. Paul From neteler at itc.it Mon Dec 11 21:34:02 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Dec 11 21:34:04 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211180501.GA25251@localdomain> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> Message-ID: <20061211203402.GA13499@bartok.itc.it> On Mon, Dec 11, 2006 at 07:05:01PM +0100, Jachym Cepicky wrote: > hi Markus, > > > On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: > > On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > > > hi, > > > > > > since nobody really complained, I commited the patch. v.to.db has new > > > option "slope" now > > > > hi jachym, > > > > does it now work for LatLong? I guess I overlooked some email. > > > > Markus > > > > yes, I was writing about this: > > no, it does not :-( it does not even work with option=length, because of > > > Vect_cidx_get_num_unique_cats_by_index ( &Map, > Vect_cidx_get_field_index(&Map, options.field ) ); > > in main.c returns 1634887471 of unique cats by index and v.to.db ends up > with G_calloc error: could not allocat memory. > > I have no clue, how to fix this bug. Hi Jachym, I don't think that we should knowingly introduce bugs in GRASS. It would be good to get that resolved soon. As Paul said - I also assumed that you would consider the patch as non-ready, so I didn't further comment. Best, Markus From neteler at itc.it Mon Dec 11 21:40:42 2006 From: neteler at itc.it (Markus Neteler) Date: Mon Dec 11 21:40:44 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211203402.GA13499@bartok.itc.it> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> <20061211203402.GA13499@bartok.itc.it> Message-ID: <20061211204042.GB13499@bartok.itc.it> On Mon, Dec 11, 2006 at 09:34:02PM +0100, Markus Neteler wrote: > On Mon, Dec 11, 2006 at 07:05:01PM +0100, Jachym Cepicky wrote: > > On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: > > > On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > > > > since nobody really complained, I commited the patch. v.to.db has new > > > > option "slope" now > > > > > > does it now work for LatLong? I guess I overlooked some email. > > > > > yes, I was writing about this: > > > > no, it does not :-( it does not even work with option=length, because of In fact it works with length: GRASS 6.3.cvs (latlong):~ > v.to.db -p polbnda_italy_state op=length un=k col=dummy type=boundary cat|length -1|8630.5217187381 1|0 2 categories read from map 0 records selected from table 0 categories read from map exist in selection from table 0 categories read from map don't exist in selection from table 0 records updated/inserted 0 update/insert errors We fixed that one year ago: 2005-11-30 16:26 markus * areas.c, description.html: Wolf Bergenheim: use geodetic length for perimeter in LatLong; prettified areas.c with indent to verify exactly the coastline length for Italy which is given incorrectly in the ASPRS Grid & datums paper on Italy. Markus > > > > > > Vect_cidx_get_num_unique_cats_by_index ( &Map, > > Vect_cidx_get_field_index(&Map, options.field ) ); > > > > in main.c returns 1634887471 of unique cats by index and v.to.db ends up > > with G_calloc error: could not allocat memory. > > > > I have no clue, how to fix this bug. > > Hi Jachym, > > I don't think that we should knowingly introduce bugs in > GRASS. It would be good to get that resolved soon. > As Paul said - I also assumed that you would consider the > patch as non-ready, so I didn't further comment. > > Best, > Markus From michael.barton at asu.edu Mon Dec 11 23:20:54 2006 From: michael.barton at asu.edu (Michael Barton) Date: Mon Dec 11 23:21:02 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061211142430.45dd944a.hamish_nospam@yahoo.com> Message-ID: I just added widgets to set the north arrow text color and size. The text color doesn't work on my Mac and there is nothing to set the text size. However, if the layout work OK for you folks, then we can use this to test fixing the text color. It seems like a good idea to be able to set the text size too. Is there a variable/command to do this? If all is OK, I can add exactly the same thing to the new scale panel. Michael On 12/10/06 6:24 PM, "Hamish" wrote: > is it possible to have the "Place Arrow" button change the mouse cursor > to crosshairs when in the the nviz canvas? > > I have been thinking about making a polygon "N" for the north arrow, > that would get around text placement & color issues. (below arrow, same > width, same color) > > Text placement & color issues would still remain for the scalebar of > course. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Dec 12 00:54:48 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 12 00:55:00 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <457D9D26.9030708@o2.pl> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> <457D9D26.9030708@o2.pl> Message-ID: <20061212125448.34d821e0.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > Hamish wrote: > > - not familiar enough with Zooming issues to test that. > > One bug remainning in gis.m AFAIK is that in the constrained zoom mode > the region aspect ratio is not preserved during single-click zoom > in/out (and the aspect ratio must be preserved, because it is the > *constrained zoom mode*). > > Other zooming issues I used to complain about seem to have been fixed > by Michael. Great. > > > * `nviz vol=` gives a warning that it won't work > > There is still a bug in NVIZ, that usually after adding a vector point > layer, removing it, and adding a new one, artifacts are displayed, > including: > > 1. different icons then the chosen one, for some points > 2. some points are displayed with random colors, not the one specified > 3. line artifact happen to pop up > > See the attached screendump (spearfish: elevation.10m + archsites) and > latest remarks in the http://intevation.de/rt/webrt?serial_num=4492. do both of these issues exist in 6.2 and 6.3, or have they been fixed in 6.3 but not backported? Hamish From hamish_nospam at yahoo.com Tue Dec 12 01:27:15 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 12 01:27:31 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> Message-ID: <20061212132715.6979edbb.hamish_nospam@yahoo.com> > >> does it now work for LatLong? I guess I overlooked some email. > >> > [...] > > no, it does not :-( it does not even work with option=length, > > because of > > > > Vect_cidx_get_num_unique_cats_by_index ( &Map, > > Vect_cidx_get_field_index(&Map, options.field ) ); > > > > in main.c returns 1634887471 of unique cats by index and v.to.db > > ends up with G_calloc error: could not allocat memory. > > > > I have no clue, how to fix this bug. Paul: > I (maybe others) interpreted this as you admitting that the patch was > not yet ready/good enough to commit to CVS! So maybe that's why > nobody complained - Is it true that wrong results will be given in a > lat/long location with no warning? If so, then something should be > changed. If not, and I've misunderstood, then it's all OK! a simple if ((G_projection() == PROJECTION_LL)) G_fatal_error("slope option not supported for lat/lon locations"); could allow the patch to go in without introducing bugs. Of course we should try and fix the bug instead of coding around it, and now is the time to do that. Hamish From hamish_nospam at yahoo.com Tue Dec 12 01:40:18 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Dec 12 01:40:27 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211204042.GB13499@bartok.itc.it> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> <20061211203402.GA13499@bartok.itc.it> <20061211204042.GB13499@bartok.itc.it> Message-ID: <20061212134018.18e4beaf.hamish_nospam@yahoo.com> Markus Neteler wrote: > to verify exactly the coastline length for Italy which is given > incorrectly in the ASPRS Grid & datums paper on Italy. to be pedantic: coastline length is a classic fractal problem with no real answer. the best you can do is assume the dataset was digitized with the same fractal depth throughout (and that's a bad assumption) and then compare relative sections of the vector as a ratio. "The empirical evidence suggests a rule which, if extrapolated, shows that the measured length increases without limit as the measurement scale decreases towards zero." http://en.wikipedia.org/wiki/How_Long_Is_the_Coast_of_Britain%3F_Statistical_Self-Similarity_and_Fractional_Dimension or did you get different answers from the same dataset, reprojected? Hamish From hmitaso at unity.ncsu.edu Tue Dec 12 01:41:50 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Dec 12 01:41:55 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061212125448.34d821e0.hamish_nospam@yahoo.com> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> <457D9D26.9030708@o2.pl> <20061212125448.34d821e0.hamish_nospam@yahoo.com> Message-ID: On Dec 11, 2006, at 6:54 PM, Hamish wrote: > Maciej Sieczka wrote: >> Hamish wrote: >>> - not familiar enough with Zooming issues to test that. >> >> One bug remainning in gis.m AFAIK is that in the constrained zoom >> mode >> the region aspect ratio is not preserved during single-click zoom >> in/out (and the aspect ratio must be preserved, because it is the >> *constrained zoom mode*). >> >> Other zooming issues I used to complain about seem to have been fixed >> by Michael. Great. >> >>> * `nviz vol=` gives a warning that it won't work >> >> There is still a bug in NVIZ, that usually after adding a vector >> point >> layer, removing it, and adding a new one, artifacts are displayed, >> including: >> >> 1. different icons then the chosen one, for some points >> 2. some points are displayed with random colors, not the one >> specified >> 3. line artifact happen to pop up >> >> See the attached screendump (spearfish: elevation.10m + archsites) >> and >> latest remarks in the http://intevation.de/rt/webrt?serial_num=4492. > > > do both of these issues exist in 6.2 and 6.3, or have they been > fixed in > 6.3 but not backported? I did not test it with spearfish, but I can confirm that there is a problem still in 6.3 My problem was not the same - icons, colors worked fine, but when I chose x as a symbol all points were displayed under the surface, using other symbols they were draped properly: here is the image of what I tested it with (I sneak preview of the new data set we plan to replace the spearfish with) http://skagit.meas.ncsu.edu/~helena/grasswork/grassprobl/ nvizpointbug1.jpg (the black of I change the black squares to x they are all under the surface, even if I make them really big). It would be useful if others tested this with different types of data and sequence of operations - this happened after I deleted and reloaded the data as Maciek has indicated. Helena > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-bugs at intevation.de Tue Dec 12 06:10:28 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Dec 12 06:10:30 2006 Subject: [GRASS-dev] [bug #5378] (grass) r.thin: less disk IO? Message-ID: <20061212051028.BD74E10016A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5378 ------------------------------------------------------------------------- Subject: r.thin: less disk IO? Is there a way to have r.thin use less disk IO? it is hardly using any memory at all, but thrashing away on the disk like crazy. This would help speed up the module a lot. raster/r.thin/io.c thanks, Hamish -------------------------------------------- Managed by Request Tracker From neteler at itc.it Tue Dec 12 07:12:48 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Dec 12 07:12:49 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061212134018.18e4beaf.hamish_nospam@yahoo.com> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> <20061211203402.GA13499@bartok.itc.it> <20061211204042.GB13499@bartok.itc.it> <20061212134018.18e4beaf.hamish_nospam@yahoo.com> Message-ID: <20061212061248.GA16335@bartok.itc.it> On Tue, Dec 12, 2006 at 01:40:18PM +1300, Hamish wrote: > Markus Neteler wrote: > > to verify exactly the coastline length for Italy which is given > > incorrectly in the ASPRS Grid & datums paper on Italy. > > > to be pedantic: > > coastline length is a classic fractal problem with no real answer. > ... > or did you get different answers from the same dataset, reprojected? I am aware of this fractal problem but that was not the point. One year ago the module reported a few *degree* as length for a boundary which was nonsense for the user. Now it calculated the geodetic length of the vector pieces. Markus PS: http://grass.itc.it/pipermail/grass-dev/2005-November/020030.html http://grass.itc.it/pipermail/grass-dev/2005-November/020099.html http://grass.itc.it/pipermail/grass-dev/2005-November/020160.html (then we solved it offlist) From grass-bugs at intevation.de Tue Dec 12 07:18:52 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Dec 12 07:18:53 2006 Subject: [GRASS-dev] [bug #5379] (grass) v.univar: add -e flag Message-ID: <20061212061852.1A15D10016A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5379 ------------------------------------------------------------------------- Subject: v.univar: add -e flag Hi, it would be great to have -e Calculate extended statistics also for v.univar ("transfer" from r.univar) to get rid of v.univar.sh. Markus -------------------------------------------- Managed by Request Tracker From jachym.cepicky at centrum.cz Tue Dec 12 08:28:55 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Dec 12 08:29:00 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> Message-ID: <20061212072855.GA28566@localdomain> hallo, On Mon, Dec 11, 2006 at 07:01:21PM +0000, Paul Kelly wrote: > Hello Jachym > Just a little comment below: > > On Mon, 11 Dec 2006, Jachym Cepicky wrote: > > >On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: > >>On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > >>>hi, > >>> > >>>since nobody really complained, I commited the patch. v.to.db has new > >>>option "slope" now > >> > >>hi jachym, > >> > >>does it now work for LatLong? I guess I overlooked some email. > >> > [...] > >no, it does not :-( it does not even work with option=length, because of > > > > > >Vect_cidx_get_num_unique_cats_by_index ( &Map, > >Vect_cidx_get_field_index(&Map, options.field ) ); > > > >in main.c returns 1634887471 of unique cats by index and v.to.db ends up > >with G_calloc error: could not allocat memory. > > > >I have no clue, how to fix this bug. > > I (maybe others) interpreted this as you admitting that the patch was not > yet ready/good enough to commit to CVS! So maybe that's why nobody > complained - Is it true that wrong results will be given in a lat/long > location with no warning? If so, then something should be changed. > If not, and I've misunderstood, then it's all OK! > > Paul Slope is calculated with line lenght. Calculating line length on lat/long location does not work either. This patch adds new funtionality and (should) does not break old ones. I tryed this in GRASS 6.2 and calculating line length on lat/long location does not work there too. So, as I got mostly positive feedback and as I did not break any funtionality, I commited the patch. I also tryed to describe, why this does not work on lat/long locations. Sorry, I was not able to find out, where exactly the problem is. I guess, some variable is not initialized. If I should not commit the patch, because of this all, I'm sorry and will remove this patch from cvs. I'll fill the bug tracker for the length issue. Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061212/b9be0c7b/attachment.bin From jachym.cepicky at centrum.cz Tue Dec 12 09:12:25 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Dec 12 09:12:30 2006 Subject: [GRASS-dev] v.to.db option=slope In-Reply-To: <20061211204042.GB13499@bartok.itc.it> References: <20061207163000.GA28829@localdomain> <20061211175357.GA24372@localdomain> <20061211175836.GF5184@bartok.itc.it> <20061211180501.GA25251@localdomain> <20061211203402.GA13499@bartok.itc.it> <20061211204042.GB13499@bartok.itc.it> Message-ID: <20061212081225.GB28566@localdomain> hi, ee, sorry, I was confused. It seems to, that option=length does not work for vectors WITHOUT database connection. When I tryed this on new vector, with connected database table, everything seem to work fine: v.digit -n line v.drape in=line out=line3d rast=dem v.to.db -p col=nothing map=line3d option=length cat|length 1|4645.31351829853 v.to.db -p col=nothing map=line3d option=slope cat|slope 1|-0.0559703879998248 d.what.rast 14:43:43.389044E 49:50:30.741694N dmt in jachym, actual (530.000000) 14:39:59.979022E 49:51:15.627726N dmt in jachym, actual (269.000000) echo "(269-530)/4645.313518"|bc -l -.056185 So I would say, that calculating slope works ? Jachym On Mon, Dec 11, 2006 at 09:40:42PM +0100, Markus Neteler wrote: > On Mon, Dec 11, 2006 at 09:34:02PM +0100, Markus Neteler wrote: > > On Mon, Dec 11, 2006 at 07:05:01PM +0100, Jachym Cepicky wrote: > > > On Mon, Dec 11, 2006 at 06:58:36PM +0100, Markus Neteler wrote: > > > > On Mon, Dec 11, 2006 at 06:53:57PM +0100, Jachym Cepicky wrote: > > > > > since nobody really complained, I commited the patch. v.to.db has new > > > > > option "slope" now > > > > > > > > does it now work for LatLong? I guess I overlooked some email. > > > > > > > yes, I was writing about this: > > > > > > no, it does not :-( it does not even work with option=length, because of > > In fact it works with length: > > GRASS 6.3.cvs (latlong):~ > v.to.db -p polbnda_italy_state op=length un=k col=dummy type=boundary > cat|length > -1|8630.5217187381 > 1|0 > 2 categories read from map > 0 records selected from table > 0 categories read from map exist in selection from table > 0 categories read from map don't exist in selection from table > 0 records updated/inserted > 0 update/insert errors > > We fixed that one year ago: > > 2005-11-30 16:26 markus > * areas.c, description.html: Wolf Bergenheim: use geodetic length > for perimeter in LatLong; prettified areas.c with indent > > to verify exactly the coastline length for Italy which is given incorrectly in > the ASPRS Grid & datums paper on Italy. > > Markus > > > > > > > > > > Vect_cidx_get_num_unique_cats_by_index ( &Map, > > > Vect_cidx_get_field_index(&Map, options.field ) ); > > > > > > in main.c returns 1634887471 of unique cats by index and v.to.db ends up > > > with G_calloc error: could not allocat memory. > > > > > > I have no clue, how to fix this bug. > > > > Hi Jachym, > > > > I don't think that we should knowingly introduce bugs in > > GRASS. It would be good to get that resolved soon. > > As Paul said - I also assumed that you would consider the > > patch as non-ready, so I didn't further comment. > > > > Best, > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061212/bda01ed2/attachment.bin From jachym.cepicky at centrum.cz Tue Dec 12 14:41:42 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Dec 12 14:41:48 2006 Subject: [GRASS-dev] v.edit updates Message-ID: <20061212134142.GA14204@localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061212/d54827fc/attachment-0001.bin From michael.barton at asu.edu Tue Dec 12 17:39:09 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 12 17:39:19 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: Message-ID: On 12/11/06 5:41 PM, "Helena Mitasova" wrote: > > I did not test it with spearfish, but I can confirm that there is a > problem still in 6.3 > My problem was not the same - icons, colors worked fine, but when I > chose x as > a symbol all points were displayed under the surface, using other > symbols they were > draped properly: here is the image of what I tested it with (I sneak > preview > of the new data set we plan to replace the spearfish with) > > http://skagit.meas.ncsu.edu/~helena/grasswork/grassprobl/ > nvizpointbug1.jpg > (the black of I change the black squares to x they are all under the > surface, even > if I make them really big). > > It would be useful if others tested this with different types of data > and sequence > of operations - this happened after I deleted and reloaded the data > as Maciek has indicated. > Helena, I checked the x icon in a current (as of last Friday) version of NVIZ. On my system (Mac OSX with x11 version of GRASS), I have the opposite problem from you. The x's float above the landscape. I think the problem is that they are trying to conform to the landscape rather than be a 3D icon like the rest of them. This has been a long-standing problem AFAICT. This is one of the reasons I switched the default icon from X to sphere (the other is that the x's are difficult to see). You can see a screenshot of the floating x's at BTW, the new landscapes look very cool. Where are they from? Switching the demo set from Spearfish to someplace else after over 20 years is BIG news for GRASS. Is the city of Spearfish protesting? ;-) Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Tue Dec 12 17:56:00 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Dec 12 17:56:04 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <20061212125448.34d821e0.hamish_nospam@yahoo.com> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> <457D9D26.9030708@o2.pl> <20061212125448.34d821e0.hamish_nospam@yahoo.com> Message-ID: <457EDF20.3050605@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >> There is still a bug in NVIZ, that usually after adding a vector point >> layer, removing it, and adding a new one, artifacts are displayed, >> including: >> >> 1. different icons then the chosen one, for some points >> 2. some points are displayed with random colors, not the one specified >> 3. line artifact happen to pop up >> >> See the attached screendump (spearfish: elevation.10m + archsites) and >> latest remarks in the http://intevation.de/rt/webrt?serial_num=4492. > do both of these issues exist in 6.2 and 6.3, or have they been fixed in > 6.3 but not backported? Both issues exist in 6.2 and 6.3. Maciek From bcovill at tekmap.ns.ca Tue Dec 12 18:34:21 2006 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Tue Dec 12 18:34:52 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <457EDF20.3050605@o2.pl> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> <457D9D26.9030708@o2.pl> <20061212125448.34d821e0.hamish_nospam@yahoo.com> <457EDF20.3050605@o2.pl> Message-ID: <1165944861.14826.8.camel@linuxmain.localhost> On Tue, 2006-12-12 at 17:56 +0100, Maciej Sieczka wrote: > Hamish wrote: > > Maciej Sieczka wrote: > > >> There is still a bug in NVIZ, that usually after adding a vector point > >> layer, removing it, and adding a new one, artifacts are displayed, > >> including: > >> > >> 1. different icons then the chosen one, for some points > >> 2. some points are displayed with random colors, not the one specified > >> 3. line artifact happen to pop up > >> > >> See the attached screendump (spearfish: elevation.10m + archsites) and > >> latest remarks in the http://intevation.de/rt/webrt?serial_num=4492. > > > do both of these issues exist in 6.2 and 6.3, or have they been fixed in > > 6.3 but not backported? > > Both issues exist in 6.2 and 6.3. This appears to be a bug in ogsf (Gp3.c) where it uses the adapted sites library to load the vector points. I have been testing a modified version where I load the points with direct calls to the vector library (not sites). This seems to clear up the reported problem. Once I have finished testing I will commit to cvs. This will also get rid of the ogsf dependance on the temporary sites library. -- Bob > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From tutey at o2.pl Tue Dec 12 19:02:23 2006 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Dec 12 19:02:35 2006 Subject: [GRASS-dev] GRASS 6.2.1RC1 published In-Reply-To: <1165944861.14826.8.camel@linuxmain.localhost> References: <20061206213647.GA28175@bartok.itc.it> <457A92FB.7010401@gmx.de> <1165674371.21250.34.camel@devel> <20061209150628.GA27879@bartok.itc.it> <20061211234002.5cc5d9c1.hamish_nospam@yahoo.com> <457D9D26.9030708@o2.pl> <20061212125448.34d821e0.hamish_nospam@yahoo.com> <457EDF20.3050605@o2.pl> <1165944861.14826.8.camel@linuxmain.localhost> Message-ID: <457EEEAF.7020106@o2.pl> Bob Covill wrote: > On Tue, 2006-12-12 at 17:56 +0100, Maciej Sieczka wrote: >> Both issues exist in 6.2 and 6.3. > This appears to be a bug in ogsf (Gp3.c) where it uses the adapted sites > library to load the vector points. I have been testing a modified > version where I load the points with direct calls to the vector library > (not sites). This seems to clear up the reported problem. > > Once I have finished testing I will commit to cvs. This will also get > rid of the ogsf dependance on the temporary sites library. Excellent! I will be glad to test it. Cheers, Maciek From hmitaso at unity.ncsu.edu Tue Dec 12 19:30:31 2006 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Dec 12 19:27:02 2006 Subject: [GRASS-dev] new data set In-Reply-To: References: Message-ID: <457EF547.20907@unity.ncsu.edu> Michael Barton wrote: > On 12/11/06 5:41 PM, "Helena Mitasova" wrote: > > >> I did not test it with spearfish, but I can confirm that there is a >> problem still in 6.3 >> My problem was not the same - icons, colors worked fine, but when I >> chose x as >> a symbol all points were displayed under the surface, using other >> symbols they were >> draped properly: here is the image of what I tested it with (I sneak >> preview >> of the new data set we plan to replace the spearfish with) >> >> http://skagit.meas.ncsu.edu/~helena/grasswork/grassprobl/ >> nvizpointbug1.jpg >> (the black of I change the black squares to x they are all under the >> surface, even >> if I make them really big). >> >> It would be useful if others tested this with different types of data >> and sequence >> of operations - this happened after I deleted and reloaded the data >> as Maciek has indicated. >> >> > > Helena, > > I checked the x icon in a current (as of last Friday) version of NVIZ. On my > system (Mac OSX with x11 version of GRASS), I have the opposite problem from > you. The x's float above the landscape. I think the problem is that they are > trying to conform to the landscape rather than be a 3D icon like the rest of > them. This has been a long-standing problem AFAICT. This is one of the > reasons I switched the default icon from X to sphere (the other is that the > x's are difficult to see). You can see a screenshot of the floating x's at > > > BTW, the new landscapes look very cool. Where are they from? Switching the > demo set from Spearfish to someplace else after over 20 years is BIG news > for GRASS. Is the city of Spearfish protesting? ;-) > There is more info and related links here: http://wiki.osgeo.org/index.php/Edu_Data_Package_North_Carolina I am not releasing it yet as I am working with it to find out what is the minimum data set needed to cover the material in the book and tutorials - the amount of data for this area is huge and we want to keep it easy to handle. I plan for additional mapsets covering various topics (e.g. terrain data and analysis from different sources, coastal, urban, etc.) - others will be probably able to create their own using the public data available. I think that we will have Spearfish around for a while until the new data set gets well tested and established. If anybody is working on any new tutorials or educational materials based on spearfish, and would rather use the new data set, let me know, I will post what I have now. Helena > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > -- Helena Mitasova Department of Marine, Earth and Atmospheric Sciences North Carolina State University 1125 Jordan Hall NCSU Box 8208 Raleigh, NC 27695-8208 http://skagit.meas.ncsu.edu/~helena/ email: hmitaso@unity.ncsu.edu ph: 919-513-1327 (no voicemail) fax 919 515-7802 From paul-grass at stjohnspoint.co.uk Tue Dec 12 21:58:26 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 12 21:58:29 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <457D76AD.3050407@club.worldonline.be> References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> Message-ID: Hello Moritz I've got a bit further with documenting what I was doing. See attached for some of my notes. Mostly on compiling the accompanying libraries GRASS absolutely needs: XDR Zlib libpng PROJ.4 GDAL I put these into a gzipped tar file in case anybody would like to get started quickly - in this case you would just need Msys,Mingw with bison and flex. Everything else included in here: http://www.stjohnspoint.co.uk/grass/wingrass-extralibs.tar.gz and then the prefix where you untar that file you will need to supply to the GRASS configure as: --with-includes=prefix --with-libs=prefix FWIW my configure line was: ./configure --prefix=c:/grass --bindir=c:/grass/bin \ --with-includes=/c/grass/forgrass/include \ --with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \ --without-postgres --with-opengl=windows --without-fftw --without-x \ --enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \ --with-tcltk-libs=/c/tcl/bin After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory into the GRASS bin directory, and then you have a more or less self-contained GRASS distribution. I also installed Activestate Tcl/Tk 8.4.13 (in c:\tcl). I could make a binary distribution that sort of works OK to a certain extent without having Msys/Mingw installed, only thing is I want to wait until Nviz is working again on Windows as it was up to yesterday. The problem is starting it from a script. Scripts are very problematic (and of course only possible at all if you have Msys installed) because of the way Msys handles Windows paths. If you have Msys and Mingw installed, putting their bin directories in the PATH makes things in general run more smoothly, but of course that's cheating! Paul -------------- next part -------------- Download and run the MinGW installer. Let it download and install what it needs. Also install: flex from gnuwin32.sourceforge.net and put flex.exe in Mingw bin directory Use bison from Mingw as Gnuwin32 bison looks for libintl3.dll Download pdcurses from Mingw download page. Install in directory prefix where libraries needed for GRASS are going. Rename libpdcurses.a to libcurses.a (only need this and curses.h) TODO: compile this from scratch and make it a shared DLL to save disk space. Run Msys installer and let it install default stuff. XDR: download from Glynn's link. need to copy in config.guess from GRASS. Also a patch: diff -ur xdr-orig/Makefile.in xdr-pk/Makefile.in --- xdr-orig/Makefile.in Fri Nov 18 16:13:16 2005 +++ xdr-pk/Makefile.in Mon Dec 11 22:18:34 2006 @@ -19,24 +19,27 @@ HDRS = rpc/types.h rpc/xdr.h -all xdrlib: libxdr.a +all xdrlib: libxdr.dll libxdr.a: ${OBJS} @echo "building libxdr.a" ${AR} cru libxdr.a ${OBJS} -install: $(HDRS) libxdr.a +libxdr.dll: ${OBJS} + @echo "building libxdr.dll" + ${CC} -shared -o libxdr.dll ${OBJS} -lwsock32 + +install: $(HDRS) libxdr.dll @echo "Creating RPC header directory" - -mkdir -p ${prefix}/include/rpc && \ - chmod 755 ${prefix}/include/rpc + -mkdir -p -m 755 ${prefix}/include/rpc @echo "Installing XDR header files" -set -x;for i in $(HDRS) ; do \ (install -c -m 644 $$i ${prefix}/include/rpc) done @echo "Installing XDR library" - install -c -m 644 libxdr.a ${prefix}/lib - ${RANLIB} ${prefix}/lib/libxdr.a + -mkdir -p -m 755 ${prefix}/lib + install -c -m 644 libxdr.dll ${prefix}/lib clean: - rm -f *.o libxdr.a + rm -f *.o libxdr.dll diff -ur xdr-orig/xdr_array.c xdr-pk/xdr_array.c --- xdr-orig/xdr_array.c Fri Nov 18 16:13:16 2005 +++ xdr-pk/xdr_array.c Mon Dec 11 22:06:28 2006 @@ -41,6 +41,8 @@ */ #include +#include +#include #include #include @@ -95,7 +97,7 @@ "xdr_array: out of memory\n"); return (FALSE); } - bzero(target, nodesize); + memset(target, 0, (size_t)nodesize); break; case XDR_FREE: diff -ur xdr-orig/xdr_mem.c xdr-pk/xdr_mem.c --- xdr-orig/xdr_mem.c Fri Nov 18 16:13:16 2005 +++ xdr-pk/xdr_mem.c Mon Dec 11 22:09:45 2006 @@ -42,6 +42,7 @@ * */ +#include #include #include @@ -126,7 +127,7 @@ if ((xdrs->x_handy -= len) < 0) return (FALSE); - bcopy(xdrs->x_private, addr, len); + memmove(addr, xdrs->x_private, (size_t)len); xdrs->x_private += len; return (TRUE); } @@ -140,7 +141,7 @@ if ((xdrs->x_handy -= len) < 0) return (FALSE); - bcopy(addr, xdrs->x_private, len); + memmove(xdrs->x_private, addr, (size_t)len); xdrs->x_private += len; return (TRUE); } diff -ur xdr-orig/xdr_rec.c xdr-pk/xdr_rec.c --- xdr-orig/xdr_rec.c Fri Nov 18 16:13:16 2005 +++ xdr-pk/xdr_rec.c Mon Dec 11 22:10:58 2006 @@ -49,6 +49,9 @@ */ #include +#include +#include + #include #include //#include @@ -279,7 +282,7 @@ while (len > 0) { current = (u_int)rstrm->out_boundry - (u_int)rstrm->out_finger; current = (len < current) ? len : current; - bcopy(addr, rstrm->out_finger, current); + memmove(rstrm->out_finger, addr, (size_t)current); rstrm->out_finger += current; addr += current; len -= current; @@ -530,7 +533,7 @@ continue; } current = (len < current) ? len : current; - bcopy(rstrm->in_finger, addr, current); + memmove(addr, rstrm->in_finger, (size_t)current); rstrm->in_finger += current; addr += current; len -= current; diff -ur xdr-orig/xdr_reference.c xdr-pk/xdr_reference.c --- xdr-orig/xdr_reference.c Fri Nov 18 16:13:16 2005 +++ xdr-pk/xdr_reference.c Mon Dec 11 22:05:35 2006 @@ -41,6 +41,8 @@ */ #include +#include +#include #include #include @@ -77,7 +79,7 @@ "xdr_reference: out of memory\n"); return (FALSE); } - bzero(loc, (int)size); + memset(loc, 0, (size_t)size); break; } ./configure --prefix=/c/grass/forgrass make make install zlib-1.2.3 A patch: --- orig/zlib-1.2.3/configure Mon Jul 11 22:11:57 2005 +++ pk/zlib-1.2.3/configure Mon Dec 11 22:57:11 2006 @@ -79,6 +79,11 @@ Linux | linux | GNU | GNU/*) LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.so.1"};; CYGWIN* | Cygwin* | cygwin* | OS/2* ) EXE='.exe';; + MINGW32* ) + shared_ext='.dll' + SFLAGS=${CFLAGS} + LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.dll.1"} + EXE='.exe';; QNX*) # This is for QNX6. I suppose that the QNX rule below is for QNX2,QNX4 # (alain.bonnefoy@icbt.com) LDSHARED=${LDSHARED-"$cc -shared -Wl,-hlibz.so.1"};; ./configure --shared --prefix=/c/grass/forgrass make make install libpng 1.2.12-noconfig cp scripts/makefile.mingw ./Makefile Make it. Then I added a bit to the Makefile to create a shared library: libpng.dll: $(OBJS) gcc -shared -o $@ $(OBJS) -L$(ZLIBLIB) -lz make libpng.dll install to lib directory manually and same for png.h and pngconf.h into include. PROJ 4.5.0 ./configure --enable-shared --disable-static --prefix=/c/grass/forgrass make but then delete libraries and executables created and do this cd src/.libs gcc -shared -o libproj.dll -lm PJ_aeqd.o PJ_gnom.o PJ_laea.o PJ_mod_ster.o PJ_nsper.o PJ_nzmg.o PJ_ortho.o PJ_stere.o PJ_sterea.o PJ_aea.o PJ_bipc.o PJ_bonne.o PJ_eqdc.o PJ_imw_p.o PJ_krovak.o PJ_lcc.o PJ_mpoly.o PJ_poly.o PJ_rpoly.o PJ_sconics.o proj_rouss.o PJ_cass.o PJ_cc.o PJ_cea.o PJ_eqc.o PJ_gall.o PJ_labrd.o PJ_lsat.o PJ_merc.o PJ_mill.o PJ_ocea.o PJ_omerc.o PJ_somerc.o PJ_tcc.o PJ_tcea.o PJ_tmerc.o PJ_airy.o PJ_aitoff.o PJ_august.o PJ_bacon.o PJ_chamb.o PJ_hammer.o PJ_lagrng.o PJ_larr.o PJ_lask.o PJ_nocol.o PJ_ob_tran.o PJ_oea.o PJ_tpeqd.o PJ_vandg.o PJ_vandg2.o PJ_vandg4.o PJ_wag7.o PJ_lcca.o PJ_geos.o PJ_boggs.o PJ_collg.o PJ_crast.o PJ_denoy.o PJ_eck1.o PJ_eck2.o PJ_eck3.o PJ_eck4.o PJ_eck5.o PJ_fahey.o PJ_fouc_s.o PJ_gins8.o PJ_gn_sinu.o PJ_goode.o PJ_hatano.o PJ_loxim.o PJ_mbt_fps.o PJ_mbtfpp.o PJ_mbtfpq.o PJ_moll.o PJ_nell.o PJ_nell_h.o PJ_putp2.o PJ_putp3.o PJ_putp4p.o PJ_putp5.o PJ_putp6.o PJ_robin.o PJ_sts.o PJ_urm5.o PJ_urmfps.o PJ_wag2.o PJ_wag3.o PJ_wink1.o PJ_wink2.o pj_latlong.o pj_geocent.o aasincos.o adjlon.o bch2bps.o bchgen.o biveval.o dmstor.o mk_cheby.o pj_auth.o pj_deriv.o pj_ell_set.o pj_ellps.o pj_errno.o pj_factors.o pj_fwd.o pj_init.o pj_inv.o pj_list.o pj_malloc.o pj_mlfn.o pj_msfn.o proj_mdist.o pj_open_lib.o pj_param.o pj_phi2.o pj_pr_list.o pj_qsfn.o pj_strerrno.o pj_tsfn.o pj_units.o pj_zpoly1.o rtodms.o vector1.o pj_release.o pj_gauss.o nad_cvt.o nad_init.o nad_intr.o emess.o pj_apply_gridshift.o pj_datums.o pj_datum_set.o pj_transform.o geocent.o pj_utils.o pj_gridinfo.o pj_gridlist.o jniproj.o install libproj.dll /c/grass/forgrass/lib cd .. sh-2.04$ ls -l *exe -rwxr-xr-x 1 Paul Administ 621579 Dec 11 23:35 cs2cs.exe -rwxr-xr-x 1 Paul Administ 77539 Dec 11 23:35 geod.exe -rwxr-xr-x 1 Paul Administ 26045 Dec 11 23:35 nad2bin.exe -rwxr-xr-x 1 Paul Administ 143429 Dec 11 23:35 nad2nad.exe -rwxr-xr-x 1 Paul Administ 592770 Dec 11 23:35 proj.exe gcc -g -O2 -o cs2cs.exe cs2cs.o gen_cheb.o p_series.o emess.o -L/c/grass/forgrass/lib -lproj gcc -g -O2 -o geod.exe geod.o geod_set.o geod_for.o geod_inv.o emess.o -L/c/grass/forgrass/lib -lproj gcc -g -O2 -o nad2bin.exe nad2bin.o gcc -g -O2 -o nad2nad.exe nad2nad.o emess.o -L/c/grass/forgrass/lib -lproj gcc -g -O2 -o proj.exe proj.o gen_cheb.o p_series.o emess.o -L/c/grass/forgrass/lib -lproj sh-2.04$ ls -l *exe -rwxr-xr-x 1 Paul Administ 55485 Dec 12 09:43 cs2cs.exe -rwxr-xr-x 1 Paul Administ 55002 Dec 12 09:48 geod.exe -rwxr-xr-x 1 Paul Administ 26045 Dec 12 09:47 nad2bin.exe -rwxr-xr-x 1 Paul Administ 44650 Dec 12 09:49 nad2nad.exe -rwxr-xr-x 1 Paul Administ 64185 Dec 12 09:49 proj.exe mkdir -p /c/grass/forgrass/bin for i in *exe ; do install $i /c/grass/forgrass/bin ; done for i in projects.h nad_list.h proj_api.h org_proj4_Projections.h ; do install -m 644 $i /c/grass/forgrass/include ; done GDAL 1.4.0 beta1 ./configure --prefix=/c/grass/forgrass --enable-shared --with-libz=/c/grass/forgrass --with-png=/c/grass/forgrass make make install If you want you could move libgdal-1.dll from bin/ to lib/ and edit libgdal.la to reflect this. Rename ogr* to ogr*exe From neteler at itc.it Tue Dec 12 22:22:58 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Dec 12 22:22:58 2006 Subject: [GRASS-dev] GRASS GIS 6.2.1 released Message-ID: <20061212212257.GB8105@bartok.itc.it> GRASS GIS releases version 6.2.1 12 December 2006 http://grass.itc.it GRASS 6.2.1 is a new stable release which fixes several bugs discovered in the 6.2.0 source code. This release is solely for stability purposes and adds no new features. Besides bug fixes it also includes a number of new message translations, updates for the help pages, and will better handle errors caused by missing or incorrectly installed support software. It also introduces a new 3D raster module which was left out of the last release due to time constraints. Full story at http://grass.itc.it/announces/announce_grass621.html From paul-grass at stjohnspoint.co.uk Tue Dec 12 22:37:08 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Dec 12 22:37:10 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> Message-ID: Oh and in case anybody is trying this, you won't get too far with the Windows startup without changing the path to WINGISBASE in grass63.bat (the startup file) to have Windows-style backslash-\ directory separator characters. Can't seem to get the Makefile to put these in but I guess I'll get it working eventually. On Tue, 12 Dec 2006, Paul Kelly wrote: > Hello Moritz > I've got a bit further with documenting what I was doing. See attached for > some of my notes. Mostly on compiling the accompanying libraries GRASS > absolutely needs: > XDR > Zlib > libpng > PROJ.4 > GDAL > > I put these into a gzipped tar file in case anybody would like to get started > quickly - in this case you would just need Msys,Mingw with bison and flex. > Everything else included in here: > http://www.stjohnspoint.co.uk/grass/wingrass-extralibs.tar.gz > and then the prefix where you untar that file you will need to supply to the > GRASS configure as: > --with-includes=prefix --with-libs=prefix > FWIW my configure line was: > ./configure --prefix=c:/grass --bindir=c:/grass/bin \ > --with-includes=/c/grass/forgrass/include \ > --with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \ > --without-postgres --with-opengl=windows --without-fftw --without-x \ > --enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \ > --with-tcltk-libs=/c/tcl/bin > > After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, > libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the > GDAL and PROJ .exe files in the bin directory into the GRASS bin directory, > and then you have a more or less self-contained GRASS distribution. > > I also installed Activestate Tcl/Tk 8.4.13 (in c:\tcl). > > I could make a binary distribution that sort of works OK to a certain extent > without having Msys/Mingw installed, only thing is I want to wait until Nviz > is working again on Windows as it was up to yesterday. The problem is > starting it from a script. Scripts are very problematic (and of course only > possible at all if you have Msys installed) because of the way Msys handles > Windows paths. > > If you have Msys and Mingw installed, putting their bin directories in the > PATH makes things in general run more smoothly, but of course that's > cheating! > > Paul > From michael.barton at asu.edu Tue Dec 12 22:44:05 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 12 22:45:47 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: Message-ID: This will be GREAT! Thanks very much. Michael On 12/12/06 1:58 PM, "Paul Kelly" wrote: > Hello Moritz > I've got a bit further with documenting what I was doing. See attached for > some of my notes. Mostly on compiling the accompanying libraries GRASS > absolutely needs: > XDR > Zlib > libpng > PROJ.4 > GDAL > > I put these into a gzipped tar file in case anybody would like to get > started quickly - in this case you would just need Msys,Mingw with bison > and flex. Everything else included in here: > http://www.stjohnspoint.co.uk/grass/wingrass-extralibs.tar.gz > and then the prefix where you untar that file you will need to supply to > the GRASS configure as: > --with-includes=prefix --with-libs=prefix > FWIW my configure line was: > ./configure --prefix=c:/grass --bindir=c:/grass/bin \ > --with-includes=/c/grass/forgrass/include \ > --with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff \ > --without-postgres --with-opengl=windows --without-fftw --without-x \ > --enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \ > --with-tcltk-libs=/c/tcl/bin > > After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, > libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the > GDAL and PROJ .exe files in the bin directory into the GRASS bin > directory, and then you have a more or less self-contained GRASS > distribution. > > I also installed Activestate Tcl/Tk 8.4.13 (in c:\tcl). > > I could make a binary distribution that sort of works OK to a certain > extent without having Msys/Mingw installed, only thing is I want to wait > until Nviz is working again on Windows as it was up to yesterday. The > problem is starting it from a script. Scripts are very problematic (and of > course only possible at all if you have Msys installed) because of the way > Msys handles Windows paths. > > If you have Msys and Mingw installed, putting their bin directories in the > PATH makes things in general run more smoothly, but of course that's > cheating! > > Paul __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Dec 12 22:47:47 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 12 22:48:43 2006 Subject: [GRASS-dev] Re: [GRASS-user] GRASS GIS 6.2.1 released In-Reply-To: <20061212212257.GB8105@bartok.itc.it> Message-ID: Good going Markus. This must be some kind of record. How many stable releases have there been this year already? Michael On 12/12/06 2:22 PM, "Markus Neteler" wrote: > GRASS GIS releases version 6.2.1 > 12 December 2006 > http://grass.itc.it > > GRASS 6.2.1 is a new stable release which fixes several bugs discovered in > the 6.2.0 source code. This release is solely for stability purposes and adds > no new features. Besides bug fixes it also includes a number of new message > translations, updates for the help pages, and will better handle errors > caused by missing or incorrectly installed support software. It also > introduces a new 3D raster module which was left out of the last release > due to time constraints. > > Full story at http://grass.itc.it/announces/announce_grass621.html > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From soerengebbert at gmx.de Tue Dec 12 22:53:16 2006 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Tue Dec 12 22:53:18 2006 Subject: [GRASS-dev] Re: [Qgis-developer] Re: GRASS Unit Tests for Win Build In-Reply-To: <1FBC64ED-158E-4697-8740-4480C546F9DE@mrcc.com> References: <20061211225407.190010@gmx.net> <1FBC64ED-158E-4697-8740-4480C546F9DE@mrcc.com> Message-ID: <20061212215316.295080@gmx.net> Hi, i made it. :) I have copied the gproj, site and vect lib to the grass lib directory to run the test suite. The result is available here: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_win32_msys/ It is quite similiar to the qgis-grass-build result: http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_win32/ Best regards Soeren -------- Original-Nachricht -------- Datum: Mon, 11 Dec 2006 14:11:34 -0900 Von: Gary Sherman An: "S?ren Gebbert" Betreff: Re: [Qgis-developer] Re: GRASS Unit Tests for Win Build > > On Dec 11, 2006, at 1:54 PM, S?ren Gebbert wrote: > > > i have tried to run the grass test suite within the msys environment. > > But the tests failed for many modules, because the library > > libgrass_gproj.6.3.cvs.dll was not found. > > The library is in the top-level directory where qgis is installed > (this is true for the latest test build). Try adding your qgis > install directory to the path and then testing. > -gary > -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- > Gary Sherman > Micro Resources: http://mrcc.com > *Geospatial Hosting > *Web Site Hosting > "We work virtually everywhere" > -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- > > -- "Ein Herz f?r Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankesch?n: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! From neteler at itc.it Tue Dec 12 23:09:09 2006 From: neteler at itc.it (Markus Neteler) Date: Tue Dec 12 23:09:10 2006 Subject: [GRASS-dev] Re: [GRASS-user] GRASS GIS 6.2.1 released In-Reply-To: References: <20061212212257.GB8105@bartok.itc.it> Message-ID: <20061212220909.GC8105@bartok.itc.it> Michael, everything is well documented here: http://grass.itc.it/ -> Intro (top menu) -> History (left menu) http://grass.itc.it/devel/grasshist.html -> Releases (left menu) http://grass.itc.it/devel/grassreleases.html We started the year 2006 with 6.0.2RC2, followed by RC3, RC4, then 6.0.2 in February (so 1st official), three 6.1.x releases as technology preview, 6.2.0beta1, beta2, RC1-RC3, then 6.2.0 end of October, 6.2.1RC1 and now 6.2.1! We are well experienced now and have meanwhile a functional release cycle. The release tarball preparation plus Web site update takes me now only 30 minutes, for major releases I post around press releases which takes 2 hours to fill all the various forms. Outstanding problems are documented in the Wiki: http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan#TODO_for_6.2.2 Altogether, this only works due to the great feedback of the power users (and "normal" users of course) to the developers and the growing group of developers. To answer your question: 6.0.2 and 6.2.0/6.2.1 in this year. cheers Markus On Tue, Dec 12, 2006 at 02:47:47PM -0700, Michael Barton wrote: > Good going Markus. This must be some kind of record. How many stable > releases have there been this year already? > > Michael > > > On 12/12/06 2:22 PM, "Markus Neteler" wrote: > > > GRASS GIS releases version 6.2.1 > > 12 December 2006 > > http://grass.itc.it > > > > GRASS 6.2.1 is a new stable release which fixes several bugs discovered in > > the 6.2.0 source code. This release is solely for stability purposes and adds > > no new features. Besides bug fixes it also includes a number of new message > > translations, updates for the help pages, and will better handle errors > > caused by missing or incorrectly installed support software. It also > > introduces a new 3D raster module which was left out of the last release > > due to time constraints. > > > > Full story at http://grass.itc.it/announces/announce_grass621.html > > > > > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From woklist at kyngchaos.com Tue Dec 12 23:20:54 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Dec 12 23:21:23 2006 Subject: [GRASS-dev] GRASS GIS 6.2.1 released In-Reply-To: <20061212212257.GB8105@bartok.itc.it> References: <20061212212257.GB8105@bartok.itc.it> Message-ID: <1BC69172-D19B-4478-87A0-823E033E1092@kyngchaos.com> Cool. I'll take a break from my GRASS Xcode project and package up a Mac OS X app. On Dec 12, 2006, at 3:22 PM, Markus Neteler wrote: > GRASS GIS releases version 6.2.1 > 12 December 2006 > http://grass.itc.it > > GRASS 6.2.1 is a new stable release which fixes several bugs > discovered in > the 6.2.0 source code. This release is solely for stability > purposes and adds > no new features. Besides bug fixes it also includes a number of new > message > translations, updates for the help pages, and will better handle > errors > caused by missing or incorrectly installed support software. It also > introduces a new 3D raster module which was left out of the last > release > due to time constraints. > > Full story at http://grass.itc.it/announces/announce_grass621.html > ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From michael.barton at asu.edu Tue Dec 12 23:22:59 2006 From: michael.barton at asu.edu (Michael Barton) Date: Tue Dec 12 23:23:05 2006 Subject: [GRASS-dev] updates to grass startup Message-ID: I just committed a set of patches to the GRASS startup tcltk files (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to make creating a new location from EPSG code or georeferenced file more robust. This is especially important for Windows users who cannot make a new location with g.proj. I?ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and they seem to be fine. Please test on other platforms. Also, if we are going to have EPSG codes as a standard way to create a new location (and I think this is a handy way to go), can we distribute a copy of the EPSG file inside the GRASS directory structure (e.g., in the infamous catchall etc or another directory)? The EPSG file is ending up in different places on different architectures making it difficult to find. If it was always in the same place, within the GRASS hierarchy, it would be easy to make this the default location for the GUI. Obviously the next thing to do is to make it searchable. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061212/dde4003f/attachment.html From oliver4grass at gmail.com Wed Dec 13 02:40:53 2006 From: oliver4grass at gmail.com (Vytautas V) Date: Wed Dec 13 02:40:55 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: <20061201153951.GF16862@bartok.itc.it> <20061206093111.GA24258@bartok.itc.it> <20061211194516.6546fa6f.hamish_nospam@yahoo.com> Message-ID: what about creating seperate module i.out.gdal for exporting groups? It can be created from a copy of current r.out.gdal. Vytautas From hamish_nospam at yahoo.com Wed Dec 13 06:54:07 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 13 06:55:46 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: References: <20061211142430.45dd944a.hamish_nospam@yahoo.com> Message-ID: <20061213185407.583d73e8.hamish_nospam@yahoo.com> Michael Barton wrote: > It seems like a good idea to be able to set the text > size too. Is there a variable/command to do this? grab the font control from panel_label.tcl lib/ogsf/gsd_objs.c: /************************************************************** * Function to draw North Arrow takes OpenGL coords and size *************************************************************/ int gsd_north_arrow (float *pos2, float len, GLuint fontbase, unsigned long arw_clr, unsigned long text_clr) { So yes, there is C support for setting a dynamic font. Right now the nviz north arrow and scale text is hardcoded as 18pt in nviz/src/draw.c: FontBase = load_font(TOGL_BITMAP_HELVETICA_18); but nviz/src/label.c uses the same thing to set the font from the controls: sprintf(font, "%s", argv[2]); size = (int) atoi(argv[3]); .. /* Print the label */ FontBase = load_font(font); which are the second and third arguments passed to Nplace_label ($font and $Nv_(labelFontSize)). So mimic panel_label and then it's just a quick modification to draw.c to use the variable value instead of the hardcoded one. Hamish From jachym.cepicky at centrum.cz Wed Dec 13 11:17:59 2006 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Dec 13 11:54:39 2006 Subject: [GRASS-dev] v.edit updates In-Reply-To: <20061212134142.GA14204@localdomain> References: <20061212134142.GA14204@localdomain> Message-ID: <20061213101759.GA10904@localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061213/e220fa24/attachment-0001.bin From hamish_nospam at yahoo.com Wed Dec 13 11:59:14 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 13 11:59:20 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: References: Message-ID: <20061213235914.552b79d4.hamish_nospam@yahoo.com> when creating a new location from EPSG code an xterm flashes up and then disappears. This might have some important info/warning/error in it. I have prepared the following patch, but not applied it as it makes the script partially interactive. (ie it asks the user to press to continue, but times out in 2 minutes [enough time to find a pen and write down an error]) So not a great solution, but here it is. Better? put a pause at end of exec grass-xterm-wrapper: lib/init/epsg_option.tcl.in: exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \ $env(GISBASE)/etc/make_location_epsg.sh \ $epsg_code $epsgLocation $locpath >@stdout 2>@stderr; \ read -t 120 or somehow like that? Hamish -------------- next part -------------- Index: lib/init/make_location_epsg.sh.in =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/init/make_location_epsg.sh.in,v retrieving revision 1.1 diff -u -r1.1 make_location_epsg.sh.in --- lib/init/make_location_epsg.sh.in 24 Apr 2006 09:17:55 -0000 1.1 +++ lib/init/make_location_epsg.sh.in 13 Dec 2006 10:51:59 -0000 @@ -36,9 +36,13 @@ fi if test -f $HOME/.gislock$GRASSVERSION ; then + echo echo "ERROR. GRASS $GRASSVERSION is already running" echo "Please close other session first." rm -f $HOME/.gislock$GRASSVERSION + echo + echo "Press to continue." + read -t 120 #exit 1 fi @@ -49,8 +53,12 @@ if [ "$MYGISDBASE" = "" ] ; then GISDBASE=`grep GISDBASE $HOME/.$GRASSRC | cut -d' ' -f2` if [ "$GISDBASE" = "" ] ; then + echo echo "ERROR. Cannot get GISDBASE from $HOME/.$GRASSRC" echo "Please specify the GISDBASE parameter" + echo + echo "Press to continue." + read -t 120 exit 1 fi else @@ -60,7 +68,10 @@ GISBASE=`echo $GISBASE | sed "s+'++g"` if test -d $GISDBASE/$LOCATION ; then + echo echo "ERROR. Location $LOCATION already exists in $GISDBASE" + echo "Press to continue." + read -t 120 exit 1 fi @@ -112,10 +123,15 @@ meters: 1.0" > $GISDBASE/$TEMPDIR/PERMANENT/PROJ_UNITS # create new location: +echo g.proj -c proj4='+init=epsg:'$EPSG location=$LOCATION if [ $? -eq 1 ] ; then + echo echo "An error occured. Stop." + echo + echo "Press to continue." + read -t 120 exit 1 fi @@ -127,6 +143,7 @@ #cleanup: rm -rf $GISDBASE/$TEMPDIR +echo echo "Now you can launch GRASS with:" echo " grass$GRASSVERSION $GISDBASE/$LOCATION/PERMANENT" echo "and start to import data sets (r.in.gdal -e ... ; v.in.ogr -e ... )." @@ -135,3 +152,6 @@ echo " check with g.proj -w" echo "To fix a missing datum definition, either edit the new PROJ_INFO file" echo "or carefully run g.proj again inside the new location." +echo +echo "Press to continue." +read -t 120 From hamish_nospam at yahoo.com Wed Dec 13 12:10:22 2006 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Dec 13 12:12:33 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: References: Message-ID: <20061214001022.00bcf732.hamish_nospam@yahoo.com> Michael Barton wrote: > I just committed a set of patches to the GRASS startup tcltk files > (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are > designed to make creating a new location from EPSG code or > georeferenced file more robust. This is especially important for > Windows users who cannot make a new location with g.proj. > > I?ve tested these on my Mac OSX with x11 GRASS cvs build of last > Friday and they seem to be fine. Please test on other platforms. now locations and mapsets are not sorted in alphabetical order. :/ > Also, if we are going to have EPSG codes as a standard way to create a > new location (and I think this is a handy way to go), can we > distribute a copy of the EPSG file inside the GRASS directory > structure (e.g., in the infamous catchall etc or another directory)? > The EPSG file is ending up in different places on different > architectures making it difficult to find. If it was always in the > same place, within the GRASS hierarchy, it would be easy to make this > the default location for the GUI. not for, but not strongly against, however: - The EPSG database and proj.4 are likely to be updated more often than GRASS is. - packagers should set --with-proj-share=, ./configure should give a clear error message if not found for home-brew. Tcl then finds this dir in the "PROJSHARE" variable. > Obviously the next thing to do is to make it searchable. yes please, and auto-fill the highlighted value in the create dialogue. Hamish From neteler at itc.it Wed Dec 13 12:19:36 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Dec 13 12:19:38 2006 Subject: [GRASS-dev] r.out.gdal2 -> r.out.gdal? In-Reply-To: References: <20061201153951.GF16862@bartok.itc.it> <20061206093111.GA24258@bartok.itc.it> <20061211194516.6546fa6f.hamish_nospam@yahoo.com> Message-ID: <457FE1C8.5040802@itc.it> Vytautas V wrote on 12/13/2006 02:40 AM: > what about creating seperate module i.out.gdal for exporting groups? > It can be created from a copy of current r.out.gdal. > Vytautas, copying code (cloning) is usually a bad thing since you have to maintain identical code several times. Personally I like the idea of having raster= group= for r.out.gdal. Markus From maris.gis at gmail.com Wed Dec 13 12:30:58 2006 From: maris.gis at gmail.com (Maris Nartiss) Date: Wed Dec 13 12:31:00 2006 Subject: [GRASS-dev] Re: updates to grass startup In-Reply-To: <20061213235914.552b79d4.hamish_nospam@yahoo.com> References: <20061213235914.552b79d4.hamish_nospam@yahoo.com> Message-ID: <2b3d8c1c0612130330i6ce2e121s244c7ae47ac18107@mail.gmail.com> Hi, my cleanup just fixed bugs 5328 and 5373. It also pariatly fixed 5372 and 5371 (My fault - too much bugs in one report). Summarising up: Currently there is no mechanism to catch error if creating of new location has failed. Current code always will look like it has suceed and will restart GRASS to strat use newly created location. Hamish code will only make error message visible to user (good thing), but GRASS should not continue as if everything was OK. When creating new location from EPSG code, there is some error in cleaning up temporary location in case of error. (See below) Creating new location from georeferenced file still will not work, as it needs some (temporary) location to run g.proj. Probably make_location_epsg.sh.in could be used to create new, similar script for georeferenced file too. Or probaby some new script, that creates valid temporary location and then cleans up for any module, that may need temporary location for running (do we need such script?). To reproduce problems - 1) rm .grassrc6 (This why n00bs report unreporoducable errors - daily grass users always have .grassrc6 with valid locations/mapsets); 2) create new location with EPSG code 1234 - tmp location is left over; 3) repeat 1st step and now create new location from valid georeferenced file - error. Currently I'm not as good in coding to fix those problems :( Just trying to make GRASS fool proof, Maris. 2006/12/13, Hamish : > when creating a new location from EPSG code an xterm flashes up and then > disappears. This might have some important info/warning/error in it. > > I have prepared the following patch, but not applied it as it makes the > script partially interactive. (ie it asks the user to press to > continue, but times out in 2 minutes [enough time to find a pen and > write down an error]) > > So not a great solution, but here it is. > > Better? put a pause at end of exec grass-xterm-wrapper: > > lib/init/epsg_option.tcl.in: > > exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \ > $env(GISBASE)/etc/make_location_epsg.sh \ > $epsg_code $epsgLocation $locpath >@stdout 2>@stderr; \ > read -t 120 > > or somehow like that? > > > Hamish > > From paul-grass at stjohnspoint.co.uk Wed Dec 13 12:52:09 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 13 12:52:13 2006 Subject: [GRASS-dev] Re: updates to grass startup In-Reply-To: <2b3d8c1c0612130330i6ce2e121s244c7ae47ac18107@mail.gmail.com> References: <20061213235914.552b79d4.hamish_nospam@yahoo.com> <2b3d8c1c0612130330i6ce2e121s244c7ae47ac18107@mail.gmail.com> Message-ID: On Wed, 13 Dec 2006, Maris Nartiss wrote: > Hi, > > my cleanup just fixed bugs 5328 and 5373. It also pariatly fixed 5372 > and 5371 (My fault - too much bugs in one report). > > Summarising up: > > Currently there is no mechanism to catch error if creating of new > location has failed. Current code always will look like it has suceed > and will restart GRASS to strat use newly created location. Hamish > code will only make error message visible to user (good thing), but > GRASS should not continue as if everything was OK. > > When creating new location from EPSG code, there is some error in > cleaning up temporary location in case of error. (See below) > > Creating new location from georeferenced file still will not work, as > it needs some (temporary) location to run g.proj. Probably > make_location_epsg.sh.in could be used to create new, similar script > for georeferenced file too. Or probaby some new script, that creates > valid temporary location and then cleans up for any module, that may > need temporary location for running (do we need such script?). I think we could maybe include the "demolocation" in the released distribution? It is small so not much overhead and contains a valid GISRC file that can be used in the initial stages. > > To reproduce problems - 1) rm .grassrc6 (This why n00bs report > unreporoducable errors - daily grass users always have .grassrc6 with > valid locations/mapsets); > 2) create new location with EPSG code 1234 - tmp location is left over; > 3) repeat 1st step and now create new location from valid > georeferenced file - error. > > Currently I'm not as good in coding to fix those problems :( > > Just trying to make GRASS fool proof, Really important. The startup is IMHO one of the most awkward, antiquated and bugprone parts of GRASS which I'm sure really puts people off! Paul From paul-grass at stjohnspoint.co.uk Wed Dec 13 12:46:45 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 13 12:53:35 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: References: Message-ID: Hello Michael On Tue, 12 Dec 2006, Michael Barton wrote: > I just committed a set of patches to the GRASS startup tcltk files > (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to > make creating a new location from EPSG code or georeferenced file more > robust. This is especially important for Windows users who cannot make a new > location with g.proj. BTW that is no longer true. g.setproj and etc/set_data work fine on Windows (better if you have Msys in your path though - I'm working on replacing a system("ls -C") call). If you click the "projection values" button in gis_set.tcl it will pop up a Window running set_data so you can create a location the traditional way. Current problem though is that the list of locations doesn't refresh to show the new location after you return from the box. I had a quick look a week or two ago but the design of gis_set.tcl seemed to make it very difficult to refresh that. Although if you click after the database directory and press Enter it refreshes. Maybe you have improved something to make that easier though? > I?ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and > they seem to be fine. Please test on other platforms. > > Also, if we are going to have EPSG codes as a standard way to create a new > location (and I think this is a handy way to go), can we distribute a copy > of the EPSG file inside the GRASS directory structure (e.g., in the infamous > catchall etc or another directory)? The EPSG file is ending up in different > places on different architectures making it difficult to find. If it was > always in the same place, within the GRASS hierarchy, it would be easy to > make this the default location for the GUI. I tried to create a location with EPSG code but it just says "WARNING: The epsg-codes file was not found!" and nothing appears to happen. Surely it isn't necessary to have that file installed if you already know the code you need? It isn't used for anything other than browsing and while including it in GRASS is definitely preferable to having to look for it wherever it was installed with PROJ, my preference would be to remove it altogether and instead in some way generate the lists from the .csv files in lib/proj that are actually used by g.proj to generate the location. Not sure how to do that but I think it's very confusing the way the file used for browsing is different from and potentially out of sync with the file used in the location generation. Or another option would be to use the PROJ.4 definitions in that file directly and forget about the roundabout way it is currently done by passing the EPSG code to g.proj as part of a PROJ-style projection description? Whatever's done will probably need a bit of work though. Paul From mlennert at club.worldonline.be Wed Dec 13 14:17:24 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Dec 13 14:16:08 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> Message-ID: <1594.164.15.134.77.1166015844.squirrel@geog-pc40.ulb.ac.be> Paul, On Tue, December 12, 2006 21:58, Paul Kelly wrote: > Hello Moritz > I've got a bit further with documenting what I was doing. See attached for > some of my notes. Mostly on compiling the accompanying libraries GRASS > absolutely needs: > XDR > Zlib > libpng > PROJ.4 > GDAL > > I put these into a gzipped tar file in case anybody would like to get > started quickly - in this case you would just need Msys,Mingw with bison > and flex. Everything else included in here: > http://www.stjohnspoint.co.uk/grass/wingrass-extralibs.tar.gz > and then the prefix where you untar that file you will need to supply to > the GRASS configure as: > --with-includes=prefix --with-libs=prefix > FWIW my configure line was: > ./configure --prefix=c:/grass --bindir=c:/grass/bin \ > --with-includes=/c/grass/forgrass/include \ > --with-libs=/c/grass/forgrass/lib --with-cxx --without-jpeg --without-tiff > \ > --without-postgres --with-opengl=windows --without-fftw --without-x \ > --enable-x11=no --enable-shared=yes --with-tcltk-includes=/c/tcl/include \ > --with-tcltk-libs=/c/tcl/bin > > After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, > libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the > GDAL and PROJ .exe files in the bin directory into the GRASS bin > directory, and then you have a more or less self-contained GRASS > distribution. Great job. Thanks for doing this ! I have had the following issues/questions while trying to go through the compilation using your tarball of compiled libraries (as comments (Mo:) within your compile instructions (Pa:)): Pa: Download and run the MinGW installer. Let it download and install what it needs. Mo: - I imagine I have to tell the installer to install g++ and mingw make ? - I imagine you just forgot to mention the install of msys ? Pa: Also install: flex from gnuwin32.sourceforge.net and put flex.exe in Mingw bin directory Mo: Why not flex from mingw ? And all I need to do is copy flex.exe, nothing else ? Pa: Use bison from Mingw as Gnuwin32 bison looks for libintl3.dll Mo: I did that, but I get this error: cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or directory make[3]: *** [y.tab.h] Error 1 It is in /mingw/share/bison/m4sugar/m4sugar.m4. I don't know why it is looking for it in msys ? This causes an error in the compilation of libvect and so many consequent errors. Mo: What about the shared files from proj, such as epsg (in share directory when ./configure&&make&&make install of proj in msys), they are not in your tarball Mo: during compilation, I get many errors concerning unfindable libz.dll.1.2.3; apparently program tries to launch db.* grass exe files such as db.columns, etc during compilation. Don't know why. After copying all files from c:\forgrass\lib to c:\grasssrc\grass6\dist*\lib no more error messages during compilation. You mention copying these after compilation. What am I doing wrong ? Moritz From paul-grass at stjohnspoint.co.uk Wed Dec 13 14:29:03 2006 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Dec 13 14:29:12 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <1594.164.15.134.77.1166015844.squirrel@geog-pc40.ulb.ac.be> References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> <1594.164.15.134.77.1166015844.squirrel@geog-pc40.ulb.ac.be> Message-ID: Hello Moritz Comments below. On Wed, 13 Dec 2006, Moritz Lennert wrote: > Great job. Thanks for doing this ! > > I have had the following issues/questions while trying to go through the > compilation using your tarball of compiled libraries (as comments (Mo:) > within your compile instructions (Pa:)): > > Pa: Download and run the MinGW installer. Let it download and install what > it needs. > > Mo: > > - I imagine I have to tell the installer to install g++ and mingw make ? Hmm, yes. I wasn't sure but as I recall I ticked those boxes yes. I told you my notes weren't thorough! > - I imagine you just forgot to mention the install of msys ? I mentioned it after pdcurses - don't recall there being any notable problems with it hence the briefness of the mention! > Pa: Also install: flex from gnuwin32.sourceforge.net and put flex.exe in > Mingw bin directory > > Mo: Why not flex from mingw ? And all I need to do is copy flex.exe, > nothing else ? I couldn't find flex on the Mingw site. Maybe I was blind. Is it there? Yes, just putting the flex.exe in the mingw bin directory worked fine for me. > Pa: Use bison from Mingw as Gnuwin32 bison looks for libintl3.dll > > Mo: I did that, but I get this error: > > cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or > directory > make[3]: *** [y.tab.h] Error 1 > > It is in /mingw/share/bison/m4sugar/m4sugar.m4. I don't know why it is > looking for it in msys ? This causes an error in the compilation of > libvect and so many consequent errors. Ah OK. I think I hacked about with that a little bit come to think of it. Just put it where it's looking for it ;) > Mo: What about the shared files from proj, such as epsg (in share > directory when ./configure&&make&&make install of proj in msys), they are > not in your tarball Good point. I should think there is only that one file affected by that though. Shared files needed by PROJ and GDAL are generally included with GRASS. See earlier discussions on the mailing list today about that EPSG file. > Mo: during compilation, I get many errors concerning unfindable > libz.dll.1.2.3; apparently program tries to launch db.* grass exe files > such as db.columns, etc during compilation. Don't know why. > After copying all files from c:\forgrass\lib to > c:\grasssrc\grass6\dist*\lib no more error messages during compilation. > You mention copying these after compilation. What am I doing wrong ? Just make sure c:\forgrass\lib is in your PATH before you start compiling and it should be fine. I copy them after compilation just to have everything self-contained for distributing it to others. As long as the DLLs are on your system and in the PATH everything should work. Also you need to change man/Makefile so it doesn't convert the HTML pages to man. The Makefile should be conditionalised so this is dependent on Perl being installed. Will look at it later. Thanks a lot for testing this. Paul From mlennert at club.worldonline.be Wed Dec 13 15:03:36 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Dec 13 15:02:18 2006 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <456315C6.2080208@club.worldonline.be> <45641333.4020607@club.worldonline.be> <4320.164.15.134.66.1165576169.squirrel@geog-pc40.ulb.ac.be> <457D76AD.3050407@club.worldonline.be> <1594.164.15.134.77.1166015844.squirrel@geog-pc40.ulb.ac.be> Message-ID: <1791.164.15.134.77.1166018616.squirrel@geog-pc40.ulb.ac.be> On Wed, December 13, 2006 14:29, Paul Kelly wrote: > Hello Moritz > Comments below. > > On Wed, 13 Dec 2006, Moritz Lennert wrote: > >> Great job. Thanks for doing this ! >> >> I have had the following issues/questions while trying to go through the >> compilation using your tarball of compiled libraries (as comments (Mo:) >> within your compile instructions (Pa:)): >> >> Pa: Download and run the MinGW installer. Let it download and install >> what >> it needs. >> >> Mo: >> >> - I imagine I have to tell the installer to install g++ and mingw make ? > > Hmm, yes. I wasn't sure but as I recall I ticked those boxes yes. I told > you my notes weren't thorough! no problem, just wanted to make sure. > >> - I imagine you just forgot to mention the install of msys ? > > I mentioned it after pdcurses - don't recall there being any notable > problems with it hence the briefness of the mention! > Sorry, yes. But if I see correctly, pdcurses (already renamed) is in your tar ball. >> Pa: Also install: flex from gnuwin32.sourceforge.net and put flex.exe in >> Mingw bin directory >> >> Mo: Why not flex from mingw ? And all I need to do is copy flex.exe, >> nothing else ? > > I couldn't find flex on the Mingw site. Maybe I was blind. Is it there? > Yes, just putting the flex.exe in the mingw bin directory worked fine for > me. Here: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724&release_id=158862 you see flex and bison for msys (I think this might be the problem with my bison installation: it is for msys and I installed it in the mingw directory - will try again in msys) > >> Pa: Use bison from Mingw as Gnuwin32 bison looks for libintl3.dll >> >> Mo: I did that, but I get this error: >> >> cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or >> directory >> make[3]: *** [y.tab.h] Error 1 >> >> It is in /mingw/share/bison/m4sugar/m4sugar.m4. I don't know why it is >> looking for it in msys ? This causes an error in the compilation of >> libvect and so many consequent errors. > > Ah OK. I think I hacked about with that a little bit come to think of it. > Just put it where it's looking for it ;) I'll try as mentioned above. If that doesn't help, I'll move it around. > >> Mo: What about the shared files from proj, such as epsg (in share >> directory when ./configure&&make&&make install of proj in msys), they >> are >> not in your tarball > > Good point. I should think there is only that one file affected by that > though. Shared files needed by PROJ and GDAL are generally included with > GRASS. See earlier discussions on the mailing list today about that EPSG > file. Ok, so I'll ignore this for now. > >> Mo: during compilation, I get many errors concerning unfindable >> libz.dll.1.2.3; apparently program tries to launch db.* grass exe files >> such as db.columns, etc during compilation. Don't know why. >> After copying all files from c:\forgrass\lib to >> c:\grasssrc\grass6\dist*\lib no more error messages during compilation. >> You mention copying these after compilation. What am I doing wrong ? > > Just make sure c:\forgrass\lib is in your PATH before you start compiling > and it should be fine. I copy them after compilation just to have > everything self-contained for distributing it to others. As long as the > DLLs are on your system and in the PATH everything should work. Ok, will try that. > > Also you need to change man/Makefile so it doesn't convert the HTML pages > to man. The Makefile should be conditionalised so this is dependent on > Perl being installed. Will look at it later. Yes, saw an error on that. Will try to figure out how to change the makefile. Thanks ! Moritz From grass-bugs at intevation.de Wed Dec 13 17:00:40 2006 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Dec 13 17:00:43 2006 Subject: [GRASS-dev] [bug #5384] (grass) r.series point of increase in time-series Message-ID: <20061213160040.D93B91005BE@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5384 ------------------------------------------------------------------------- Subject: r.series point of increase in time-series Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: cvs Hello, currently it is possible to do an analysis of steepest increase/decrease of a time-series manually using r.series: ts1, ts2, ts3, ts4, ts5, ts6 r.series input=ts1,ts2,ts3 output=ts123 method=slope r.series input=ts2,ts3,ts4 output=ts234 method=slope ... r.series input=ts4,ts5,ts6 output=ts456 method=slope then r.series input=ts123,ts234,...,ts456 output=ts_increase method=raster_max but it becomes quite laborious if the time-series holds many steps. It would be great to have an option method=increase/decrease with the option how many time-steps should be analysed for slope (ts1,ts2,ts3 or ts1,ts2,ts3,ts4,ts5). regards, Martin -------------------------------------------- Managed by Request Tracker From neteler at itc.it Wed Dec 13 17:26:55 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Dec 13 17:26:57 2006 Subject: [GRASS-dev] terminology fixes in GRASS Message-ID: <20061213162655.GG13009@bartok.itc.it> Hi, I have made a global fix to terminology in GRASS for consistency. This basically affects messages, some comments and the HTML pages: raster file(s) -> raster map(s) vector file(s) -> vector map(s) The same thing should be done now for raster3d where we have a mixture of 3d grid file 3d grid map 3d cell ... What's your suggestion for this? Markus From morten at untamo.net Wed Dec 13 17:44:17 2006 From: morten at untamo.net (Morten Hulden) Date: Wed Dec 13 17:44:22 2006 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <17784.51544.421727.643216@cerise.gclements.plus.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> Message-ID: <45802DE1.6040908@untamo.net> Glynn Clements wrote: > Maciej Sieczka wrote: > >>> Is this a problem with large files that I will just have to work around or >>> is it something to do with my setup? >> Propably the same, very old issue: >> http://intevation.de/rt/webrt?serial_num=241 > > I looked into this a while ago. Unfortunately, you can't use rowio (or > a home-grown equivalent), as libgis doesn't allow the projection to be > changed while maps are open. So, you have to read the entire input > map, close it, change the projection, then write the output map. > > To get around the memory issues, you would first need to copy the > relevant portion of the input map to a temporary file, then use a > cache backed by that file. > > The segment library would do the job, although it could add a > significant performance overhead. Are you sure it would help for all possible projections? The way r.proj works -- reverse-projecting cell-by-cell into the input map and looking up the value of the nearest neighbor cell (default method) -- it seems difficult to always have the right "relevant part" of the input map in memory. Between two cylindrical projections perhaps, but for other types wouldn't there be a lot of swapping in and out of memory of the "relevant parts". Hmm... I guess this is what you mean with performance overhead. Morten From michael.barton at asu.edu Wed Dec 13 17:50:53 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 13 17:51:42 2006 Subject: [GRASS-dev] Maris Nariss contribution Message-ID: I want to say that the commits I did yesterday for GRASS startup were done by Maris Nariss. He should get credit for these improvements. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061213/c7a3aaa5/attachment.html From michael.barton at asu.edu Wed Dec 13 18:01:39 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 13 18:02:22 2006 Subject: [GRASS-dev] Re: North Arrow updates In-Reply-To: <20061213185407.583d73e8.hamish_nospam@yahoo.com> Message-ID: OK. I'll work on this later today. Michael On 12/12/06 10:54 PM, "Hamish" wrote: > Michael Barton wrote: >> It seems like a good idea to be able to set the text >> size too. Is there a variable/command to do this? > > grab the font control from panel_label.tcl > > > lib/ogsf/gsd_objs.c: > /************************************************************** > * Function to draw North Arrow takes OpenGL coords and size > *************************************************************/ > int gsd_north_arrow (float *pos2, float len, GLuint fontbase, > unsigned long arw_clr, unsigned long text_clr) { > > So yes, there is C support for setting a dynamic font. > > > Right now the nviz north arrow and scale text is hardcoded as 18pt > in nviz/src/draw.c: > FontBase = load_font(TOGL_BITMAP_HELVETICA_18); > > but > > nviz/src/label.c uses the same thing to set the font from the controls: > > sprintf(font, "%s", argv[2]); > size = (int) atoi(argv[3]); > .. > /* Print the label */ > FontBase = load_font(font); > > which are the second and third arguments passed to Nplace_label > ($font and $Nv_(labelFontSize)). So mimic panel_label and then it's just > a quick modification to draw.c to use the variable value instead of the > hardcoded one. > > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From neteler at itc.it Wed Dec 13 18:09:01 2006 From: neteler at itc.it (Markus Neteler) Date: Wed Dec 13 18:09:03 2006 Subject: [GRASS-dev] Re: mkdir function In-Reply-To: <17784.705.539266.65270@cerise.gclements.plus.com> References: <20061207000222.0fac9d71.hamish_nospam@yahoo.com> <750967.20744.qm@web36105.mail.mud.yahoo.com> <20061207190509.7cb02b3b.hamish_nospam@yahoo.com> <4577C941.7000507@itc.it> <20061207212811.7cd96866.hamish_nospam@yahoo.com> <4577F127.9000204@itc.it> <17784.705.539266.65270@cerise.gclements.plus.com> Message-ID: <20061213170901.GI13009@bartok.itc.it> On Thu, Dec 07, 2006 at 12:02:09PM +0000, Glynn Clements wrote: > Markus Neteler wrote: ... > > Probably a search/replace of ' mkdir' would do, using G_mkdir() from > > ./lib/gis/paths.c > > ? Or we need to modify G_mkdir() to accepts two parameters. > > No, G_mkdir() is fine. > > On Unix, the mode argument should always be 0777, so the user has > complete control of the permissions via their umask; anything which > uses a more restrictive mode is second-guessing the user. > > The only programs which should be setting permissions explicitly are > those which provide some other mechanism for the user to control the > permissions. I have done the changes to G_mkdir() accordingly. Also added a G_lstat() in lib/gis/paths.c for a similar problem. Find attached a diff for review. The following 3 functions are too complicated for me (!) to fix: G_mkdir TODOS: lib/g3d/g3dwindowio.c lib/gis/mapset_msc.c lib/raster/io_fifo.c Feedback welcome, Markus -------------- next part -------------- Index: general/manage/lib/do_copy.c =================================================================== RCS file: /grassrepository/grass6/general/manage/lib/do_copy.c,v retrieving revision 1.9 diff -u -r1.9 do_copy.c --- general/manage/lib/do_copy.c 18 Mar 2006 11:04:16 -0000 1.9 +++ general/manage/lib/do_copy.c 13 Dec 2006 17:03:15 -0000 @@ -9,11 +9,6 @@ #include #include "list.h" -#ifdef __MINGW32__ -#define mkdir(name, mode) mkdir(name) -#define lstat(path, sb) stat(path, sb) -#endif - static int recursive_copy(const char *src, const char *dst); /* @@ -119,13 +114,13 @@ size_t len, len2; mode_t mode; - if(lstat(src, &sb)) + if(G_lstat(src, &sb)) return 1; /* src is a file */ if(!S_ISDIR((mode = sb.st_mode))) { - if(!lstat(dst, &sb) && S_ISDIR(sb.st_mode)) + if(!G_lstat(dst, &sb) && S_ISDIR(sb.st_mode)) { const char *p = strrchr(src, '/'); /* src => dst/src */ @@ -156,15 +151,15 @@ /* src is a directory */ - if(lstat(dst, &sb)) + if(G_lstat(dst, &sb)) { - if(mkdir(dst, mode & 0777)) + if(G_mkdir(dst)) return 1; }else /* if dst already exists and it's a file, try to remove it */ if(!S_ISDIR(sb.st_mode)) { - if(remove(dst) || mkdir(dst, mode & 0777)) + if(remove(dst) || G_mkdir(dst)) return 1; } Index: lib/db/dbmi_driver/d_mkdir.c =================================================================== RCS file: /grassrepository/grass6/lib/db/dbmi_driver/d_mkdir.c,v retrieving revision 1.6 diff -u -r1.6 d_mkdir.c --- lib/db/dbmi_driver/d_mkdir.c 9 Feb 2006 03:08:55 -0000 1.6 +++ lib/db/dbmi_driver/d_mkdir.c 13 Dec 2006 17:03:16 -0000 @@ -37,13 +37,8 @@ if (db_isdir(path) == DB_OK) return DB_OK; -#ifdef __MINGW32__ - if (mkdir (path) == 0) + if (G_mkdir (path) == 0) return DB_OK; -#else - if (mkdir (path, mode) == 0) - return DB_OK; -#endif db_syserror(path); Index: lib/gis/remove.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/remove.c,v retrieving revision 2.4 diff -u -r2.4 remove.c --- lib/gis/remove.c 4 Apr 2006 09:27:13 -0000 2.4 +++ lib/gis/remove.c 13 Dec 2006 17:03:16 -0000 @@ -21,10 +21,6 @@ #include #include -#ifdef __MINGW32__ -#define lstat(path, sb) stat(path, sb) -#endif - static int recursive_remove(const char *path); /*! @@ -76,7 +72,7 @@ struct stat sb; char path2[4096]; - if(lstat(path, &sb)) + if(G_lstat(path, &sb)) return 1; if(!S_ISDIR(sb.st_mode)) return remove(path) == 0 ? 0 : 1; Index: lib/gis/unix_socks.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/unix_socks.c,v retrieving revision 1.8 diff -u -r1.8 unix_socks.c --- lib/gis/unix_socks.c 9 Feb 2006 03:08:56 -0000 1.8 +++ lib/gis/unix_socks.c 13 Dec 2006 17:03:16 -0000 @@ -81,9 +81,9 @@ sprintf (path, "%s-%s-%s", prefix, user, lock); - if ((status = lstat (path, &theStat)) != 0) + if ((status = G_lstat (path, &theStat)) != 0) { - status = mkdir (path, S_IRWXU); + status = G_mkdir (path); } else { Index: lib/gis/user_config.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/user_config.c,v retrieving revision 2.5 diff -u -r2.5 user_config.c --- lib/gis/user_config.c 7 Jul 2006 10:16:35 -0000 2.5 +++ lib/gis/user_config.c 13 Dec 2006 17:03:16 -0000 @@ -39,10 +39,6 @@ #include #include -#ifdef __MINGW32__ -# define mkdir(name, mode) ((mkdir) (name)) -#endif - /************************************************************************** * _make_toplevel(): make user's toplevel config directory if it doesn't * already exist. Adjust perms to 1700. Returns the toplevel directory @@ -90,14 +86,14 @@ sprintf (path, "%s%s", my_passwd->pw_dir, "/.grass"); #endif - status = lstat (path, &buf); + status = G_lstat (path, &buf); /* If errno == ENOENT, the directory doesn't exist */ if (status != 0) { if (errno == ENOENT) { - status = mkdir (path, S_IRWXU); /* drwx------ */ + status = G_mkdir (path); if (status != 0) /* mkdir failed */ { @@ -245,11 +241,11 @@ { sprintf (path, "%s/%s", top, cp); errno = 0; - status = lstat (path, &buf); + status = G_lstat (path, &buf); if (status != 0) { /* the element doesn't exist */ - status = mkdir (path, S_IRWXU); /* drwx------ */ + status = G_mkdir (path); if (status != 0) { /* Some kind of problem... */ Index: lib/gis/win32_pipes.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/win32_pipes.c,v retrieving revision 2.3 diff -u -r2.3 win32_pipes.c --- lib/gis/win32_pipes.c 14 Feb 2006 09:02:57 -0000 2.3 +++ lib/gis/win32_pipes.c 13 Dec 2006 17:03:16 -0000 @@ -64,9 +64,9 @@ path = G_malloc (len); sprintf (path, "%s%s", prefix, user); - if ((status = lstat (path, &theStat)) != 0) + if ((status = G_lstat (path, &theStat)) != 0) { - status = mkdir ( path ); + status = G_mkdir ( path ); } else { Index: lib/init/mke_mapset.c =================================================================== RCS file: /grassrepository/grass6/lib/init/mke_mapset.c,v retrieving revision 2.5 diff -u -r2.5 mke_mapset.c --- lib/init/mke_mapset.c 27 Oct 2006 22:27:00 -0000 2.5 +++ lib/init/mke_mapset.c 13 Dec 2006 17:03:16 -0000 @@ -10,10 +10,6 @@ #include -#ifdef __MINGW32__ -# define mkdir(name, mode) ((mkdir) (name)) -#endif - int make_mapset (char *location, char *mapset) { char buffer[2048] ; @@ -22,7 +18,7 @@ /* create the mapset directory */ sprintf(buffer,"%s/%s",location, mapset) ; - mkdir(buffer, 0777) ; + G_mkdir(buffer) ; /* give the mapset a default window for the entire location */ sprintf(buffer,"cat '%s'/PERMANENT/DEFAULT_WIND > '%s'/'%s'/WIND", @@ -42,7 +38,7 @@ /* Make the dbf/ subdirectory */ sprintf( buffer, "%s/%s/dbf", location, mapset ); - if( mkdir( buffer, 0777 ) != 0 ) + if( G_mkdir( buffer ) != 0 ) return -1; return(0) ; Index: raster/r.le/r.le.patch/main.c =================================================================== RCS file: /grassrepository/grass6/raster/r.le/r.le.patch/main.c,v retrieving revision 2.6 diff -u -r2.6 main.c --- raster/r.le/r.le.patch/main.c 17 Oct 2006 12:03:22 -0000 2.6 +++ raster/r.le/r.le.patch/main.c 13 Dec 2006 17:03:17 -0000 @@ -146,7 +146,7 @@ r.le.out subdirectory */ if (choice->wrum != 'm') - G_system("mkdir r.le.out"); + G_mkdir("r.le.out"); patch_fore(); G_free(choice); Index: raster/r.le/r.le.pixel/main.c =================================================================== RCS file: /grassrepository/grass6/raster/r.le/r.le.pixel/main.c,v retrieving revision 2.7 diff -u -r2.7 main.c --- raster/r.le/r.le.pixel/main.c 19 Oct 2006 04:22:44 -0000 2.7 +++ raster/r.le/r.le.pixel/main.c 13 Dec 2006 17:03:17 -0000 @@ -120,7 +120,7 @@ r.le.out subdirectory */ if (choice->wrum != 'm') - G_system("mkdir r.le.out"); + G_mkdir("r.le.out"); texture_fore(); G_free (choice); Index: raster/r.le/r.le.setup/main.c =================================================================== RCS file: /grassrepository/grass6/raster/r.le/r.le.setup/main.c,v retrieving revision 2.11 diff -u -r2.11 main.c --- raster/r.le/r.le.setup/main.c 19 Oct 2006 04:22:45 -0000 2.11 +++ raster/r.le/r.le.setup/main.c 13 Dec 2006 17:03:17 -0000 @@ -134,7 +134,7 @@ DIR *dp; if(!(dp = opendir("r.le.para"))) - G_system("mkdir r.le.para"); + G_mkdir("r.le.para"); else closedir(dp); return; Index: raster/r.li/r.li.daemon/daemon.c =================================================================== RCS file: /grassrepository/grass6/raster/r.li/r.li.daemon/daemon.c,v retrieving revision 1.4 diff -u -r1.4 daemon.c --- raster/r.li/r.li.daemon/daemon.c 13 Dec 2006 14:21:40 -0000 1.4 +++ raster/r.li/r.li.daemon/daemon.c 13 Dec 2006 17:03:18 -0000 @@ -117,11 +117,11 @@ /*check if ~/.r.li/output exist*/ sprintf(out, "%s/.r.li/", getenv("HOME")); - doneDir = mkdir(out, 0755); + doneDir = G_mkdir(out); if (doneDir == -1 && errno != EEXIST) G_fatal_error( _("Cannot create .r.li directory")); sprintf(out, "%s/.r.li/output", getenv("HOME")); - doneDir = mkdir(out, 0755); + doneDir = G_mkdir(out); if (doneDir == -1 && errno != EEXIST) G_fatal_error( _("Cannot create .r.li/output directory")); sprintf(out, "%s/.r.li/output/%s", getenv("HOME"), output); From michael.barton at asu.edu Wed Dec 13 18:15:19 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 13 18:15:27 2006 Subject: [GRASS-dev] v.edit updates In-Reply-To: <20061213101759.GA10904@localdomain> Message-ID: Jachym, Because we need to have a digitizing tool that works without x11, I'm in favor of moving ahead with v.edit since it is by far the most advanced attempt to get this rolling so far. I haven't had time to review and test it however. Michael On 12/13/06 3:17 AM, "Jachym Cepicky" wrote: > Hallo, > since nobody answared, I suppose there nobody had enough time to check > the patches. > > Before I move with further development, I would like to hear from the > GRASS-core developers, that this changes are all right and worth to be > committed to cvs. > I did not commit this changes yet, because of they are changing behavior > and features of v.edit significantly. > > Removed options: > type - there is no need to define type of the vector input feature, > this can be done using other methods (grass ascii format) > values - all database updates should be done via db.* commands > > Changes options: > coords - coords were used for data inputs. But it could come to > maximum length of a line limit. > coords option is used for feature identification, not for > data input > action->tool - IMHO "tool" does fit idea of the option better, than > action > > tools: merge - removed > new tools introduced > > Added options: > to - moving to coordinates > at - breaking/spliting at this coordinates > bbox - for bounding box feature selection > about - (not added yet) for moving features +- map units > > How to test this: > This commands should give you impression about how v.edit currently > works: > > # copy soils map > g.copy vect=soils,tmp --o > d.mon x0 > d.vect tmp > > # add new line the soils map > echo "L 2 1 > 593229.5625 4917307.3125 > 606824.0625 4926102 > 1 60" | v.edit map=tmp tool=add > > v.build tmp > echo "insert into tmp (cat, label) values (60,'road');"|db.execute > d.redraw > > # remove feature defined by coordinates > v.edit map=tmp tool=delete coords=593229.5625,4917307.3125 > d.redraw # line should be removed > > # remove feature defined by category > v.edit map=tmp tool=delete cat=13 > d.redraw # big soil area on south should be removed > > # remove featuers defined by bounding box > d.graph -m color=0:255:0 << EOF > width 4 > polyline > 602203.125 4918112.25 > 602203.125 4924402.6875 > 604319.8125 4924402.6875 > 604319.8125 4918112.25 > 602203.125 4918112.25 > EOF > > v.edit map=tmp tool=delete bbox=602203.125,4918112.25,604319.8125,4924402.6875 > d.redraw > > I prepared new patch (attached). If there will be no provisos, I would > like to add this to cvs soon and continue with the development. > > Thank you > > Jachym > > On Tue, Dec 12, 2006 at 02:41:42PM +0100, Jachym Cepicky wrote: >> Hallo, >> according to suggested funtion of v.edit [1], I started to work on >> v.edit module. >> >> I prepared patch for this and it would be great, if anybody could look >> at it and say, if it is worth to commit to cvs. >> >> Currently, only tools "delete" and "add" are supported. But they cand be >> used on slightly different way: >> >> With this patch, v.edit no longer accepts input in form of comma >> separated list of coordinates, but it reads input (tools "create" and >> "add") from stdin or from ASCII file. I used a2b.c file from v.in.ascii >> for this purpose. Currently, it does not accept header of the vector >> file, so v.out.ascii vect|v.edit tool=add would not work. >> >> For "tool=remove", new ways for feature definition are defined: >> >> coords=x,y - remove feature, which can be found on coordinates x,y >> >> cats=3,4 - remove reature with category 3 or 4 >> >> bbox=x1,y1,x2,y2 - remove features in bounding box >> >> If everything will be all right, I'll continue on v.edit with moving and >> spliting tools >> >> Looking forward to your feedback >> >> Jachym >> >> [1] http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool#v.edit >> -- >> Jachym Cepicky >> e-mail: jachym.cepicky@centrum.cz >> URL: http://les-ejk.cz >> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub >> ----------------------------------------- >> OFFICE: >> Department of Geoinformation Technologies >> Zemedelska 3 >> 613 00, Brno >> Czech Republick >> e-mail: xcepicky@node.mendelu.cz >> URL: http://mapserver.mendelu.cz >> Tel.: +420 545 134 514 > >> Index: vector/v.edit/a2b.c >> =================================================================== >> RCS file: vector/v.edit/a2b.c >> diff -N vector/v.edit/a2b.c >> --- /dev/null 1 Jan 1970 00:00:00 -0000 >> +++ vector/v.edit/a2b.c 12 Dec 2006 13:29:22 -0000 >> @@ -0,0 +1,171 @@ >> +/* >> + * This file has been adopted from v.in.ascii code >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include "global.h" >> + >> +#define BUFFSIZE 128 >> + >> +int asc_to_bin(FILE *ascii , struct Map_info *Map) >> +{ >> + char ctype ; >> + char buff[BUFFSIZE]; >> + double *xarray ; >> + double *yarray ; >> + double *zarray ; >> + double *x, *y, *z; >> + int i, n_points, n_coors, n_cats ; >> + int type; >> + int alloc_points ; >> + int end_of_file ; >> + struct line_pnts *Points; >> + struct line_cats *Cats; >> + int catn; >> + int cat; >> + >> + /* Must always use this to create an initialized line_pnts structure */ >> + Points = Vect_new_line_struct (); >> + Cats = Vect_new_cats_struct (); >> + >> + end_of_file = 0 ; >> + /*alloc_points = 1000 ; */ >> + alloc_points = 1; >> + xarray = (double *) G_calloc(alloc_points, sizeof(double)) ; >> + yarray = (double *) G_calloc(alloc_points, sizeof(double)) ; >> + zarray = (double *) G_calloc(alloc_points, sizeof(double)) ; >> + >> + while( G_getl2(buff,BUFFSIZE-1,ascii) != 0 ) >> + { >> + n_cats=0; >> + if (buff[0] == '\0') { >> + G_debug(3, "a2b: skipping blank line"); >> + continue; >> + } >> + >> + if ( sscanf(buff, "%1c%d%d", &ctype, &n_coors, &n_cats) < 2 || >> n_coors < 0 || n_cats < 0 ) { >> + if (ctype == '#') { >> + G_debug(2, "a2b: skipping commented line"); >> + continue; >> + } >> + G_warning (_("Error reading ascii file <%s>"), buff) ; >> + return 0; >> + } >> + if (ctype == '#') { >> + G_debug(2, "a2b: Skipping commented line"); >> + continue; >> + } >> + >> + switch(ctype){ >> + case 'A': >> + type = GV_BOUNDARY ; >> + break ; >> + case 'B': >> + type = GV_BOUNDARY ; >> + break ; >> + case 'C': >> + type = GV_CENTROID ; >> + break ; >> + case 'L': >> + type = GV_LINE ; >> + break ; >> + case 'P': >> + type = GV_POINT ; >> + break ; >> + case 'F': >> + type = GV_FACE ; >> + break ; >> + case 'K': >> + type = GV_KERNEL ; >> + break ; >> + case 'a': >> + case 'b': >> + case 'c': >> + case 'l': >> + case 'p': >> + type = 0; /* dead -> ignore */ >> + break; >> + default: >> + G_warning (_("Error reading ascii file: <%s>"), buff) ; >> + return 0; >> + } >> + G_debug(5, "feature type = %d", type); >> + >> + n_points = 0 ; >> + x = xarray ; >> + y = yarray ; >> + z = zarray ; >> + >> + /* Collect the points */ >> + for( i=0; i> + { >> + if ( G_getl2(buff,BUFFSIZE-1,ascii) == 0 ) { >> + G_warning (_("End of ascii file reached before end of coordinates")) ; >> + return 0; >> + } >> + if (buff[0] == '\0') { >> + G_debug(3, "a2b: skipping blank line while reading vertices"); >> + i--; >> + continue; >> + } >> + >> + *z=0; >> + if ( sscanf(buff, "%lf%lf%lf", x, y, z) < 2 ) { >> + G_warning (_("Error reading ascii file: <%s>"), buff) ; >> + return 0; >> + } >> + G_debug( 5, "coor in: %s -> x = %f y = %f z = %f", G_chop(buff), *x, >> *y, *z); >> + >> + n_points++; >> + x++; >> + y++; >> + z++; >> + >> + if (n_points >= alloc_points) >> + { >> + alloc_points = n_points + 1000 ; >> + xarray = (double *) G_realloc((void *)xarray, alloc_points * >> sizeof(double) ); >> + yarray = (double *) G_realloc((void *)yarray, alloc_points * >> sizeof(double) ); >> + zarray = (double *) G_realloc((void *)zarray, alloc_points * >> sizeof(double) ); >> + x = xarray + n_points ; >> + y = yarray + n_points ; >> + z = zarray + n_points ; >> + } >> + } >> + >> + /* Collect the cats */ >> + for( i=0; i> + { >> + if ( G_getl2(buff,BUFFSIZE-1,ascii) == 0 ) { >> + G_warning (_("End of ascii file reached before end of categories.")) ; >> + return 0; >> + } >> + if (buff[0] == '\0') { >> + G_debug(3, "a2b: skipping blank line while reading category info"); >> + i--; >> + continue; >> + } >> + >> + if ( sscanf(buff, "%u%u", &catn, &cat) != 2 ) { >> + G_warning (_("Error reading categories: <%s>"), buff) ; >> + return 0; >> + } >> + Vect_cat_set ( Cats, catn, cat ); >> + } >> + >> + /* Allocation is handled for line_pnts */ >> + if (0 > Vect_copy_xyz_to_pnts (Points, xarray, yarray, zarray, >> n_points)) >> + G_fatal_error(_("Out of memory")); >> + >> + if ( type > 0 ) >> + Vect_write_line ( Map, type, Points, Cats ); >> + >> + Vect_reset_cats ( Cats ); >> + } >> + return 0; >> +} >> + >> Index: vector/v.edit/args.c >> =================================================================== >> RCS file: /grassrepository/grass6/vector/v.edit/args.c,v >> retrieving revision 1.6 >> diff -u -r1.6 args.c >> --- vector/v.edit/args.c 7 Jun 2006 19:16:16 -0000 1.6 >> +++ vector/v.edit/args.c 12 Dec 2006 13:29:22 -0000 >> @@ -4,48 +4,74 @@ >> { >> map_opt = G_define_standard_option(G_OPT_V_MAP); >> >> - act_opt = G_define_option(); >> - act_opt->key = "action"; >> - act_opt->type = TYPE_STRING; >> - act_opt->required = YES; >> - act_opt->multiple = NO; >> - act_opt->description = _("The edit action to take."); >> - act_opt->options = "create,add,delete,move,merge"; >> - >> - typ_opt = G_define_standard_option(G_OPT_V_TYPE); >> - typ_opt->required = NO; >> - typ_opt->description = _("Select type. Required for add action."); >> - typ_opt->options = "point,line,area,centroid,boundary"; >> - typ_opt->answer = "point"; >> - >> + tool_opt = G_define_option(); >> + tool_opt->key = "tool"; >> + tool_opt->type = TYPE_STRING; >> + tool_opt->required = YES; >> + tool_opt->multiple = NO; >> + tool_opt->description = _("The edit tool to take.\n" >> + "\t\tcreate - Create new vector file\n" >> + "\t\tadd - Add new vector feature to >> existing vector file\n" >> + "\t\tdelete - Delete feature from vector >> file\n" >> + "\t\tmove - Move feature in vector file\n" >> + "\t\tvertex - Move just only vertex\n" >> + "\t\tbreak - Add new vertex to existing vector >> line\n" >> + "\t\tsplit - Split line into two separate >> lines"); >> + tool_opt->options = "create,add,delete,move,vertex,break,split"; >> + >> + input_opt = G_define_option(); >> + input_opt->key = "input"; >> + input_opt->type = TYPE_STRING; >> + input_opt->required = NO; >> + input_opt->multiple = NO; >> + input_opt->description = _("ASCII file to be converted to binary vector >> file, if not given reads from standard input"); >> + >> cat_opt = G_define_standard_option(G_OPT_V_CATS); >> cat_opt->required = NO; >> >> - pnt_opt = G_define_option(); >> - pnt_opt->key = "coords"; >> - pnt_opt->key_desc = "x,y"; >> - pnt_opt->type = TYPE_DOUBLE; >> - pnt_opt->required = NO; >> - pnt_opt->multiple = YES; >> - pnt_opt->description = _("An x,y list of points. Required for add and >> move actions."); >> - >> - val_opt = G_define_option(); >> - val_opt->key = "values"; >> - val_opt->type = TYPE_STRING; >> - val_opt->required = NO; >> - val_opt->multiple = NO; >> - val_opt->description = _("A comma-separated list of attr=val pairs."); >> - >> + coord_opt = G_define_option(); >> + coord_opt->key = "coords"; >> + coord_opt->key_desc = "x,y"; >> + coord_opt->type = TYPE_DOUBLE; >> + coord_opt->required = NO; >> + coord_opt->multiple = YES; >> + coord_opt->description = _("An x,y list of points. Required for add and >> move actions."); >> + >> + to_opt = G_define_option(); >> + to_opt->key = "to"; >> + to_opt->key_desc = "x,y"; >> + to_opt->type = TYPE_DOUBLE; >> + to_opt->required = NO; >> + to_opt->multiple = NO; >> + to_opt->description = _("An x,y location of selected feature"); >> + >> + at_opt = G_define_option(); >> + at_opt->key = "at"; >> + at_opt->key_desc = "x,y"; >> + at_opt->type = TYPE_DOUBLE; >> + at_opt->required = NO; >> + at_opt->multiple = NO; >> + at_opt->description = _("An x,y location of breaking feature"); >> + >> + bbox_opt = G_define_option(); >> + bbox_opt->key = "bbox"; >> + bbox_opt->key_desc = "x1,y1,x2,y2"; >> + bbox_opt->type = TYPE_DOUBLE; >> + bbox_opt->required = NO; >> + bbox_opt->multiple = NO; >> + bbox_opt->description = _("Bounding box of selected feature"); >> + >> + snap_opt = G_define_option(); >> + snap_opt->key = "snap"; >> + snap_opt->type = TYPE_DOUBLE; >> + snap_opt->required = NO; >> + snap_opt->multiple = NO; >> + snap_opt->description = _("Object points will snap to existing points >> within snap units."); >> + snap_opt->answer = "5.0"; >> + >> + >> fld_opt = G_define_standard_option(G_OPT_V_FIELD); >> >> - snp_opt = G_define_option(); >> - snp_opt->key = "snap"; >> - snp_opt->type = TYPE_DOUBLE; >> - snp_opt->required = NO; >> - snp_opt->multiple = NO; >> - snp_opt->description = _("Object points will snap to existing points >> within snap units."); >> - snp_opt->answer = "5.0"; >> - >> t_flg = G_define_flag(); >> t_flg->key = 't'; >> t_flg->description = _("Do not use topology."); >> @@ -62,59 +88,136 @@ >> c_flg->key = 'c'; >> c_flg->description = _("Do not close boundaries"); >> >> + n_flg = G_define_flag(); >> + n_flg->key = 'n'; >> + n_flg->description = _("Don't expect a header"); >> + >> if(G_parser(argc, argv)) >> return 0; >> >> /* check that the given arguments makes sense together*/ >> /** @todo check for incorrect extra parameters */ >> >> - if(strcmp(act_opt->answer, "create")==0) { /* create requires nothing >> extra*/ >> + if ( input_opt->answer != NULL ) { >> + if ( (ascii = fopen ( input_opt->answer, "r" ) ) == NULL ) >> + { >> + G_warning(_("Could not open ascii file <%s>"), >> input_opt->answer); >> + G_usage(); >> + } >> + } else { >> + ascii = stdin; >> + } >> + >> + /* check for coordinate param */ >> + if (coord_opt->answers != NULL) { >> + int i = 0; >> + for (i = 0; coord_opt->answers[i]; i ++) >> + ; >> + if (i%2 != 0) { >> + G_warning(_("Number of coordinates must be odd number")); >> + G_usage(); >> + return 0; >> + } >> + >> + } >> + >> + /* check for bbox param */ >> + if (bbox_opt->answers != NULL) { >> + int i = 0; >> + for (i = 0; bbox_opt->answers[i]; i ++) >> + ; >> + if (i%2 != 0) { >> + G_warning(_("Number of coordinates must be odd number")); >> + G_usage(); >> + return 0; >> + } >> + >> + } >> + >> + if(strcmp(tool_opt->answer, "create")==0) { /* create requires nothing >> extra*/ >> action_mode = MODE_CREATE; >> return 1; >> } >> >> - snap = atof(snp_opt->answer); >> - >> - if(strcmp(act_opt->answer, "add")==0) { /* add requires a points >> argument */ >> + if(strcmp(tool_opt->answer, "add")==0) { /* add requires a points >> argument */ >> action_mode = MODE_ADD; >> - if(pnt_opt->answers == NULL) { >> - help(_("Required parameter not set")); >> + return 1; >> + } >> + else if(strcmp(tool_opt->answer, "delete")==0) { /* del requires a cats >> or or bbox or coords*/ >> + action_mode = MODE_DEL; >> + if((cat_opt->answers == NULL) && >> + (coord_opt->answers == NULL) && >> + (bbox_opt->answers == NULL)) { >> + G_warning(_("At least one from <%s> must be specified"),"cats, coords, >> bbox"); >> + G_usage(); >> return 0; >> }; >> return 1; >> } >> - else if(strcmp(act_opt->answer, "delete")==0) { /* del requires a cats >> */ >> - action_mode = MODE_DEL; >> - if(cat_opt->answers == NULL) { >> - help(_("Required parameter not set")); >> + else if(strcmp(tool_opt->answer, "move")==0) { /* move requires coords >> or cats arguments */ >> + action_mode = MODE_MOVE; >> + if(to_opt->answers == NULL) { >> + G_warning(_("For <%s> operation, option <%s> must be >> set"),"move","to"); >> + G_usage(); >> + return 0; >> + } >> + if((coord_opt->answers == NULL) && >> + (cat_opt->answers == NULL) && >> + (bbox_opt->answers == NULL)) { >> + G_warning(_("At least one from <%s> must be specified"),"cats, coords, >> bbox"); >> + G_usage(); >> return 0; >> }; >> return 1; >> } >> - else if(strcmp(act_opt->answer, "move")==0) { /* move requires points >> and cats arguments */ >> - action_mode = MODE_ADD; >> - if((pnt_opt->answers == NULL)||(cat_opt->answers == NULL)) { >> - help(_("Both parameters and are required.")); >> + >> + else if(strcmp(tool_opt->answer, "vertex")==0) { /* move vertex requires >> a coord and to options */ >> + action_mode = MODE_VERTEX; >> + if(coord_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> + return 0; >> + }; >> + if(to_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> return 0; >> }; >> return 1; >> } >> - else if(strcmp(act_opt->answer, "merge")==0) { /* merge requires a cats >> argument */ >> - action_mode = MODE_ADD; >> - if(cat_opt->answers == NULL) { >> - help(_("Required parameter not set")); >> + else if(strcmp(tool_opt->answer, "break")==0) { /* break line requires a >> coord and at options */ >> + action_mode = MODE_BREAK; >> + if(coord_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> + return 0; >> + }; >> + if(at_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> return 0; >> }; >> return 1; >> } >> + else if(strcmp(tool_opt->answer, "split")==0) { /* split line requires a >> coord and at options */ >> + action_mode = MODE_SPLIT; >> + if(coord_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> + return 0; >> + }; >> + if(at_opt->answers == NULL) { >> + G_warning(_("Required parameter not set")); >> + G_usage(); >> + return 0; >> + }; >> + return 1; >> + } >> + >> else { >> - help(_("This should never happen.")); >> + G_warning(_("Operation <%s> not implemented."),tool_opt->answer); >> + G_usage(); >> return 0; >> } >> } >> >> -void help(const char *msg) >> -{ >> - G_message("\nERROR: %s\n\n", msg); >> - G_usage(); >> -} >> Index: vector/v.edit/del.c >> =================================================================== >> RCS file: /grassrepository/grass6/vector/v.edit/del.c,v >> retrieving revision 1.2 >> diff -u -r1.2 del.c >> --- vector/v.edit/del.c 6 Oct 2006 06:47:56 -0000 1.2 >> +++ vector/v.edit/del.c 12 Dec 2006 13:29:23 -0000 >> @@ -2,45 +2,151 @@ >> >> int do_del(struct Map_info *Map) >> { >> - int i; >> + int res = 0; >> + >> + >> + /* cats or coord or bbox */ >> + if(cat_opt->answer != NULL) { >> + >> + res = delete_categories(Map); >> + } >> + else if (coord_opt->answer != NULL) { >> + >> + res = delete_coordinates(Map); >> + } >> + else if (bbox_opt->answer != NULL) { >> + >> + res = delete_bbox(Map); >> + } >> + else { >> + /* this case should not happen, see args.c for details */ >> + G_warning("cats, coord or bbox must be specified"); >> + } >> + >> +} >> + >> +int delete_bbox(struct Map_info *Map) >> +{ >> + double x1,y1,x2,y2; >> + BOUND_BOX bbox; >> + BOUND_BOX feature_bbox; >> + int cat, ret, type, i; >> + struct ilist *List; >> + SPATIAL_INDEX si; >> + struct line_pnts *Points; >> + struct line_cats *Cats; >> + int removed = 0; >> + >> + >> + /* bounding box */ >> + x1 = atof(bbox_opt->answers[0]); >> + y1 = atof(bbox_opt->answers[1]); >> + x2 = atof(bbox_opt->answers[2]); >> + y2 = atof(bbox_opt->answers[3]); >> + bbox.N = y1 < y2 ? y2 : y1; >> + bbox.S = y1 < y2 ? y1 : y2; >> + bbox.W = x1 < x2 ? x1 : x2; >> + bbox.E = x1 < x2 ? x2 : x1; >> + bbox.T = 0.0; >> + bbox.B = 0.0; >> + >> + Points = Vect_new_line_struct(); >> + Cats = Vect_new_cats_struct(); >> + List = Vect_new_list (); >> + >> + /* get lines number */ >> + Vect_select_lines_by_box ( Map, &bbox, GV_POINTS | GV_LINES | >> GV_BOUNDARY | GV_CENTROID, List ); >> + G_debug ( 1, " %d lines selected by box", List->n_values ); >> + >> + for ( i = 0; i < List->n_values; i++) { >> + >> + type = Vect_read_line(Map, Points, Cats, List->value[i]); >> + G_debug(2, "Deleting type [%d] number [%d]", type, List->value[i]); >> + Vect_delete_line(Map, List->value[i]); >> + removed++; >> + /* attr_del(Map, layer, cat);*/ >> + } >> + G_message(_("%d features deleted"), removed); >> + return 1; >> +} >> + >> +int delete_coordinates(struct Map_info *Map) >> +{ >> + double east, north; >> + int line; >> + double maxdist = 0.5; >> + char buff[16] = ""; >> + >> + int type; >> + struct line_pnts *Points; >> + struct line_cats *Cats; >> + int cat; >> + int field=atoi(fld_opt->answer); >> + int removed = 0; >> + >> + east = atof(coord_opt->answers[0]); >> + north = atof(coord_opt->answers[1]); >> + >> + line = Vect_find_line(Map, east, north, 0.0, GV_POINT | GV_CENTROID, >> maxdist, 0, 0); >> + >> + if (line == 0) >> + line = Vect_find_line(Map, east, north, 0.0, GV_LINE | GV_BOUNDARY | >> GV_FACE, maxdist, 0, 0); >> + >> + >> + G_debug (2, "line = %d", line); >> + >> + if (line == 0) { >> + G_warning(_("Nothing Found.")); >> + return 0; >> + >> + } >> + else { >> + type = Vect_read_line(Map, Points, Cats, line); >> + Points = Vect_new_line_struct(); >> + Cats = Vect_new_cats_struct(); >> + if ((cat = Vect_get_line_cat(Map, line, field )) > 0) >> + sprintf(buff,_("category [%d]"),cat); >> + >> + G_debug(2, "Deleting type [%d] number [%d] %s", type, line, buff); >> + Vect_delete_line(Map, line); >> + removed++; >> + >> + /* attr_del(Map, layer, cat);*/ >> + } >> + >> + G_message(_("%d features deleted"), removed); >> + return 1; >> +} >> + >> + >> +int delete_categories(struct Map_info *Map) >> +{ >> + >> struct cat_list * cl; >> int layer=atoi(fld_opt->answer); >> + int i, removed=0; >> >> - G_debug(1,"layer = %d",layer); >> -/* >> - if(cat_opt->answer=NULL) { >> - cats = coords_catlist(Map); >> - } >> - */ >> cl = Vect_new_cat_list(); >> Vect_str_to_cat_list(cat_opt->answer, cl); >> - >> + >> + G_debug(1,"layer = %d",layer); >> + >> for(i=0;in_ranges;i++) { >> int cat, type, id, ret; >> G_debug(1, "cl->min[%d]=%d, cl->max[%d]=%d, layer=%d", >> i, cl->min[i], i, cl->max[i], cl->field); >> for(cat=cl->min[i]; cat <= cl->max[i]; cat++) { >> - ret = Vect_cidx_find_next(Map, layer, cat, GV_POINTS|GV_LINES, >> + ret = Vect_cidx_find_next(Map, layer, cat, GV_POINTS|GV_LINES | >> GV_BOUNDARY | GV_CENTROID, >> 0, &type, &id); >> G_debug(1, "ret=%d", ret); >> if(ret<0) continue; >> - G_debug(1, "Found something to delete: id=%d, type=%d",id,type); >> - if(type==GV_CENTROID) { >> - int area; >> - double x,y; >> - Vect_get_node_coor(Map, id, &x, &y, NULL); >> - area = Vect_find_area(Map, x, y); >> - G_debug(1, "Deleteing area %d: id=%d, area=%d",cat,id,area); >> -/* Vect_delete_line(Map, id); */ >> -/* Vect_delete_line(Map, area); */ >> - attr_del(Map, layer, cat); >> - } >> - else { >> -/* Vect_delete_line(Map, id); */ >> - attr_del(Map, layer, cat); >> - } >> + G_debug(2,"Deleting type [%d] number [%d] cat [%d]", type, id, >> cat); >> + Vect_delete_line(Map, id); >> + /* attr_del(Map, layer, cat);*/ >> + removed ++; >> } >> } >> + G_message(_("%d features deleted"), removed); >> >> return 1; >> } >> Index: vector/v.edit/global.h >> =================================================================== >> RCS file: /grassrepository/grass6/vector/v.edit/global.h,v >> retrieving revision 1.6 >> diff -u -r1.6 global.h >> --- vector/v.edit/global.h 7 Jun 2006 19:16:16 -0000 1.6 >> +++ vector/v.edit/global.h 12 Dec 2006 13:29:23 -0000 >> @@ -18,15 +18,18 @@ >> MODE_ADD, >> MODE_DEL, >> MODE_MOVE, >> - MODE_MERGE >> + MODE_VERTEX, >> + MODE_SPLIT, >> + MODE_BREAK >> }; >> >> -void help(const char *msg); >> int parser(int argc, char*argv[]); >> >> -int do_add(struct Map_info *Map); >> +int asc_to_bin(FILE *, struct Map_info *); >> int do_del(struct Map_info *Map); >> - >> +int delete_categories(struct Map_info *Map); >> +int delete_coordinates(struct Map_info *Map); >> +int delete_bbox(struct Map_info *Map); >> >> void cat_max_set ( int field, int cat); >> int cat_max_get ( int field ); >> @@ -37,11 +40,12 @@ >> int attr_edit(struct Map_info *Map, int field, int cat, const char *vals); >> int attr_del(struct Map_info *Map, int field, int cat); >> >> -global struct Option *map_opt, *act_opt, *typ_opt, *cat_opt, *pnt_opt, >> *fld_opt, *val_opt, *snp_opt; >> -global struct Flag *n_flg, *t_flg, *d_flg, *b_flg, *c_flg; >> +global struct Option *input_opt, *map_opt, *tool_opt, *coord_opt, *cat_opt, >> *to_opt, *at_opt, *bbox_opt, *snap_opt, *fld_opt; >> +global struct Flag *n_flg, *t_flg, *d_flg, *b_flg, *c_flg, *n_flg; >> global struct GModule *module; >> global struct Map_info Map; >> global enum mode action_mode; >> global char *mapset; >> -global double snap; >> + >> +global FILE *ascii; >> #endif >> Index: vector/v.edit/main.c >> =================================================================== >> RCS file: /grassrepository/grass6/vector/v.edit/main.c,v >> retrieving revision 1.9 >> diff -u -r1.9 main.c >> --- vector/v.edit/main.c 6 Oct 2006 06:47:56 -0000 1.9 >> +++ vector/v.edit/main.c 12 Dec 2006 13:29:23 -0000 >> @@ -21,6 +21,7 @@ >> >> #define MAIN >> #include "global.h" >> + >> /* static int error_routine(const char*msg, int fatal); */ >> >> int main (int argc, char *argv[]) >> @@ -56,7 +57,6 @@ >> } >> else { >> /* Vect_set_open_level(2); */ >> - G_message(_("Reading vector file ...")); >> Vect_open_update (&Map, map_opt->answer, mapset); >> } >> /* Vect_set_category_index_update ( &Map ); */ >> @@ -66,7 +66,8 @@ >> >> switch(action_mode) { >> case MODE_ADD: >> - ret = do_add(&Map); >> + G_message(_("Adding new features to vector file ...")); >> + ret = asc_to_bin(ascii, &Map) ; >> break; >> case MODE_DEL: >> ret = do_del(&Map); > > > > >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Dec 13 18:32:38 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 13 18:33:32 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: <20061214001022.00bcf732.hamish_nospam@yahoo.com> Message-ID: On 12/13/06 4:10 AM, "Hamish" wrote: > > now locations and mapsets are not sorted in alphabetical order. > :/ > I wonder what changed this? Need to look back at the code. Maris? >> Also, if we are going to have EPSG codes as a standard way to create a >> new location (and I think this is a handy way to go), can we >> distribute a copy of the EPSG file inside the GRASS directory >> structure (e.g., in the infamous catchall etc or another directory)? >> The EPSG file is ending up in different places on different >> architectures making it difficult to find. If it was always in the >> same place, within the GRASS hierarchy, it would be easy to make this >> the default location for the GUI. > > not for, but not strongly against, however: > - The EPSG database and proj.4 are likely to be updated more often than > GRASS is. > - packagers should set --with-proj-share=, ./configure should give a > clear error message if not found for home-brew. Tcl then finds this dir > in the "PROJSHARE" variable. > Point well taken. Still, I'm slightly in favor of including this small file with GRASS to make using what is now an essential tool easier. Even if PROJ is updated regularly, this doesn't mean that GRASS users update their PROJ installation. So it's likely out of sync in many cases anyway. This is a simple text file that is easy to drop into GRASS. But of course, who should be the one to do it so that it doesn't get way out of date. > >> Obviously the next thing to do is to make it searchable. > > yes please, and auto-fill the highlighted value in the create dialogue. > I'm working on that now. I figured that it would be a chore and so had avoided it. It turns out that I was right, but I'm making progress. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From mlennert at club.worldonline.be Wed Dec 13 18:38:27 2006 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Dec 13 18:37:10 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: References: Message-ID: <2210.164.15.134.77.1166031507.squirrel@geog-pc40.ulb.ac.be> On Wed, December 13, 2006 18:32, Michael Barton wrote: >>> Also, if we are going to have EPSG codes as a standard way to create a >>> new location (and I think this is a handy way to go), can we >>> distribute a copy of the EPSG file inside the GRASS directory >>> structure (e.g., in the infamous catchall etc or another directory)? >>> The EPSG file is ending up in different places on different >>> architectures making it difficult to find. If it was always in the >>> same place, within the GRASS hierarchy, it would be easy to make this >>> the default location for the GUI. >> >> not for, but not strongly against, however: >> - The EPSG database and proj.4 are likely to be updated more often than >> GRASS is. >> - packagers should set --with-proj-share=, ./configure should give a >> clear error message if not found for home-brew. Tcl then finds this dir >> in the "PROJSHARE" variable. >> > > Point well taken. Still, I'm slightly in favor of including this small > file > with GRASS to make using what is now an essential tool easier. Even if > PROJ > is updated regularly, this doesn't mean that GRASS users update their PROJ > installation. So it's likely out of sync in many cases anyway. This is a > simple text file that is easy to drop into GRASS. But of course, who > should > be the one to do it so that it doesn't get way out of date. > I have never found it a problem that the user has to define the location of the file if it is not in the default location. So I would rather keep one version in proj than have to update both... Moritz From michael.barton at asu.edu Wed Dec 13 18:40:14 2006 From: michael.barton at asu.edu (Michael Barton) Date: Wed Dec 13 18:47:22 2006 Subject: [GRASS-dev] updates to grass startup In-Reply-To: Message-ID: On 12/13/06 4:46 AM, "Paul Kelly" wrote: > Hello Michael > > On Tue, 12 Dec 2006, Michael Barton wrote: > >> I just committed a set of patches to the GRASS startup tcltk files >> (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to >> make creating a new location from EPSG code or georeferenced file more >> robust. This is especially important for Windows users who cannot make a new >> location with g.proj. > > BTW that is no longer true. g.setproj and etc/set_data work fine on > Windows (better if you have Msys in your path though - I'm working on > replacing a system("ls -C") call). If you click the "projection values" > button in gis_set.tcl it will pop up a Window running set_data so you can > create a location the traditional way. Current problem though is that the > list of locations doesn't refresh to show the new location after you > return from the box. I had a quick look a week or two ago but the design > of gis_set.tcl seemed to make it very difficult to refresh that. Although > if you click after the database directory and press Enter it refreshes. > Maybe you have improved something to make that easier though? This is very good news. The design of gis_set.tcl is difficult overall, because it is pretty old legacy code. I'm not sure there is an easy way to do an automatic refresh after returning from the terminal window.