[GRASS-dev] GFOSS symposium at IGC, please contribute now!

[Henning Lorenz]

Dear GRASS developers and users!

The session IEI-20, "Free and open-source geospatial software:  
applications in Earth Sciences and recent development" (http://wiki.osgeo.org/wiki/OSGeo_at_IGC2008 
) at the 33rd IGC, 6th - 14th August 2008 in Oslo (http://www. 
33igc.org), did not yet recieve the required number of abstract  
submissions. The abstract deadline has been extended to Friday this  
week. Please help us to save the GFOSS session and submit an abstract  
to the session in case you are going to attend the congress. Please  
tell also your (GFOSS-)friends and colleagues about this session.

Thank you very much!

With best wishes,

Henning

--
Henning Lorenz
Research scientist (Arctic tectonics)
The Swedish Deep Drilling Program (http://www.sddp.se; Scientific  
coordinator)


Uppsala University
Department of Earth Sciences
Villavägen 16
752 36 Uppsala
Sweden
phone:  +46 (0)18 471 23 24
mobile: +46 (0)733 622 655
fax:+46 (0)18 50 11 10
e-mail: [EMAIL PROTECTED]
http://www.geofys.uu.se/?q=view/home/63

GnuPG-key:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=index&search=Henning+Lorenz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #12: gis.m->Help->About system doesn't work (launches another gis.m instance)

[Hamish]

Michael wrote:
> Yes, this should be backported. I thought that was fixed before the  
> 6.3.0 branch. But apparently it didn't get ported over.

the change does not apply cleanly, the 6.3.0RC version has gmlib.tcl
not gm.tcl.

what to do? remove gmlib.tcl line from releasebranch_6_3 or was gm.tcl
removed from trunk when it should have been changed to gmlib.tcl ?

http://trac.osgeo.org/grass/changeset?new=grass%2Ftrunk%2Fgui%2Ftcltk%2Fgis.m%2Ftksys.tcl%4029624&old=grass%2Ftrunk%2Fgui%2Ftcltk%2Fgis.m%2Ftksys.tcl%4024717


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #77: Change wxGui workspace file extension away from .grc

[Michael Barton]

On Mar 3, 2008, at 9:49 PM, [EMAIL PROTECTED] wrote:


Date: Tue, 04 Mar 2008 04:38:22 -
From: "GRASS GIS" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] [GRASS GIS] #77: Change wxGui workspace file
extension away from .grc
To: undisclosed-recipients:;
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"

#77: Change wxGui workspace file extension away from .grc
- 
+--

 Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
 Type:  task |  Status:  new
 Priority:  blocker  |   Milestone:  6.3.0
Component:  default  | Version:  svn-trunk
 Keywords:  wx, gui  |
- 
+--

 Hi,

 before releasing 6.3.0 we should change wxGui workspace file  
extension
 away from .grc as it is incompatible with older GRASS tcl/tk .grc  
files.


 some suggestions from the -dev list:
   http://thread.gmane.org/gmane.comp.gis.grass.devel/24737/ 
focus=24934


 but nothing decided.


I relooked at the discussion. I don't have particularly strong  
feelings one way or the other. But if you need a decision, I'd favor  
either *.gws (GRASS workspace) or *.gwsf (GRASS workspace file)


I did a search on a couple of file extension sites. *.gwsf did not  
exist and *.gws was found on only one site. It was listed as a  
GeoMedia (Intergraph) geoworkspace file format.


So I guess we'd be wise to steer clear of *.gws. But *.gwsf seems fine.

Anyone have any objection to *.gwsf?

Michael

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #12: gis.m->Help->About system doesn't work (launches another gis.m instance)

[GRASS GIS]

#12: gis.m->Help->About system doesn't work (launches another gis.m instance)
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  unspecified  
Resolution:  fixed|Keywords:   
--+-
Comment (by hamish):

 Replying to [comment:4 hamish]:
 > Michael,
 >
 > r29647 does not appear to be backported to the 6.3 branch. Should it be?
 any other gis.m bug fixes that need to be backported?


 tip: in the trac SVN browser click on the Rev number next to a directory
 name to see change history of all files in that dir.

   http://trac.osgeo.org/grass/log/grass/trunk/gui/tcltk/gis.m


 H

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #12: gis.m->Help->About system doesn't work (launches another gis.m instance)

[Michael Barton]

Yes, this should be backported. I thought that was fixed before the  
6.3.0 branch. But apparently it didn't get ported over. I've tried to  
keep Markus up to date on any other bug fixes since the 6.3.0 branch.  
I hope I haven't missed anything else. Thanks for spotting it.


Michael

C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: 



On Mar 3, 2008, at 9:49 PM, GRASS GIS wrote:

#12: gis.m->Help->About system doesn't work (launches another gis.m  
instance)
-- 
+-

  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  unspecified
Resolution:  fixed|Keywords:
-- 
+-

Comment (by hamish):

 Michael,

 r29647 does not appear to be backported to the 6.3 branch. Should  
it be?

 any other gis.m bug fixes that need to be backported?


 ?,
 Hamish

--
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http:// 
grass.osgeo.org/


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #78: gis.m's help page not processed correctly

[GRASS GIS]

#78: gis.m's help page not processed correctly
+---
 Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  6.3.0
Component:  Docs| Version:  svn-trunk
 Keywords:  gis.m, manuals  |  
+---
 Hi,

 I notice that gis.m's help page does not get the  header, --html-
 description, and footer applied to it. d.m manages to get this so gis.m
 should be able to as well. It goes use the standard parser interface and
 --html-description does work.


 Hamish

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #12: gis.m->Help->About system doesn't work (launches another gis.m instance)

[GRASS GIS]

#12: gis.m->Help->About system doesn't work (launches another gis.m instance)
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.3.0
 Component:  default  | Version:  unspecified  
Resolution:  fixed|Keywords:   
--+-
Comment (by hamish):

 Michael,

 r29647 does not appear to be backported to the 6.3 branch. Should it be?
 any other gis.m bug fixes that need to be backported?


 ?,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #77: Change wxGui workspace file extension away from .grc

[GRASS GIS]

#77: Change wxGui workspace file extension away from .grc
-+--
 Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
 Type:  task |  Status:  new  
 Priority:  blocker  |   Milestone:  6.3.0
Component:  default  | Version:  svn-trunk
 Keywords:  wx, gui  |  
-+--
 Hi,

 before releasing 6.3.0 we should change wxGui workspace file extension
 away from .grc as it is incompatible with older GRASS tcl/tk .grc files.

 some suggestions from the -dev list:
   http://thread.gmane.org/gmane.comp.gis.grass.devel/24737/focus=24934

 but nothing decided.



 Hamish

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] more about 3d polygons and TINs

[G. Allegri]

I've read the long interesting discussion about 3d-polygons and TINs:
http://www.nabble.com/convert-3D-polygons-or-Tins-to-a-DEM--td14998420.html

AFAIU, code to manage the creation (and editing?) of 3d features, like
TINs, is still undergoing development.
I think this is a good moment to propose to consider, in the TIN
creation phase, the use of multiple types of input features: points,
lines, polygons.
I come from ArcGIS world, where it's possible to set these as "mass
points", "breaklines" and "hulls" [1]. For example these features are
strongly requested by geologists, when i.e. fault lines has to be
setted, or when a highland is known to "break" the linear
interpolations of points.

Of course, it's a wish... but maybe useful while doing "brainstorming"
about the code to be developed. :-)

Giovanni

[1]: 
http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Creating_TIN_surface_data_from_vector_data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS RC5 man/man1/d.ask.1 Error 127

[Hamish]

Marco Pasetti wrote:
> in the last few lines of compiling I have the following error:
> 
> make[1]: ***
> [/usr/local/src/grass-6.3.0RC5/dist.i686-pc-mingw32/man/man1/d.ask.1]
> Error
> 127
> 
> And then at the end a Make error I don't remember in the previous
> compilations I did:
> 
> Finished compilation: Mon Mar  3 22:52:36 GMT 2008
> make: *** [default] Error 1
> 
> What is it?
> 
> In WinGRASS current status I read:
> You also have to erase $(MANDIR) $(MANPAGES) from line 13 of
> man/Makefile,
> i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'
> 
> At line 13 of man/Makefile I have:
> default: $(MANPAGES)
> 
> That could be the reason of the error?

(no idea, d.ask.html builds fine for me and the man page looks ok too)


FYI d.ask is not needed for the MS Windows port. It requires an xmon
and will not be ported to GRASS 7.


Hamish



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Hamish]

Maciek:
> Oh, and what about other punctuation symbols? Are !?,;: within/at the
> end of the message? [1] does not explain.
>
[1]http://grass.gdf-hannover.de/wiki/Development_Specs#Message_standardization


the g.message help page tries to explain.
I do not know the full list of chars which must be with 'single'
quotes.


Hamish




  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[Hamish]

marco wrote:
> icons are beautiful, I don't discuss :-)

> If do you want to give me the original png (the biggest possible) I
> can do the job in few minutes.

EPS + SVG versions at:
  http://grass.osgeo.org/download/logograms.php

(and lots of other formats too)


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] WinGRASS RC5 man/man1/d.ask.1 Error 127

[Marco Pasetti]

Hi,

I just finished to recompile GRASS 6.3.0RC5 with Tcl/Tk 8.5.1;
I made a quick test with sample data of North-Carolina (SRTM elevation
raster 30m) and it seems bo be OK (but it's the first time for me using
NVIZ, I don't what's the feature intended to not work)
Anyway, the reason of the mail is another: in the last few lines of
compiling I have the following error:

make[1]: ***
[/usr/local/src/grass-6.3.0RC5/dist.i686-pc-mingw32/man/man1/d.ask.1] Error
127

And then at the end a Make error I don't remember in the previous
compilations I did:

Finished compilation: Mon Mar  3 22:52:36 GMT 2008
make: *** [default] Error 1

What is it?

In WinGRASS current status I read:
You also have to erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile,
i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'

At line 13 of man/Makefile I have:
default: $(MANPAGES)

That could be the reason of the error?

Thanks and goodnight,

Marco

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 2D to 3D points

[Hamish]

Michael:
> >> v.transform is really a georectifying module for vector objects.
> >> It's a conceptual stretch to include transforming 2D to 3D points
> >> there-- though it does work.
Hamish:
> > Hence using a wrapper function with a more intuitive name and only
> > expose the relevant options.
Michael:
> In the past, this would be the easiest solution. However, I'm  
> increasingly reluctant to create more Bash scripts for GRASS given
> the plans to move away from that platform and the problems with
> running scripts under Windows/MSys now.

using 'g.module --script' + the fact that it is apparently a one-liner
v.transform process means the script would only take about 2 minutes to
write. So little investment in bash and easily replaced when the time
comes.

We can't/shouldn't make python a mandatory dependency until GRASS 7. If
we do it in bash now (then rewrite as python later) it gets the
functionality out there now and allows the solution to start leaking
into people's minds and work. The user shouldn't notice if the back-end
language changes at some point if the interface stays the same.
This is not to say we can't start to develop shadow g.module.py
versions of scripts now! That would give us a good head start and help
spread the load in time.


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: m.distance / SWIG-Python interface + passing pointers with SWIG [was: d.measure w/ bearing]

[Hamish]

Michael:
> Thanks for checking on this. I'll look at your example to see how it 
> is done.

new updated demo version at the wiki site:
  http://grass.gdf-hannover.de/wiki/PythonSwigExamples

and new full version in the source code: 
  http://trac.osgeo.org/grass/browser/grass/trunk/swig/python/examples


Both versions now have fully functional g.parser support!* The full +
cleaned version in SVN has support for multi-segment input either given
from the command line coord= option or piped from stdin, and also
supports parsing DDD:MM:SS. formatted lat/lon coordinates.

Requires NumPy and NumPtr. As the NumPtr module seems very useful for
us, I will add it in SVN unless there are objections.


* having a slight issue testing for the existance of an enviro
variable, which means it can hang when reading nothing from stdin.
os.getenv() returns None if the variable doesn't exist. But g.parser
seems to create the variable anyway and set it equal to '' if it was
unset. So there is no way easy to test if(option->answer == NULL) from
the script AFAICT. sys.argv is already toast by then. (replaced after
g.parser call)

i.e. this doesn't work as expected:
opt_answer = os.getenv("GIS_OPT_COORD")
if opt_answer is not None:
   # read from command line option
else:
   # read from stdin


> In fact, we don't even need to create an independent module.

Agreed, I do not expect to move the (full) module to be an official
module, I think it's too simple for that. It is just meant to be a
fully working example, or could be used as an addon if someone needed a
multi-segment geodesic distance/area calculator.


> The discussion was over how to implement measurement (and I suppose  
> bearing if it's also supported) in the GUI, and Martin's point was  
> 'why do these calculations in Python when the GRASS libraries can do 
> them?' We should simply be able to incorporate the SWIG calls to the 
> library in the wxPython GUI module. It already can grab xy points.

I suppose you could say "programming" is not banned in the GUI (e.g. wx
measurement or profile tool), but reimplementing complicated things
like great circle calculations in the GUI when well tested and faster C
versions already exist and are accessible via swig.

For general use we would have to make the decision to make swig a
mandatory dependency for the wxGUI. I think that opens more doors than
it closes, so support the idea.

> For a stand alone module--i.e., to be used in non-GUI circumstances  
> too--your Python script could be an example of how to begin to
> replace bash with Python programming. SWIG would give us more options
> than we now have with bash.

exactly.


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Hamish]

Maciej:
[thanks for the cat != key fix; not mentioned as it was all fine...]

> >  resulted in a speed boost. In the end, v.db.renamcol without
> > awk is as fast as it was with awk.

Markus: 
> At this point I don't see why do this effort.
> There is the risk to introduce new bugs (as seen here) and
> there is no point in saving 7% of 10 nanoseconds. Since
> awk is needed in GRASS it can also be used here.
> 
> Why not using efforts for more important things?


just a thought on the other side of the coin: it is nice to have
reference code to copy from once we all figure out best practices. I
think the issue is similar to removing redundant `cat`s. maybe it's
pedantic but it makes us better next time we have to write a script--
as long as it is done for self education and not for useless 'OMG!
wasted 2ns!' crusades.


Hamish





  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[Martin Landa]

Hi,

2008/3/2, Hamish <[EMAIL PROTECTED]>:
>  One thing I noticed:
>  The start screen screenshot includes "C:/grassdata" which will
>  instantly look very wrong to MS Windows-only users.
>  ?
>  Can C:\ be used or does it need to be a forward slash?

hm, strange behaviour under MSYS, I just clicked 'Browse', by default
I got c:/grassdata. MSYS seems to understand /c/grassdata,
c:\grassdata even c:/grassdata.

>  We have a GRASS icon for MS Windows in SVN, could it be used on the top
>  right corner of the windows and the taskbar?  lib/init/grass.ico

Now should be fixed. See

http://grass.gdf-hannover.de/wiki/Image:Wxgui-startup-windows1.png

>  In the GIS manager window layer list it possible to pack the [100%] box
>  at the right edge of the line?

I am not sure, anyway I have discussed that with Michael. wx.SpinCtrl
widget for changing transparency seems to be a bit disturbing (at
least for me, personal taste). Maybe I would prefer to hide this
functionality in contextual menu "Set transparency level" -> open
small window frame, OK.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] compiling grass_trunk under MSYS

[Martin Landa]

Hi,

when I try to compile GRASS code from trunk under MSYS I get

spawn.c: In function `G_spawn':
spawn.c:81: warning: passing arg 3 of `_spawnv' from incompatible pointer type
spawn.c: In function `do_bindings':
spawn.c:218: warning: `return' with a value, in function returning void
spawn.c: In function `do_spawn':
spawn.c:227: error: void value not ignored as it ought to be
spawn.c:229: warning: passing arg 3 of `spawnvpe' from incompatible pointer type
spawn.c:229: warning: passing arg 4 of `spawnvpe' from incompatible pointer type
make: *** [OBJ.i686-pc-mingw32/spawn.o] Error 1

changing prototype of do_bindings from

static void do_bindings(char **env, struct binding *bindings, int num_bindings)

to

static char** do_bindings(char **env, struct binding *bindings, int
num_bindings)

solves compilation. But I am not sure how to fix it in better way.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

RE: [GRASS-dev] Update to r.out.gdal

[Patton, Eric]

>Hi, I just committed a warning message change in TRUNK, but I think some 
>un-backported changes were also committed to grass63_release inadvertently 
>during my commit.
>
>Can someone confirm that everything is ok? Sorry for the headache.

I think I failed to sync my grass63_release source with the svn repo before 
committing. My submission incorporates Martin's edits from changeset 29556 as 
well, if I'm not mistaken.

What's the proper svn magic for cases like these?

~ Eric.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Update to r.out.gdal

[Patton, Eric]

Hi, I just committed a warning message change in TRUNK, but I think some 
un-backported changes were also committed to grass63_release inadvertently 
during my commit.

Can someone confirm that everything is ok? Sorry for the headache.

~ Eric.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

[Michael Barton]

On Mar 3, 2008, at 8:53 AM, Dylan Beaudette wrote:


I see quite a bit of disconnect between the GUI development and core
GRASS development (I am not helping this either). It would be a good
idea to spend some careful thought, with lots of input from everyone
involved to nail down the general plan for GRASS 7. I can see a lot of
potential for hurt feelings (= lost developers) if a slow and methodic
approach is not taken.

Cheers,

Dylan


Actually, I don't think that there is that much of a disconnect. There  
is a lot of communication between the folks writing a lot of the C- 
code and those of us working on the GUI. I think we're all lurching  
along in more or less the same general direction. But it's a very big  
and very complicated project and coordination can always be improved.  
Regular discussions about new display architecture and the move away  
from C-modules with hard-coded interactivity limited to an aging xmon  
interface have been going on for nearly 2 years.


The whole impetus for the current TclTk GUI was to demonstrate that we  
could have an interactive display architecture that did not need to  
rely on interactive d.* modules in which it was hard-coded--and to  
provide an environment which could encourage C programmers to expand  
modules to work better with this approach. This has been largely  
successful especially because of good coordination between GUI  
development and core C-module development. The current Windows native  
version of GRASS would not have been possible without this work.


The move toward Python as a scripting platform seems very exciting for  
GUI development, but even more so for expanded core functionality.  
After working with it for a year and a half, I'm sold. We are slowly  
beginning to switch our scripting in my lab from bash to Python--with  
much better and easier to read and maintain code. The python GUI also  
has opened a lot of new possibilities that I think many will benefit  
from (e.g., the new attribute data management modules).


We need to keep talking about this and issues like 'where' to put  
different functions in the new architecture. Sometimes it's clear, but  
other times it's fuzzy. I hope I haven't hurt anyone's feelings. Mine  
are OK.


Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

[Dylan Beaudette]

On Sunday 02 March 2008, Hamish wrote:
> Helena wrote:
> > > This reminds me - was the patch below submitted to SVN?
>
> Not yet. AFAICT Dylan has SVN permissions for grass-addons/ but not the
> main source tree?

I don't think that I have write-access to any tree yet. At some point it would 
be nice to setup (with approval from the others) those permissions.

> I haven't checked: does the patch "do the right thing" for lat/lon
> locations yet? It needs to do that first. FWIW, I haven't looked at the
> patch yet but the feature seems useful.

Yes and tested, see:
http://trac.osgeo.org/grass/attachment/ticket/76/d.measure_bearing.patch

> > > Do we have a procedure (dedicated person) for keeping
> > > track of patches submitted through track
> > > and making sure they get submitted if appropriate?
>
> Interested devels should claim ownership of the bug in the tracker.
> As long as it is in the tracker it won't get too lost or forgotten.

... It is in the tracker, so that is a start.

Cheers,

Dylan

> Otherwise they sit there until someone takes an interest, which may not
> be an entirely bad thing as commiters are obliged to take primary
> responsibility for code they check in. Every new part of the code needs
> a champion to look after it otherwise bugs go unfixed and there is no
> check on bloat.
>
> Michael:
> > I just tried to check out any updates to d.measure and found that it
> > doesn't run on my Mac. It produces a bus error. I don't need it, but
> > folks should be aware of this.
>
> The code hasn't changed in 10 months*. So perhaps something else is
> wrong like a build problem? If it persists can you debug it?
>
> [*] http://trac.osgeo.org/grass/browser/grass/trunk/display/d.measure
>
>
> Hamish
>
>
>
>  
> ___
>_ Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now. 
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: m.distance / SWIG-Python interface + passing pointers with SWIG [was: d.measure w/ bearing]

[Michael Barton]

On Mar 3, 2008, at 2:30 AM, Hamish wrote:


Martin Landa wrote:

it would be good to use d.measure or something like g.measure in
wxGUI too instead of using Python-based function for distance
calculation (at least it would make sense for LL projections)?


Hamish wrote:

Yes, we should use existing library functions whenever possible, in
this case those found in lib/gis/distance.c and lib/gis/geodist.c.
call it m.distance;

...

It would be very easy to write in C but from a learning exercise
perspective it seems like a perfect thing to try doing with
SWIG+Python, and perhaps too simple a thing to have as a generic
module??



Python-SWIG m.distance (working) prototype:
 http://grass.gdf-hannover.de/wiki/PythonSwigExamples


Starting from the shell it takes about 0.5 sec to run. ie very slow.
But that includes the overhead of starting #!/usr/bin/python and
importing the required modules. If the same code was called from an
already running python session with all that stuff already loaded, I
expect it would be highly fast.  (FWIW unstripped libgis.so is ~900kb,
_python_grass6.so ~1.7mb)


G_area_of_polygon() needs x and y vertices passed to it as memory
address pointers to two double-FP arrays. I really don't know much
about SWIG but a web search turned up a Python module called NumPtr
(Numeric Pointer) for doing that. It seems pretty simple. Instructions
for it are on the wiki link above.


If there isn't already a built-in easier way that I missed, perhaps we
could add that code as a contrib in our swig/python/ dir? It is GPL2,
less than 100kb, and several years without a new version. Hopefully  
the

lack of upstream activity means that it is mature, and not abandoned.
It is a simple enough thing that it wouldn't surprise me if it was
mature. And because it is so simple and small it seems more trouble
than it would be worth to insist that it be an external dependency, or
a be a significant burden to maintain.



To build the SWIG-Python interface I had to hack the Makefile a  
little.


I also had to install the "swig" package on my machine to get
/usr/bin/swig, as compiling failed when it couldn't find it. Maybe add
a check for that program in the main './configure --with-python'? (for
one thing it would give --with-python something useful to do which
currently AFAIK it doesn't?)


# the Makefile problem:
cd swig/python/
make

In file included from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,
from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
from python_grass6_wrap.c:2933:
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/ 
dig_structs.h:22:21:

error: ogr_api.h: No such file or directory



local solution:
edit swig/python/Makefile and add -I/usr/include/gdal to CFLAGS.

not sure what the correct fix in swig/python/Makefile.in for that  
would

be or if the error is really in the vector includes.

Should 'make clean' remove the Makefile or should that only happen  
with

'make distclean'?



see also my notes on an earlier attempt at building swig/python/:
 http://thread.gmane.org/gmane.comp.gis.grass.devel/20751


Hamish


Hamish,

Thanks for checking on this. I'll look at your example to see how it  
is done. In fact, we don't even need to create an independent module.  
The discussion was over how to implement measurement (and I suppose  
bearing if it's also supported) in the GUI, and Martin's point was  
'why do these calculations in Python when the GRASS libraries can do  
them?' We should simply be able to incorporate the SWIG calls to the  
library in the wxPython GUI module. It already can grab xy points.


For a stand alone module--i.e., to be used in non-GUI circumstances  
too--your Python script could be an example of how to begin to replace  
bash with Python programming. SWIG would give us more options than we  
now have with bash.


Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 2D to 3D points

[Michael Barton]

On Mar 3, 2008, at 1:27 AM, Hamish wrote:


Benjamin Ducke wrote:

How about a little wrapper script for v.transform that simplifies
this action?


Dylan:

However, doesn't it make more sense to put that code (for
points) into v.extrude ? Or, is v.extrude primarily for areas
by design?


Michael:

IMHO, v.type is a much better place to put this. v.type is already
designed to transform vector objects from one type of vector object
to another. Changing a vector object from a 2D point to a 3D point
seems to fit this concept well.


As the functionality is already written into a C module, and v.type is
not conspicuously missing the feature or obviously+naturally matching
the task, IMO it is better to use a simple wrapper script with an
obvious+natural name.

I wonder if such a script could call another module for the reverse
proceedure? (v.out.ascii directly piped back into v.in.ascii (without
-z)?, or v.transform + db.in.ogr? or some new C code?)

for the 2D -> 3D case the clearest way would be to pipe
'v.out.ascii.db | v.in.ascii -z' and then copy the table. But to do
that properly v.out.ascii would need to finally to have the DB output
code written. (probably pretty simple to do; the v.out.ascii.db script
can be found in wiki addons)



(And while we're at it, v.type should
be changed to work like v.type.sh).


the module command line interface can't change until GRASS 7.
Hence we have v.type.sh, for once it's not due to long queues.



v.transform is really a georectifying module for vector objects. It's
a conceptual stretch to include transforming 2D to 3D points there--
though it does work.


Hence using a wrapper function with a more intuitive name and only
expose the relevant options.


Hamish,

In the past, this would be the easiest solution. However, I'm  
increasingly reluctant to create more Bash scripts for GRASS given the  
plans to move away from that platform and the problems with running  
scripts under Windows/MSys now.


Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Martin Landa]

Maciek,

2008/3/3, Maciej Sieczka <[EMAIL PROTECTED]>:
> >> Did my adding periods break any translations? Should I delete theses
>  >>  periods? Sorry if a stupid question.
>
>  > yes, it can turn translated messages to fuzzy. I would prefer to put
>  > '.' at the end of single sentence message too, but since last message
>  > standardization effort follows rule 'single sentence message ->
>  > without '.') I would prefer to continue in this way and to change
>  > 'rules' every year;-)
>
>
> OK. I'm deleting them. Though a sentence with no period is crippled.
>  Reader might suppose the message is incomplete or broken. Could this be
>  changed in GRASS 7?

I would really avoid it, GRASS 7 should be focused on other things
than changing all messages which have been changed in the last decade
back;-) Look at changesets with log ~ "Message standardization" from
the last few months, now it is too late to change this rule. I can
repeat that I would prefer to put '.' at the end of each (even single
sentence) message, but it would be really waste of energy to change
all messages back. Carlos?

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Maciej Sieczka pisze:

Martin Landa pisze:

2008/3/3, Maciej Sieczka <[EMAIL PROTECTED]>:



Did my adding periods break any translations? Should I delete theses
 periods? Sorry if a stupid question.



yes, it can turn translated messages to fuzzy. I would prefer to put
'.' at the end of single sentence message too, but since last message
standardization effort follows rule 'single sentence message ->
without '.') I would prefer to continue in this way and to change
'rules' every year;-)



OK. I'm deleting them.


Oh, and what about other punctuation symbols? Are !?,;: within/at the 
end of the message? [1] does not explain.


[1]http://grass.gdf-hannover.de/wiki/Development_Specs#Message_standardization

Maciek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] WinGRASS Building Guide

[marco.pasetti]

Hi,
 
I finished and published my WinGRASS Building guide:
 
http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html 
 
 
could someone give it a look, please, and check it for "english" errors and/or 
other suggestions?
 
Thanks
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Martin Landa pisze:

2008/3/3, Maciej Sieczka <[EMAIL PROTECTED]>:



Did my adding periods break any translations? Should I delete theses
 periods? Sorry if a stupid question.



yes, it can turn translated messages to fuzzy. I would prefer to put
'.' at the end of single sentence message too, but since last message
standardization effort follows rule 'single sentence message ->
without '.') I would prefer to continue in this way and to change
'rules' every year;-)


OK. I'm deleting them. Though a sentence with no period is crippled. 
Reader might suppose the message is incomplete or broken. Could this be 
changed in GRASS 7?



Anyway it should be documented somewhere.


Please. As you can see I don't know how the translation mechanism works, 
so I better don't do it myself.


Maciek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

[Dylan Beaudette]

On Sat, Mar 1, 2008 at 7:18 AM, Michael Barton <[EMAIL PROTECTED]> wrote:
>
>
>  On Mar 1, 2008, at 1:47 AM, Martin Landa wrote:
>
>  > Micheal,
>  >
>  > 2008/3/1, Michael Barton <[EMAIL PROTECTED]>:
>  >>> 2008/2/29, Dylan Beaudette <[EMAIL PROTECTED]>:
>  >>> [snip]
>   Thanks for the update. I don't regularly use either of the GUI and
>   did
>    not know about this feature. Does the patch that I submitted
>   interfere
>    with this functionality? I think that it would be useful to have
>   this
>    functionality in the old style monitors as well.
>  >>>
>  >>> d.measure is not used in wxGUI. Display windows are not
>  >>> registered as
>  >>> GRASS displays (d.mon -L) [TODO, not sure how to implemented], I
>  >>> think
>  >>> it would be good to use d.measure or something like g.measure in
>  >>> wxGUI
>  >>> too instead of using Python-based function for distance calculation
>  >>> (at least it would make sense for LL projections)? Please correct me
>  >>> if I am wrong.
>  >>
>  > Michael,
>  >> What's wrong with the Python one?
>  >
>  > duplication of the code, and in this particular case ignoring geodetic
>  > distance for LL projections.
>
>  Well, my understanding of the direction of GRASS is that by v7, we'll
>  lose all the interactive xterm-specific d.* modules. Interactive use
>  will all be shifted to whatever GUI we design, rather than being hard-
>  coded into a module. Simple, interactive measurement between 2 points
>  on a display screen seems to me something to be handled by a GUI.

I agree completely-- despite the fact that I prefer the d.* commands
for now, an integrated approach would be nice. That said, it would be
nice to retain something like the current d.* commands. Nothing is
faster when working with a couple raster/vector files.

>  d.measure will go away OR change to a module in which you enter a
>  start and end point and it returns the distance between the points.
>  In the latter case, it could then be 'plugged into' a GUI as a
>  function to calculate distance between points interactively 'grabbed'
>  by the GUI.

Sure. Until then it would be nice to have something that works, and
provides some missing functionality.

>  Ignoring geodetic distance for LL projections is simply ignorance (on
>  my part here) of the equations needed to do it. It's easy to
>  determine if a location is LL. In that case, it should calculate
>  geodetic distance rather than (or perhaps in addition to) displaying
>  distance in map units. Just need to have the functions to do this
>  added to the measurement methods.
>
>  Michael
>

I see quite a bit of disconnect between the GUI development and core
GRASS development (I am not helping this either). It would be a good
idea to spend some careful thought, with lots of input from everyone
involved to nail down the general plan for GRASS 7. I can see a lot of
potential for hurt feelings (= lost developers) if a slow and methodic
approach is not taken.

Cheers,

Dylan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Martin Landa]

Hi,

2008/3/3, Maciej Sieczka <[EMAIL PROTECTED]>:
> >>  A sentence without a period? Strange and not grammatical. What would be
>  >>  the rationalle?
>
>  >>  
> [1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox
>
>  > The key point is not not break again all translations.
>
>
> Did my adding periods break any translations? Should I delete theses
>  periods? Sorry if a stupid question.

yes, it can turn translated messages to fuzzy. I would prefer to put
'.' at the end of single sentence message too, but since last message
standardization effort follows rule 'single sentence message ->
without '.') I would prefer to continue in this way and to change
'rules' every year;-) Anyway it should be documented somewhere.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] New Binary Package Project for winGRASS

[marco.pasetti]

Perfect!



Da: Martin Landa [mailto:[EMAIL PROTECTED]
Inviato: lun 03/03/2008 16.31
A: [EMAIL PROTECTED]
Cc: Hamish; GRASS Developer Mailing List
Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS



Marco,

2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

> for transparent I meant only the "outside" background. Try with my icons to
> take a look on what I mean

finally I got the point:-) I changed outer area of icons to be
transparent in SVN trunk.

http://trac.osgeo.org/grass/changeset/30444

Martin

>
> Marco
>
>  
>  Da: Martin Landa [mailto:[EMAIL PROTECTED]
> Inviato: lun 03/03/2008 15.17
> A: [EMAIL PROTECTED]
> Cc: Hamish; GRASS Developer Mailing List
> Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS
>
>
>
>
> Hi,
>
> 2008/3/3, Martin Landa <[EMAIL PROTECTED]>:
> > > icons are beautiful, I don't discuss :-) but I would prefer to have a
> >  > transparent background, at least for the main grass icon (for windows
> it's
> >  > also a good thing to build a multiple icon archive, with 16,24,32 and
> 48 px,
> >  > if you want with also 64px format, why not)
> >  > If do you want to give me the original png (the biggest possible) I can
> do
> >  > the job in few minutes.
> >
> >
> > the original png file before I have removed them
> >
> >
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/images/?rev=30429
> >
> >  or 64px ico files should be enough, transparent background would be
> >  better. BTW 64px icons looks nice in WindowMaker:-)
>
> I tried to make grass.ico transparent, seems not so nice under Gnome
>
> http://josef.fsv.cvut.cz/~landa/tmp/grass_ico_trasparent.png
>
> Martin
>
> --
> Martin Landa  * http://gama.fsv.cvut.cz/~landa *
>


--
Martin Landa  * http://gama.fsv.cvut.cz/~landa *


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Markus Neteler pisze:

On Mon, Mar 3, 2008 at 11:53 AM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:



 A sentence without a period? Strange and not grammatical. What would be
 the rationalle?



 
[1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox



The key point is not not break again all translations.


Did my adding periods break any translations? Should I delete theses 
periods? Sorry if a stupid question.


Maciek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[Martin Landa]

Marco,

2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

> for transparent I meant only the "outside" background. Try with my icons to
> take a look on what I mean

finally I got the point:-) I changed outer area of icons to be
transparent in SVN trunk.

http://trac.osgeo.org/grass/changeset/30444

Martin

>
> Marco
>
>  
>  Da: Martin Landa [mailto:[EMAIL PROTECTED]
> Inviato: lun 03/03/2008 15.17
> A: [EMAIL PROTECTED]
> Cc: Hamish; GRASS Developer Mailing List
> Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS
>
>
>
>
> Hi,
>
> 2008/3/3, Martin Landa <[EMAIL PROTECTED]>:
> > > icons are beautiful, I don't discuss :-) but I would prefer to have a
> >  > transparent background, at least for the main grass icon (for windows
> it's
> >  > also a good thing to build a multiple icon archive, with 16,24,32 and
> 48 px,
> >  > if you want with also 64px format, why not)
> >  > If do you want to give me the original png (the biggest possible) I can
> do
> >  > the job in few minutes.
> >
> >
> > the original png file before I have removed them
> >
> >
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/images/?rev=30429
> >
> >  or 64px ico files should be enough, transparent background would be
> >  better. BTW 64px icons looks nice in WindowMaker:-)
>
> I tried to make grass.ico transparent, seems not so nice under Gnome
>
> http://josef.fsv.cvut.cz/~landa/tmp/grass_ico_trasparent.png
>
> Martin
>
> --
> Martin Landa  * http://gama.fsv.cvut.cz/~landa *
>


-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[benjamin . ducke]

Actually, I think the configure script does detect it (at least
it does for me). However, it then tries to compile a little test
program which fails. Unfortunately the output of the configure
script makes it look like a problem with the library not being
detected rather than the test program not being compiled.

If you look into config.log, you will see the "true reason":

configure:23961: mingw32-g++ -o conftest.exe -g -O2  -I/usr/include 
-L/usr/lib -lexpat conftest.cpp -L/usr -L/usr/lib -ljasper -L/usr
-L/usr/lib -lcfitsio -lpq -LC:/msys/1.0/lib -lpq -lz   >&5
C:/DOCUME~1/bart/LOCALS~1/Temp/ccAj.o: In function `main':
C:/msys/1.0/src/gdal-1.5.0/conftest.cpp:65: undefined reference to
`XML_ParserCreate'
C:/msys/1.0/src/gdal-1.5.0/conftest.cpp:66: undefined reference to
`XML_ParserFree'
collect2: ld returned 1 exit status



Benjamin

[EMAIL PROTECTED] wrote:
> Hi Benjamin,
>
> for xerces I cannot help, while about expat I did a lot of attempts.
> GDAL configure doesn't want to find it, and I don't know why!!!
> I think that you would waste your time; it's better to concentrate
> strengths on xerces
>
> Marco
>

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS & Tcl/Tk

[Michael Barton]

On Mar 3, 2008, at 3:29 AM, [EMAIL PROTECTED] wrote:


Date: Mon, 3 Mar 2008 11:29:52 +0100
From: <[EMAIL PROTECTED]>
Subject: [GRASS-dev] WinGRASS & Tcl/Tk
To: 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I'm again on Tcl/Tk issue for Windows;
Paul Kelly tells that he tested latest 8.5 release finding it  
working, so I'm going to compile that release!
But here's another question, I never faced the problem of compile  
Tcl (always used precompiled binaries), and on the web site I found  
two sources, Tcl and Tk; what to do? Compile both? same or  
different prefix?


Thanks

Marco


Make sure you test NVIZ with TclTk 8.5. That's where the main  
problems were. Maybe fixed now.


Michael

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] about SWIG Python interface...

[G. Allegri]

I talked to Alessandro. He will be very pleased to release its work.
Anyway it won't be possible before the end of April, as he's very busy
with travels outside Italy.
In the meanwhile he shall try to produce some documentation about it.

Bye,
Giovanni

2008/3/3, Martin Landa <[EMAIL PROTECTED]>:
> Hi,
>
>  2008/3/3, G. Allegri <[EMAIL PROTECTED]>:
>  [snip]
>
> >   The question is: as Martin says, it's still in a "pre-alpha" state,
>  >   but do you think it will be developed more and supported?
>  >
>  >   Is the work done by Alessandro Frigeri (Univeristy of Perugia), to
>  >   implement a SWIG/Python interface [1], already included in the actual
>  >   code?
>
>
> not yet, I hope it will be possible soon(?). It would improve GRASS
>  Swig/Python interface a lot.
>
>  Martin
>
>
>  --
>  Martin Landa  * http://gama.fsv.cvut.cz/~landa *
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

[Michael Barton]

On Mar 3, 2008, at 1:06 AM, Hamish wrote:


Michael:

I just tried to check out any updates to d.measure and found that
it doesn't run on my Mac. It produces a bus error. I don't need
it, but folks should be aware of this.



Dylan:

I do not have access to a Mac, but the module seems to compile and
run fine on Linux x86.

Could it be the call to atan2() -- perhaps the math library is not
accessed the same way on Mac OS X ?


Hamish:

I have just tested here using William's 6.3 binaries from a few weeks
ago and I too get a Bus error when trying to start d.measure.


i.e. it's got nothing to do with the bearing patch.


Hamish



While I use the command line from time to time, I don't use xmons for  
interactive displays. So this bug could have been there for quite  
awhile.


Michael

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] WinGRASS: Xerces-C and Expat under MingW

[marco.pasetti]

Hi Benjamin,
 
for xerces I cannot help, while about expat I did a lot of attempts. GDAL 
configure doesn't want to find it, and I don't know why!!!
I think that you would waste your time; it's better to concentrate strengths on 
xerces
 
Marco
 



Da: [EMAIL PROTECTED] per conto di [EMAIL PROTECTED]
Inviato: lun 03/03/2008 15.18
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] WinGRASS: Xerces-C and Expat under MingW



Dear WinGRASS friends,

I just got hold of my old MinGW notes and would like
to contribute a bit to the GRASS Win binaries.

Has anyone got GDAL 1.5.0 to configure and compile correctly
*including* support for Xerces-C 2.8.0 on MinGW?

I have tried both DLL binaries and compilation from scratch
(which only creates static libs at the moment, but that's OK).

Now, the GDAL configure scripts tries to compile a small Xerces-C
test program and keeps failing like this:

C:/DOCUME~1/bart/LOCALS~1/Temp/cck1.o: In function
`ZN11xercesc_2_810XMLDeleterD1Ev':
C:/msys/1.0/local/include/xercesc/util/PlatformUtils.hpp:851: undefined
reference to `xercesc_2_8::XMLUni::fgXercescDefaultLocale'
C:/msys/1.0/local/include/xercesc/util/PlatformUtils.hpp:851: undefined
reference to `xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char
const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool)'
collect2: ld returned 1 exit status

The crazy thing is that I know the libraries are fine and
I grepped for "" in the binaries and found the declaration for
the symbol "fgXercescDefaultLocale" in there!
(although it is not present in the "xercesc_2_8::XMLUni::" namespace
form, but I don't know whether it should be).

Also, I had Xerces-C as a static lib in the past and GDAL
would find and use it just fine. That was GDAL 1.4.4, though, so maybe
they just recently added that critical test program.

There are similar problems with Expat. I can also not get
GDAL 1.5 to recognize it.

Any help would be greatly appreciated. It seems that Xerces-C would
be important for WMS support in GDAL.

Best,

Benjamin

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[marco.pasetti]

Hi Martin,
 
for transparent I meant only the "outside" background. Try with my icons to 
take a look on what I mean
 
Marco



Da: Martin Landa [mailto:[EMAIL PROTECTED]
Inviato: lun 03/03/2008 15.17
A: [EMAIL PROTECTED]
Cc: Hamish; GRASS Developer Mailing List
Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS



Hi,

2008/3/3, Martin Landa <[EMAIL PROTECTED]>:
> > icons are beautiful, I don't discuss :-) but I would prefer to have a
>  > transparent background, at least for the main grass icon (for windows it's
>  > also a good thing to build a multiple icon archive, with 16,24,32 and 48 
> px,
>  > if you want with also 64px format, why not)
>  > If do you want to give me the original png (the biggest possible) I can do
>  > the job in few minutes.
>
>
> the original png file before I have removed them
>
>  
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/images/?rev=30429
>
>  or 64px ico files should be enough, transparent background would be
>  better. BTW 64px icons looks nice in WindowMaker:-)

I tried to make grass.ico transparent, seems not so nice under Gnome

http://josef.fsv.cvut.cz/~landa/tmp/grass_ico_trasparent.png

Martin

--
Martin Landa  * http://gama.fsv.cvut.cz/~landa *


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] WinGRASS: Xerces-C and Expat under MingW

[benjamin . ducke]

Dear WinGRASS friends,

I just got hold of my old MinGW notes and would like
to contribute a bit to the GRASS Win binaries.

Has anyone got GDAL 1.5.0 to configure and compile correctly
*including* support for Xerces-C 2.8.0 on MinGW?

I have tried both DLL binaries and compilation from scratch
(which only creates static libs at the moment, but that's OK).

Now, the GDAL configure scripts tries to compile a small Xerces-C
test program and keeps failing like this:

C:/DOCUME~1/bart/LOCALS~1/Temp/cck1.o: In function
`ZN11xercesc_2_810XMLDeleterD1Ev':
C:/msys/1.0/local/include/xercesc/util/PlatformUtils.hpp:851: undefined
reference to `xercesc_2_8::XMLUni::fgXercescDefaultLocale'
C:/msys/1.0/local/include/xercesc/util/PlatformUtils.hpp:851: undefined
reference to `xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char
const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool)'
collect2: ld returned 1 exit status

The crazy thing is that I know the libraries are fine and
I grepped for "" in the binaries and found the declaration for
the symbol "fgXercescDefaultLocale" in there!
(although it is not present in the "xercesc_2_8::XMLUni::" namespace
form, but I don't know whether it should be).

Also, I had Xerces-C as a static lib in the past and GDAL
would find and use it just fine. That was GDAL 1.4.4, though, so maybe
they just recently added that critical test program.

There are similar problems with Expat. I can also not get
GDAL 1.5 to recognize it.

Any help would be greatly appreciated. It seems that Xerces-C would
be important for WMS support in GDAL.

Best,

Benjamin

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[Martin Landa]

Hi,

2008/3/3, Martin Landa <[EMAIL PROTECTED]>:
> > icons are beautiful, I don't discuss :-) but I would prefer to have a
>  > transparent background, at least for the main grass icon (for windows it's
>  > also a good thing to build a multiple icon archive, with 16,24,32 and 48 
> px,
>  > if you want with also 64px format, why not)
>  > If do you want to give me the original png (the biggest possible) I can do
>  > the job in few minutes.
>
>
> the original png file before I have removed them
>
>  
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/images/?rev=30429
>
>  or 64px ico files should be enough, transparent background would be
>  better. BTW 64px icons looks nice in WindowMaker:-)

I tried to make grass.ico transparent, seems not so nice under Gnome

http://josef.fsv.cvut.cz/~landa/tmp/grass_ico_trasparent.png

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[Martin Landa]

Hi,

2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> icons are beautiful, I don't discuss :-) but I would prefer to have a
> transparent background, at least for the main grass icon (for windows it's
> also a good thing to build a multiple icon archive, with 16,24,32 and 48 px,
> if you want with also 64px format, why not)
> If do you want to give me the original png (the biggest possible) I can do
> the job in few minutes.

the original png file before I have removed them

http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/images/?rev=30429

or 64px ico files should be enough, transparent background would be
better. BTW 64px icons looks nice in WindowMaker:-)

Martin

>
> Marco
>
>  
>  Da: Martin Landa [mailto:[EMAIL PROTECTED]
> Inviato: lun 03/03/2008 14.33
> A: [EMAIL PROTECTED]
> Cc: Hamish; GRASS Developer Mailing List
> Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS
>
>
>
>
> Hi Marco,
>
> 2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> > about the icon, I found it, but it doesn't have the transparent layer! so
> I
> > decided to create a new one, using the official png logo, and stretching
> the
> > image to constrain it to a squared poroportion (as done for the previous
> > icon); actually, leaving the original proportion, makes the icon less
> > visible in 16px format...
> > The zip archive contains the multi-icon in 16,24,32 and 48 px and the png
> > used to create the icon.
> >
> > this is the address:
> >
> http://www.webalice.it/marco.pasetti/grass/grass_icon_package.zip
>
> today in the morning I have added some new icons to SVN (better to say
> moved for gui/wxpython/images, based on png files created by Jachym
> Cepicky)
>
> http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.ico
> http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_map.ico
> http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_sql.ico
> http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_dialog.ico
>
> single-icon 64px, I didn't tested on Windows till now. I will take a
> look at your icons.
>
> Martin
>
> --
> Martin Landa  * http://gama.fsv.cvut.cz/~landa *
>


-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Binary Package Project for winGRASS

[marco.pasetti]

Hi Martin,
 
icons are beautiful, I don't discuss :-) but I would prefer to have a 
transparent background, at least for the main grass icon (for windows it's also 
a good thing to build a multiple icon archive, with 16,24,32 and 48 px, if you 
want with also 64px format, why not)
If do you want to give me the original png (the biggest possible) I can do the 
job in few minutes.
 
Marco



Da: Martin Landa [mailto:[EMAIL PROTECTED]
Inviato: lun 03/03/2008 14.33
A: [EMAIL PROTECTED]
Cc: Hamish; GRASS Developer Mailing List
Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS



Hi Marco,

2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

> about the icon, I found it, but it doesn't have the transparent layer! so I
> decided to create a new one, using the official png logo, and stretching the
> image to constrain it to a squared poroportion (as done for the previous
> icon); actually, leaving the original proportion, makes the icon less
> visible in 16px format...
> The zip archive contains the multi-icon in 16,24,32 and 48 px and the png
> used to create the icon.
>
> this is the address:
> http://www.webalice.it/marco.pasetti/grass/grass_icon_package.zip

today in the morning I have added some new icons to SVN (better to say
moved for gui/wxpython/images, based on png files created by Jachym
Cepicky)

http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_map.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_sql.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_dialog.ico

single-icon 64px, I didn't tested on Windows till now. I will take a
look at your icons.

Martin

--
Martin Landa  * http://gama.fsv.cvut.cz/~landa *


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: R: [GRASS-dev] New Binary Package Project for winGRASS

[Moritz Lennert]

On 03/03/08 10:26, [EMAIL PROTECTED] wrote:

Moritz,
 
what release of TCL?


I don't know. I have never tried with anything else but 8.4.

Moritz

 
Marco



*Da:* Moritz Lennert [mailto:[EMAIL PROTECTED]
*Inviato:* dom 02/03/2008 20.47
*A:* [EMAIL PROTECTED]
*Cc:* 'Benjamin Ducke'; 'GRASS Developer Mailing List'
*Oggetto:* Re: R: [GRASS-dev] New Binary Package Project for winGRASS

On 01/03/08 22:14, Marco Pasetti wrote:
 > Hi Benjamin,
 >
 >> Why use ActiveTcl? The regular, GPL'd Tcl compiles without any 
problems and

 > can be distributed freely.
 >
 > Good question! When I planned the work I dind't considered this option,
 > because on the wiki it was (it is) suggested to use ActiveTcl;
 > Probably I should reconsider to build Tcl/Tk from source using MinGW, and
 > then rebuild GRASS...
 >
 > Moritz, what do you think about?

Go ahead for GPL'd tcl/tk.

Moritz



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: [GRASS-dev] New Binary Package Project for winGRASS

[Martin Landa]

Hi Marco,

2008/3/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

> about the icon, I found it, but it doesn't have the transparent layer! so I
> decided to create a new one, using the official png logo, and stretching the
> image to constrain it to a squared poroportion (as done for the previous
> icon); actually, leaving the original proportion, makes the icon less
> visible in 16px format...
> The zip archive contains the multi-icon in 16,24,32 and 48 px and the png
> used to create the icon.
>
> this is the address:
> http://www.webalice.it/marco.pasetti/grass/grass_icon_package.zip

today in the morning I have added some new icons to SVN (better to say
moved for gui/wxpython/images, based on png files created by Jachym
Cepicky)

http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_map.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_sql.ico
http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass_dialog.ico

single-icon 64px, I didn't tested on Windows till now. I will take a
look at your icons.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] about SWIG Python interface...

[Martin Landa]

Hi,

2008/3/3, G. Allegri <[EMAIL PROTECTED]>:
[snip]
>   The question is: as Martin says, it's still in a "pre-alpha" state,
>   but do you think it will be developed more and supported?
>
>   Is the work done by Alessandro Frigeri (Univeristy of Perugia), to
>   implement a SWIG/Python interface [1], already included in the actual
>   code?

not yet, I hope it will be possible soon(?). It would improve GRASS
Swig/Python interface a lot.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: [GRASS-dev] Updates to wingrass-extralibs

[Paul Kelly]

On Mon, 3 Mar 2008 [EMAIL PROTECTED] wrote:


Hi Paul,

it seems to be a head to head race! :-D

anyway... I agree about "not reinventing the wheel"... but sometimes I also 
think that it's necessary, because not all GnuWin32 libs are updated and, the biggest 
problem, they are built using VS, not MinGW;


That's not true - see http://gnuwin32.sourceforge.net/summary.html where 
it says they are all compiled with MinGW and gcc. I've compiled GDAL 
against them and had no problems.


But no, it's not a race! :) I've mean meaning to make the binaries 
available for two months now and it just seemed like a good time to 
finally do it.


On Mon, 3 Mar 2008, Hamish wrote:


or open a gmail account, then you get 100MB webspace from
pages.google.com. (the last time I tried the max file size you could
serve was 10MB)


Not a bad idea; am looking into it (to host the source code, just to 
keep things legal...)


Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Markus Neteler pisze:

On Mon, Mar 3, 2008 at 11:53 AM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:

Markus wrote:

Maciek wrote:

 Hamish pisze:



'wc -c filename' will produce output like: '17 filename' (needing awk
or cut) while 'wc -c < filename' or 'cat filename | wc -c' will produce
output like: '17'. Maybe that is the dark memory?



 That could explain the " awk '{print $1}' ". Markus?



Possibly yes. As said: darkly remembered...



In the end, v.db.renamcol without awk is as
 fast as it was with awk.



At this point I don't see why do this effort.
There is the risk to introduce new bugs


Well yes there is as always.


(as seen here)


My awk to cut switch didn't introduce any bugs. No any new bugs were 
introduced at all. The only controversial change was:


- g.message -e 'User break!'
+ g.message -e "User break!"

which could (as Hamish says) but unlikely (as Ivan says) cause shell to 
expand the exclamation mark. Anyway - I reverted that, as single quotes 
are 100% safe. Glad Hamish pointed it out to me and sorry again.


Let me remind that the main point of my patches for v.db.renamecol and 
v.db.dropcol was to correct a bug that the key column was always assumed 
to be "cat". Fixed that. Other changes were BTW.


> and there is no point in saving 7% of 10 nanoseconds.

There is no speed gain at all.


Since awk is needed in GRASS it can also be used here.
Why not using efforts for more important things?


Like I said, awk to cut change that was just done BTW fixing bugs.

Maciek

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Martin Landa]

Hi,

2008/3/3, Markus Neteler <[EMAIL PROTECTED]>:
Maciek:
>  >  > IIUC the message standardization has been to not end single sentence
>  >  > warnings and errors with a ".", only to do that with module
>  >  > descriptions. (I don't know if I agree with that all the time, but a
>  >  > lot of effort has gone in to making it that way)
>  >
>  >  A sentence without a period? Strange and not grammatical. What would be
>  >  the rationalle?
> >  
> > [1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox
Markus:
> The key point is not not break again all translations.

In the last decade most of single sentences w/e were changed to be
without '.' at the end of the sentence so I would prefer not to break
this 'rule'. Anyway it should be documented somewhere (SUBMITTING*)

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Markus Neteler]

On Mon, Mar 3, 2008 at 11:53 AM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
>  >> Markus wrote:
>   > Maciek wrote:
>  Hamish pisze:
...
>  >   setup temporary file
>  >  TMP="`g.tempfile pid=$$`"
>  >  if [ $? -ne 0 ] || [ -z "$TMP" ] ; then
>  > -g.message -e "Unable to create temporary files"
>  > +g.message -e "Unable to create temporary files."
>  >  exit 1
>  >  fi
>  >
>  > IIUC the message standardization has been to not end single sentence
>  > warnings and errors with a ".", only to do that with module
>  > descriptions. (I don't know if I agree with that all the time, but a
>  > lot of effort has gone in to making it that way)
>
>  A sentence without a period? Strange and not grammatical. What would be
>  the rationalle?
...
>  
> [1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox

The key point is not not break again all translations.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates to wingrass-extralibs

[Paul Kelly]

Hello Marco

On Mon, 3 Mar 2008 [EMAIL PROTECTED] wrote:


just few questions:
1) did you used /win subdirectory to compile?
2) did you performed make test?

I did it, and had lots of "FAILED"!


I take it we're talking about Tcl? I didn't run make test; just tried it 
with GRASS and things seemed to work (gis_set.tcl, gis.m and nviz). I 
think 26 failed tests compared to 23258 passed doesn't sound too bad 
though!


Paul

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates to wingrass-extralibs

[marco.pasetti]

Sorry, I forgot:
 
./configure --prefix=/usr/local/tcl-tk --enable-shared
make
make test
 
Tests ended at Mon Mar 03 13:27:39 +0100 2008
all.tcl:Total   24180   Passed  23258   Skipped 896 Failed  26
Sourced 137 Test Files.
Files with failing tests: cmdAH.test fCmd.test fileName.test timer.test 
winFile.test
Number of tests skipped for each constraint:
9   !ieeeFloatingPoint
17  95
2   95or98
2   RealConsole
3   asyncPipeChan
76  bigEndian
9   cdrom
1   dontCopyLinks
19  eformat
62  emptyTest
14  english
2   exdev
2   hasIsoLocale
13  hasLinks
1   interactive
29  knownBug
2   knownBug !singleTestInterp
2   largefileSupport
100 localeRegexp
12  longIs64bit
14  macosxFileAttr
15  memory
23  nonPortable
5   notNetworkFilesystem
17  pkga.dllRequired
19  pkgua.dllRequired
2   sharedCdrive
1   symbolicLinkFile
4   tempNotWin
7   testaccessproc
1   testexprparser && !ieeeFloatingPoint
22  testfilehandler
2   testfilewait
7   testfindexecutable
1   testgetdefenc
8   testopenfilechannelproc
7   teststatproc
120 testthread
21  testwordend
3   threaded
180 unix
23  unixExecs
3   unknownFailure
3   winOlderThan2000
stderr32




Da: [EMAIL PROTECTED] per conto di Paul Kelly
Inviato: lun 03/03/2008 12.06
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] Updates to wingrass-extralibs



Spurred on by the work that Marco is doing, I've finally got around to
packaging the new versions of essential libraries for WinGRASS that I
compiled a couple of months ago. In case it is helpful to anybody, the
13MB file wingrass-extralibs-20080303.tar.gz now at
http://www.stjohnspoint.co.uk/grass/ contains the following versions of
libraries:
xdr-4.0-mingw32
proj-4.6.0
gdal-1.5.0
fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
tcl-8.5.0
tk-8.5.0

I have copies of all the source packages but I don't have the
bandwidth/diskspace really to make them available there to download as
well, so this can't be considered an official binary distribution of them.
Nevertheless I hope it is useful.

I didn't compile anything else as I found I was able to get all the other
dependencies from GnuWin32 (http://gnuwin32.sourceforge.net/), i.e.
libintl, libjpeg, libpng, zlib, libtiff, freetype, curses. No point in
reinventing the wheel when they are already available in an easy-to-use
format.

The 13MB file includes all the libraries and associated utility programs,
source headers and import libraries etc. necessary for compiling.
Obviously only the .dlls (and maybe even then not all of them) need to go
into a GRASS binary distribution, so the size would be much smaller. It's
normally useful though to include a couple of the main GDAL utility
programs: gdalwarp, gdalinfo and so on. nad2bin from the PROJ distribution
is required, and cs2cs is very useful.

I realise this is slightly different from the approach Marco is taking, in
that I'm directing people to GnuWin32 for the stuff that they have
available already - again that's just laziness on my part really but I
think it will be less work in the future.

The great thing about this now is that we can include the Tcl/Tk DLLs in
the binary distribution and don't have to ask people to install a separate
Tcl/Tk any more.

Also I don't have a lot of time to maintain this either, but if someone
wants to run a relatively stripped-down WinGRASS and compile it themselves
it might just be useful, so I thought I'd put it out there to complement
Marco's work.

Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Markus Neteler]

On Mon, Mar 3, 2008 at 11:53 AM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
>  >> Markus wrote:
>   > Maciek wrote:
>  Hamish pisze:
>
>
>  >>> are you sure that this is portable?
>  >>>
>  >>> if [ "$driver" = "dbf" ] ; then
>  >>> -  NAMELEN=`echo "$newcol" | wc -c | awk '{print $1}'`
>  >>> +  NAMELEN=`echo "$newcol" | wc -c`
>  >>>
>  >>> I darkly remember that some "wc" programs insert odd spaces which
>  >>> would break the script.
>
>  >> I haven't heard of it. Maybe you are right. Let's ask on the dev ML.
>  >> Thoughts, Anybody?
>
>  > 'wc -c filename' will produce output like: '17 filename' (needing awk
>  > or cut) while 'wc -c < filename' or 'cat filename | wc -c' will produce
>  > output like: '17'. Maybe that is the dark memory?
>
>  That could explain the " awk '{print $1}' ". Markus?

Possibly yes. As said: darkly remembered...

>  > For curiosity, what's so bad about using awk?
>
>  Invoking the allmighty awk just to do what cut is designed for seems an
>  overkill to me. Awk is not needed for anything in v.db.renamecol. Cut
>  suffices. Keep it simple, the UNIX way of specialized tools and stuff.
>
>  > speed?
>
>  Actually cut itself seems slightly slower than awk for this sort of task:
>
>  $ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | cut -d" " -f2 >
>  /dev/null ; x=`expr $x + 1`; done
>
>  on my machine is about 7% slower than
>
>  $ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | awk '{print $2}'
>   > /dev/null ; x=`expr $x + 1`; done
>
>
>  On the other hand, after replacing all awk with cut in the script,
>  removing the test for awk's presence:
>
>
>   check if we have awk
>  if [ ! -x "`which awk`" ] ; then
>  g.message -e "awk required, please install awk or gawk first"
>  exit 1
>  fi
>
>  resulted in a speed boost. In the end, v.db.renamcol without awk is as
>  fast as it was with awk.

At this point I don't see why do this effort.
There is the risk to introduce new bugs (as seen here) and
there is no point in saving 7% of 10 nanoseconds. Since
awk is needed in GRASS it can also be used here.

Why not using efforts for more important things?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates to wingrass-extralibs

[marco.pasetti]

Hi Paul,
 
just few questions:
1) did you used /win subdirectory to compile?
2) did you performed make test?
 
I did it, and had lots of "FAILED"!
 
Marco



Da: [EMAIL PROTECTED] per conto di Paul Kelly
Inviato: lun 03/03/2008 12.06
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] Updates to wingrass-extralibs



Spurred on by the work that Marco is doing, I've finally got around to
packaging the new versions of essential libraries for WinGRASS that I
compiled a couple of months ago. In case it is helpful to anybody, the
13MB file wingrass-extralibs-20080303.tar.gz now at
http://www.stjohnspoint.co.uk/grass/ contains the following versions of
libraries:
xdr-4.0-mingw32
proj-4.6.0
gdal-1.5.0
fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
tcl-8.5.0
tk-8.5.0

I have copies of all the source packages but I don't have the
bandwidth/diskspace really to make them available there to download as
well, so this can't be considered an official binary distribution of them.
Nevertheless I hope it is useful.

I didn't compile anything else as I found I was able to get all the other
dependencies from GnuWin32 (http://gnuwin32.sourceforge.net/), i.e.
libintl, libjpeg, libpng, zlib, libtiff, freetype, curses. No point in
reinventing the wheel when they are already available in an easy-to-use
format.

The 13MB file includes all the libraries and associated utility programs,
source headers and import libraries etc. necessary for compiling.
Obviously only the .dlls (and maybe even then not all of them) need to go
into a GRASS binary distribution, so the size would be much smaller. It's
normally useful though to include a couple of the main GDAL utility
programs: gdalwarp, gdalinfo and so on. nad2bin from the PROJ distribution
is required, and cs2cs is very useful.

I realise this is slightly different from the approach Marco is taking, in
that I'm directing people to GnuWin32 for the stuff that they have
available already - again that's just laziness on my part really but I
think it will be less work in the future.

The great thing about this now is that we can include the Tcl/Tk DLLs in
the binary distribution and don't have to ask people to install a separate
Tcl/Tk any more.

Also I don't have a lot of time to maintain this either, but if someone
wants to run a relatively stripped-down WinGRASS and compile it themselves
it might just be useful, so I thought I'd put it out there to complement
Marco's work.

Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] about SWIG Python interface...

[Hamish]

G. Allegri wrote:
> I'm very much interested to the SWIG Python interface, as I'm
>  considering some investments to do with Grass functionalities. I'm
>  going to test the methods used by JGrass to interface Java with
>  Grass native commands,

Oh, just like there is already swig/python and swig/perl for GRASS
there could be swig/java too if someone wanted to work on that.
  http://www.swig.org/Doc1.3/Java.html

How does JGrass do it now? Do they link to the GRASS C API or just
modules? (the modules generally give enough low level control to not
need to use the C API much)


> but I think it would be a great improvemente to support it for
> Python too, as many non-programmer users use it

I am encouraged for the world by the many hints that Python may become
a de facto scripting standard for geo-scientists. It would be a Good
Thing.


Hamish




  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] about SWIG Python interface...

[Hamish]

G. Allegri  wrote:
> I'm very much interested to the SWIG Python interface, as I'm
>  considering some investments to do with Grass functionalities. I'm
>  going to test the methods used by JGrass to interface Java with
>  Grass native commands, but I think it would be a great improvemente
>  to support it for Python too, as many non-programmer users use it
>  (also the ones coming from ArcGIS world!).
>
>  The question is: as Martin says, it's still in a "pre-alpha" state,

well, it basically works, AFAICT. So I'd call it in mid-alpha state.
:)

>  but do you think it will be developed more and supported?

it's a loop: it gets developed more once it is working well and more
people are using it. my advice is to try it and see for yourself!


Start with reading swig/python/README and:
cd swig/python
make

and see what happens. if there are build problems they are probably
easy to fix.

After it builds, try the example found in the README and the ones in
the GRASS Wiki python pages linked from my last m.distance post.


What GRASS lib fns are you interested in using?


>  Is the work done by Alessandro Frigeri (Univeristy of Perugia), to
>  implement a SWIG/Python interface [1], already included in the
> actual code?
...
>  [1]
>
http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1

I don't know, but I don't think so.


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Hamish pisze:

Maciej Sieczka wrote:

On Ubuntu Gutsy it's like Ivan says - echo "!" is ok in scripts,
fails on command line.

I'm about to switch to Debian. I'll check this if not forget to.



It could very well be user error & bad memory on my behalf. But
regardless it can only be a good thing to '' quote !s.


Fully aggreed. I'll try not to forget to stick to that.

Maciek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Hamish]

Maciej Sieczka wrote:
> On Ubuntu Gutsy it's like Ivan says - echo "!" is ok in scripts,
> fails on command line.
> 
> I'm about to switch to Debian. I'll check this if not forget to.


It could very well be user error & bad memory on my behalf. But
regardless it can only be a good thing to '' quote !s.


H



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates to wingrass-extralibs

[Hamish]

Paul Kelly wrote:
> Spurred on by the work that Marco is doing, I've finally got around
> to packaging the new versions of essential libraries for WinGRASS\
> that I compiled a couple of months ago. In case it is helpful to
> anybody, the 13MB file wingrass-extralibs-20080303.tar.gz now at 
> http://www.stjohnspoint.co.uk/grass/ contains the following versions
> of libraries:
> xdr-4.0-mingw32
> proj-4.6.0
> gdal-1.5.0
> fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
> tcl-8.5.0
> tk-8.5.0
> 
> I have copies of all the source packages but I don't have the 
> bandwidth/diskspace really to make them available there to download
> as well, so this can't be considered an official binary distribution
> of them. 
> Nevertheless I hope it is useful.


Hi Paul,

why not upload to:
http://trac.osgeo.org/grass/browser/grass-web/trunk/grass63/binary/mswindows/
?

or open a gmail account, then you get 100MB webspace from
pages.google.com. (the last time I tried the max file size you could
serve was 10MB)


Hamish



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] Updates to wingrass-extralibs

[marco.pasetti]

Hi Paul,
 
it seems to be a head to head race! :-D
 
anyway... I agree about "not reinventing the wheel"... but sometimes I also 
think that it's necessary, because not all GnuWin32 libs are updated and, the 
biggest problem, they are built using VS, not MinGW; that actually could not be 
a problem, but I'm quite sure that GDAL has problems linking against VS built 
libraries.
 
Regards
 
Marco
 
PS: Paul, I don't want to overtake you, I don't like those useless races... 
just wanted to help ;-)



Da: [EMAIL PROTECTED] per conto di Paul Kelly
Inviato: lun 03/03/2008 12.06
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] Updates to wingrass-extralibs



Spurred on by the work that Marco is doing, I've finally got around to
packaging the new versions of essential libraries for WinGRASS that I
compiled a couple of months ago. In case it is helpful to anybody, the
13MB file wingrass-extralibs-20080303.tar.gz now at
http://www.stjohnspoint.co.uk/grass/ contains the following versions of
libraries:
xdr-4.0-mingw32
proj-4.6.0
gdal-1.5.0
fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
tcl-8.5.0
tk-8.5.0

I have copies of all the source packages but I don't have the
bandwidth/diskspace really to make them available there to download as
well, so this can't be considered an official binary distribution of them.
Nevertheless I hope it is useful.

I didn't compile anything else as I found I was able to get all the other
dependencies from GnuWin32 (http://gnuwin32.sourceforge.net/), i.e.
libintl, libjpeg, libpng, zlib, libtiff, freetype, curses. No point in
reinventing the wheel when they are already available in an easy-to-use
format.

The 13MB file includes all the libraries and associated utility programs,
source headers and import libraries etc. necessary for compiling.
Obviously only the .dlls (and maybe even then not all of them) need to go
into a GRASS binary distribution, so the size would be much smaller. It's
normally useful though to include a couple of the main GDAL utility
programs: gdalwarp, gdalinfo and so on. nad2bin from the PROJ distribution
is required, and cs2cs is very useful.

I realise this is slightly different from the approach Marco is taking, in
that I'm directing people to GnuWin32 for the stuff that they have
available already - again that's just laziness on my part really but I
think it will be less work in the future.

The great thing about this now is that we can include the Tcl/Tk DLLs in
the binary distribution and don't have to ask people to install a separate
Tcl/Tk any more.

Also I don't have a lot of time to maintain this either, but if someone
wants to run a relatively stripped-down WinGRASS and compile it themselves
it might just be useful, so I thought I'd put it out there to complement
Marco's work.

Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates to wingrass-extralibs

[Paul Kelly]

On Mon, 3 Mar 2008, Paul Kelly wrote:

Spurred on by the work that Marco is doing, I've finally got around to 
packaging the new versions of essential libraries for WinGRASS that I 
compiled a couple of months ago. In case it is helpful to anybody, the 13MB 
file wingrass-extralibs-20080303.tar.gz now at 
http://www.stjohnspoint.co.uk/grass/ contains the following versions of 
libraries:

xdr-4.0-mingw32
proj-4.6.0
gdal-1.5.0
fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
tcl-8.5.0
tk-8.5.0


Just thinking over this, I realise some of those will be pretty unusable 
without the correct versions of the DLLs from the Gnuwin32 packages that I 
compiled them against. Unfortunately I don't seem to have properly 
documented that anywhere... but it might be obvious from the Windows DLL 
not found error messages if anybody has the patience for that.


Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

Hamish pisze:

Ivan Shmakov wrote:
bash $ echo "hello, world!" 
bash: !": event not found
bash $ 

...

Moreover, it's an optional feature even in Bash (check the
``History expansion'' section in bash(1)):

...

In particular, this feature never gets enabled by default for
Shell scripts.


apparently "never" doesn't include Debian, where (IIRC) I had seen the
"!" error oddly happening mid-script, before all the quoting fixes.


On Ubuntu Gutsy it's like Ivan says - echo "!" is ok in scripts, fails 
on command line.


I'm about to switch to Debian. I'll check this if not forget to.

Maciek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Updates to wingrass-extralibs

[Paul Kelly]

Spurred on by the work that Marco is doing, I've finally got around to 
packaging the new versions of essential libraries for WinGRASS that I 
compiled a couple of months ago. In case it is helpful to anybody, the 
13MB file wingrass-extralibs-20080303.tar.gz now at 
http://www.stjohnspoint.co.uk/grass/ contains the following versions of 
libraries:

xdr-4.0-mingw32
proj-4.6.0
gdal-1.5.0
fftw-2.1.5 (this was before I realised FFTW 3.x is OK with GRASS)
tcl-8.5.0
tk-8.5.0

I have copies of all the source packages but I don't have the 
bandwidth/diskspace really to make them available there to download as 
well, so this can't be considered an official binary distribution of them. 
Nevertheless I hope it is useful.


I didn't compile anything else as I found I was able to get all the other 
dependencies from GnuWin32 (http://gnuwin32.sourceforge.net/), i.e. 
libintl, libjpeg, libpng, zlib, libtiff, freetype, curses. No point in 
reinventing the wheel when they are already available in an easy-to-use 
format.


The 13MB file includes all the libraries and associated utility programs, 
source headers and import libraries etc. necessary for compiling. 
Obviously only the .dlls (and maybe even then not all of them) need to go 
into a GRASS binary distribution, so the size would be much smaller. It's 
normally useful though to include a couple of the main GDAL utility 
programs: gdalwarp, gdalinfo and so on. nad2bin from the PROJ distribution 
is required, and cs2cs is very useful.


I realise this is slightly different from the approach Marco is taking, in 
that I'm directing people to GnuWin32 for the stuff that they have 
available already - again that's just laziness on my part really but I 
think it will be less work in the future.


The great thing about this now is that we can include the Tcl/Tk DLLs in 
the binary distribution and don't have to ask people to install a separate 
Tcl/Tk any more.


Also I don't have a lot of time to maintain this either, but if someone 
wants to run a relatively stripped-down WinGRASS and compile it themselves 
it might just be useful, so I thought I'd put it out there to complement 
Marco's work.


Paul
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] about SWIG Python interface...

[G. Allegri]

I'm very much interested to the SWIG Python interface, as I'm
 considering some investments to do with Grass functionalities. I'm
 going to test the methods used by JGrass to interface Java with Grass
 native commands, but I think it would be a great improvemente to
 support it for Python too, as many non-programmer users use it (also
 the ones coming from ArcGIS world!).

 The question is: as Martin says, it's still in a "pre-alpha" state,
 but do you think it will be developed more and supported?

 Is the work done by Alessandro Frigeri (Univeristy of Perugia), to
 implement a SWIG/Python interface [1], already included in the actual
 code?

 Giovanni

 [1] 
http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r30420 - grass/trunk/scripts/v.db.renamecol

[Maciej Sieczka]

>> Markus wrote:
> Maciek wrote:
Hamish pisze:


are you sure that this is portable?

if [ "$driver" = "dbf" ] ; then
-  NAMELEN=`echo "$newcol" | wc -c | awk '{print $1}'`
+  NAMELEN=`echo "$newcol" | wc -c`

I darkly remember that some "wc" programs insert odd spaces which
would break the script.


I haven't heard of it. Maybe you are right. Let's ask on the dev ML. 
Thoughts, Anybody?



'wc -c filename' will produce output like: '17 filename' (needing awk
or cut) while 'wc -c < filename' or 'cat filename | wc -c' will produce
output like: '17'. Maybe that is the dark memory?


That could explain the " awk '{print $1}' ". Markus?


For curiosity, what's so bad about using awk?


Invoking the allmighty awk just to do what cut is designed for seems an 
overkill to me. Awk is not needed for anything in v.db.renamecol. Cut 
suffices. Keep it simple, the UNIX way of specialized tools and stuff.



speed?


Actually cut itself seems slightly slower than awk for this sort of task:

$ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | cut -d" " -f2 > 
/dev/null ; x=`expr $x + 1`; done


on my machine is about 7% slower than

$ x=0; time while [ $x -lt 1000 ]; do echo "raz dwa" | awk '{print $2}' 
> /dev/null ; x=`expr $x + 1`; done



On the other hand, after replacing all awk with cut in the script, 
removing the test for awk's presence:


 check if we have awk
if [ ! -x "`which awk`" ] ; then
g.message -e "awk required, please install awk or gawk first"
exit 1
fi

resulted in a speed boost. In the end, v.db.renamcol without awk is as 
fast as it was with awk. I you want to test, try the following:


$ v.random pts n=10 --o; v.db.addtable pts col="huha1 integer
$ x=0; time while [ $x -lt 50 ]; do v.db.renamecol map=pts 
col=huha1,huha2; v.db.renamecol map=pts col=huha2,huha1; x=`expr $x + 
1`; done


using v.db.renamecol as it was with awk, and with all of awk removed or 
replaced by cut.



It cannot be removed from all scripts* so why remove from any?  [*] needed for 
FP
math (and less hard to find than bc), fancy stuff like v.in.mapgen,  ...


I know it is used widely in GRASS scripts. Yet there is no reason to 
require it in a script which does not need it (for instance unless there 
is FP maths in v.db.renamecol).



  setup temporary file
 TMP="`g.tempfile pid=$$`"
 if [ $? -ne 0 ] || [ -z "$TMP" ] ; then
-g.message -e "Unable to create temporary files" 
+g.message -e "Unable to create temporary files."

 exit 1
 fi

IIUC the message standardization has been to not end single sentence
warnings and errors with a ".", only to do that with module
descriptions. (I don't know if I agree with that all the time, but a
lot of effort has gone in to making it that way)


A sentence without a period? Strange and not grammatical. What would be 
the rationalle?


Even if it was agreed, I can't find it documented in SUBMITTING, 
SUBMITTING_SCRIPTS nor g.message man. Actually, the SUBMITTING_SCRIPTS 
examples indirectly suggest that both with and without period are 
allowed (see section 11).


The WIKI confirms the latter: "Be consistent with periods. Either end 
all phrases with a period or none", "Punctuated events, such as errors, 
deserve a period" [1]. This is contrary to what you suggest in your 
email now.


FWIW, the original v.db.renamecol used both conventions - with and 
without ".". I added periods to all sentences - correct in terms of 
grammar and GRASS standards I guess.



 if [ -z "$table" ] ; then
-   g.message 'There is no table connected to this map! Cannot rename
any column.'
+   g.message -e "There is no table connected to input vector map!
Cannot rename any column."
cleanup
exit 1
 fi

and r30418: v.db.dropcol
@@ -91,5 +80,5 @@
 exitprocedure()
 {
- g.message -e 'User break!'
+ g.message -e "User break!"
  cleanup
  exit 1

"!" is a special shell char and must be quoted in 'single quotes'.

GRASS> g.message -e "this will not work!, ok?"
bash: !,: event not found


My bad. Very sorry. Correcting it right away.

Maciek

[1]http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] WinGRASS & Tcl/Tk

[marco.pasetti]

Perfect! 
thanks
 
Marco



Da: [EMAIL PROTECTED] per conto di [EMAIL PROTECTED]
Inviato: lun 03/03/2008 11.42
A: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] WinGRASS & Tcl/Tk



Tcl is the programming language, Tk provides the graphical user
interface on top of that. So you need both:

Compile and install Tcl (using MSYS):

tar -xzvf tcl8.5.1-src.tar.gz
cd tcl8.5.1/win
./configure --prefix=/usr/local
make
make install

cp /usr/local/bin/tclsh85.exe /usr/local/bin/tclsh.exe


Install the Tk GUI widgets:

tar -xzvf tk8.5.1-src.tar.gz
cd tk8.5.1/win
./configure --prefix=/usr/local
make
make install

cp /usr/local/bin/wish84.exe /usr/local/bin/wish.exe


Hope this helps.

Good luck,

Benjamin


[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm again on Tcl/Tk issue for Windows;
> Paul Kelly tells that he tested latest 8.5 release finding it working,
> so I'm going to compile that release!
> But here's another question, I never faced the problem of compile Tcl
> (always used precompiled binaries), and on the web site I found two
> sources, Tcl and Tk; what to do? Compile both? same or different prefix?
>
> Thanks
>
> Marco

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS & Tcl/Tk

[benjamin . ducke]

Tcl is the programming language, Tk provides the graphical user
interface on top of that. So you need both:

Compile and install Tcl (using MSYS):

tar -xzvf tcl8.5.1-src.tar.gz
cd tcl8.5.1/win
./configure --prefix=/usr/local
make
make install

cp /usr/local/bin/tclsh85.exe /usr/local/bin/tclsh.exe


Install the Tk GUI widgets:

tar -xzvf tk8.5.1-src.tar.gz
cd tk8.5.1/win
./configure --prefix=/usr/local
make
make install

cp /usr/local/bin/wish84.exe /usr/local/bin/wish.exe


Hope this helps.

Good luck,

Benjamin


[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm again on Tcl/Tk issue for Windows;
> Paul Kelly tells that he tested latest 8.5 release finding it working,
> so I'm going to compile that release!
> But here's another question, I never faced the problem of compile Tcl
> (always used precompiled binaries), and on the web site I found two
> sources, Tcl and Tk; what to do? Compile both? same or different prefix?
>
> Thanks
>
> Marco

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] WinGRASS & Tcl/Tk

[marco.pasetti]

Hi,
 
I'm again on Tcl/Tk issue for Windows;
Paul Kelly tells that he tested latest 8.5 release finding it working, so I'm 
going to compile that release!
But here's another question, I never faced the problem of compile Tcl (always 
used precompiled binaries), and on the web site I found two sources, Tcl and 
Tk; what to do? Compile both? same or different prefix?
 
Thanks
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.mlist: minor improvements

[Ivan Shmakov]

> Ivan Shmakov <[EMAIL PROTECTED]> writes:

 > I've somewhat improved `g.mlist' with respect to some ``invalid''
 > user input cases.  Also, I've reduced off one `grep' invocation and
 > replaced `grep -v '^$'' with `grep .', which is supposed to be
 > somewhat faster.

 > scripts/g.mlist/g.mlist (do_list): More Shell quoting; reduced off
 > one `grep'; use `grep .' instead of `grep -v '^$''.

 > Unless there're be any objections, I'm going to commit the change.

I've now committed the change.

http://trac.osgeo.org/grass/changeset/30437

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] m.distance / SWIG-Python interface + passing pointers with SWIG [was: d.measure w/ bearing]

[Hamish]

> Martin Landa wrote:
> > it would be good to use d.measure or something like g.measure in
> > wxGUI too instead of using Python-based function for distance
> > calculation (at least it would make sense for LL projections)?

Hamish wrote:
> Yes, we should use existing library functions whenever possible, in
> this case those found in lib/gis/distance.c and lib/gis/geodist.c.
> call it m.distance;
...
> It would be very easy to write in C but from a learning exercise
> perspective it seems like a perfect thing to try doing with
> SWIG+Python, and perhaps too simple a thing to have as a generic
> module??


Python-SWIG m.distance (working) prototype:
  http://grass.gdf-hannover.de/wiki/PythonSwigExamples


Starting from the shell it takes about 0.5 sec to run. ie very slow.
But that includes the overhead of starting #!/usr/bin/python and
importing the required modules. If the same code was called from an
already running python session with all that stuff already loaded, I
expect it would be highly fast.  (FWIW unstripped libgis.so is ~900kb,
_python_grass6.so ~1.7mb)


G_area_of_polygon() needs x and y vertices passed to it as memory
address pointers to two double-FP arrays. I really don't know much
about SWIG but a web search turned up a Python module called NumPtr
(Numeric Pointer) for doing that. It seems pretty simple. Instructions
for it are on the wiki link above.


If there isn't already a built-in easier way that I missed, perhaps we
could add that code as a contrib in our swig/python/ dir? It is GPL2,
less than 100kb, and several years without a new version. Hopefully the
lack of upstream activity means that it is mature, and not abandoned.
It is a simple enough thing that it wouldn't surprise me if it was
mature. And because it is so simple and small it seems more trouble
than it would be worth to insist that it be an external dependency, or
a be a significant burden to maintain.



To build the SWIG-Python interface I had to hack the Makefile a little.

I also had to install the "swig" package on my machine to get
/usr/bin/swig, as compiling failed when it couldn't find it. Maybe add
a check for that program in the main './configure --with-python'? (for
one thing it would give --with-python something useful to do which
currently AFAIK it doesn't?)


# the Makefile problem:
cd swig/python/
make

In file included from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,
 from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
 from python_grass6_wrap.c:2933:
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:22:21:
error: ogr_api.h: No such file or directory



local solution:
 edit swig/python/Makefile and add -I/usr/include/gdal to CFLAGS.

not sure what the correct fix in swig/python/Makefile.in for that would
be or if the error is really in the vector includes.

Should 'make clean' remove the Makefile or should that only happen with
'make distclean'?



see also my notes on an earlier attempt at building swig/python/:
  http://thread.gmane.org/gmane.comp.gis.grass.devel/20751


Hamish




  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: R: [GRASS-dev] New Binary Package Project for winGRASS

[marco.pasetti]

Moritz,
 
what release of TCL?
 
Marco



Da: Moritz Lennert [mailto:[EMAIL PROTECTED]
Inviato: dom 02/03/2008 20.47
A: [EMAIL PROTECTED]
Cc: 'Benjamin Ducke'; 'GRASS Developer Mailing List'
Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS



On 01/03/08 22:14, Marco Pasetti wrote:
> Hi Benjamin,
>
>> Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and
> can be distributed freely.
>
> Good question! When I planned the work I dind't considered this option,
> because on the wiki it was (it is) suggested to use ActiveTcl;
> Probably I should reconsider to build Tcl/Tk from source using MinGW, and
> then rebuild GRASS...
>
> Moritz, what do you think about?

Go ahead for GPL'd tcl/tk.

Moritz


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] New Binary Package Project for winGRASS

[marco.pasetti]

Hi friends,
 
yesterday I decided to take a day off, so today I'll take some time before to 
reply to all... I'm going on in date-received order ;-)
 
>We have a GRASS icon for MS Windows in SVN, could it be used on the top
>right corner of the windows and the taskbar?  lib/init/grass.ico
 
about the icon, I found it, but it doesn't have the transparent layer! so I 
decided to create a new one, using the official png logo, and stretching the 
image to constrain it to a squared poroportion (as done for the previous icon); 
actually, leaving the original proportion, makes the icon less visible in 16px 
format...
The zip archive contains the multi-icon in 16,24,32 and 48 px and the png used 
to create the icon.
 
this is the address: 
http://www.webalice.it/marco.pasetti/grass/grass_icon_package.zip
 
Marco
 
 



Da: [EMAIL PROTECTED] per conto di Hamish
Inviato: dom 02/03/2008 19.59
A: Martin Landa
Cc: GRASS Developer Mailing List
Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS



Martin Landa wrote:
> Some screenshots
>
http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#MS_Windows


Very nice! these will look great on the main "platforms" screenshots
page.

One thing I noticed:
The start screen screenshot includes "C:/grassdata" which will
instantly look very wrong to MS Windows-only users.
?
Can C:\ be used or does it need to be a forward slash?


Great use of the "grass" desktop background!

We have a GRASS icon for MS Windows in SVN, could it be used on the top
right corner of the windows and the taskbar?  lib/init/grass.ico

In the GIS manager window layer list it possible to pack the [100%] box
at the right edge of the line?


Hamish



  

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: [GRASS-dev] winGRASS RC5 Fails on Creating a New Projection

[marco.pasetti]

Hi Markus,
 
I tried to use g.proj from command line and it doesn't report errors... but 
reopening GRASS I don't have the new location!
I should better learn GRASS ;-)
I'll retry later, now I have to recompile GRASS with the new built (not 
installed) Tcl version;
About that, I'm still confused about the release: Paul tells (and I trust him) 
that 8.15 is OK, while recently on the list I found lots of messages telling 
that it has problem with latest GRASS release.
What do you think about?
 
Regards,
 
Marco



Da: [EMAIL PROTECTED] per conto di Markus Neteler
Inviato: dom 02/03/2008 1.10
A: [EMAIL PROTECTED]
Oggetto: Re: [GRASS-dev] winGRASS RC5 Fails on Creating a New Projection



Hi Marco,

could you try the same on command line?

Markus

On Sat, Mar 1, 2008 at 6:59 PM, Marco Pasetti <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  >From startpanel, define new location with epsg codes
>  Used 4326 for WGS84
>  Returned the following message:
>
>  g.proj returned the following informational message: child killed: SIGABRT
>
>  Why?
>
>  Thanks
>
>  Marco
>
>  ___
>  grass-dev mailing list
>  grass-dev@lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/grass-dev
>



--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #67: r.out.gdal type= and no-data issues

[GRASS GIS]

#67: r.out.gdal type= and no-data issues
---+
  Reporter:  sieczka   |   Owner:  martinl
  Type:  defect|  Status:  assigned   
  Priority:  critical  |   Milestone:  6.3.0  
 Component:  default   | Version:  unspecified
Resolution:|Keywords:  gdal   
---+
Comment (by martinl):

 Replying to [comment:1 martinl]:
 > Please test the attached patch. Martin

 Patch applied in trunk, r30433. Martin

-- 
Ticket URL: 
GRASS GIS 
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 2D to 3D points

[Hamish]

> >> Benjamin Ducke wrote:
> >>> How about a little wrapper script for v.transform that simplifies
> >>> this action?

Dylan:
> > However, doesn't it make more sense to put that code (for
> > points) into v.extrude ? Or, is v.extrude primarily for areas 
> > by design?

Michael:
> IMHO, v.type is a much better place to put this. v.type is already  
> designed to transform vector objects from one type of vector object  
> to another. Changing a vector object from a 2D point to a 3D point  
> seems to fit this concept well.

As the functionality is already written into a C module, and v.type is
not conspicuously missing the feature or obviously+naturally matching
the task, IMO it is better to use a simple wrapper script with an
obvious+natural name.

I wonder if such a script could call another module for the reverse
proceedure? (v.out.ascii directly piped back into v.in.ascii (without
-z)?, or v.transform + db.in.ogr? or some new C code?)

for the 2D -> 3D case the clearest way would be to pipe
'v.out.ascii.db | v.in.ascii -z' and then copy the table. But to do
that properly v.out.ascii would need to finally to have the DB output
code written. (probably pretty simple to do; the v.out.ascii.db script
can be found in wiki addons)


> (And while we're at it, v.type should
> be changed to work like v.type.sh).

the module command line interface can't change until GRASS 7.
Hence we have v.type.sh, for once it's not due to long queues.

 
> v.transform is really a georectifying module for vector objects. It's
> a conceptual stretch to include transforming 2D to 3D points there-- 
> though it does work.

Hence using a wrapper function with a more intuitive name and only
expose the relevant options.



Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

[Hamish]

> Michael:
> > > I just tried to check out any updates to d.measure and found that
> > > it doesn't run on my Mac. It produces a bus error. I don't need
> > > it, but folks should be aware of this.

> Dylan:
> > I do not have access to a Mac, but the module seems to compile and
> > run fine on Linux x86. 
> > 
> > Could it be the call to atan2() -- perhaps the math library is not
> > accessed the same way on Mac OS X ? 

Hamish:
> I have just tested here using William's 6.3 binaries from a few weeks
> ago and I too get a Bus error when trying to start d.measure.

i.e. it's got nothing to do with the bearing patch.


Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev