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

[Ivan Shmakov]

> Hamish  <[EMAIL PROTECTED]> writes:

 >> 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.

It's probably so.  It seems that `!' cannot be granted its
special meaning within the non-interactive Bash (even with
explicit `set -H'.)

 > But regardless it can only be a good thing to '' quote !s.

I guess there're enough scripts with unquoted `!' outside of
GRASS, and I believe that the special treatment of `!' violates
POSIX.  So, the only good thing for the user would be to fix the
Shell.

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

[GRASS-dev] Re: [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:  martinl  
  Type:  task |  Status:  assigned 
  Priority:  blocker  |   Milestone:  6.3.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  wx, gui  
--+-
Comment (by hamish):

 .gwx isn't associated with anything geospatial or common, and seems a good
 fit. how about that?

 or these, which AFAICT are unused
  * .gxw (Grass wX Workspace)
  * .gww (  "   Wx ")



 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

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

[Markus Neteler]

Eric,

please tell us the commit(s) from

http://trac.osgeo.org/grass/timeline

to better understand it.

Markus

On Mon, Mar 3, 2008 at 7:11 PM, Patton, Eric <[EMAIL PROTECTED]> wrote:
> >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
>



-- 
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: GDAL 1.5.0 Build Error With GRASS Support

[Markus Neteler]

Hi Marco,
(cc Frank)

I assume that the plugin for gdal 1.4.3 also works for gdal 1.5.0.

Markus

On Tue, Mar 4, 2008 at 10:51 PM, Marco Pasetti <[EMAIL PROTECTED]> wrote:
> Hi Markus,
>
>  I already checked it out... but it seems that there's still not a
>  grass-plugin for latest gdal release (1.5.0); the last I found is for gdal
>  1.4.3
>
>  Marco
>
>  -Messaggio originale-
>  Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di
>  Markus Neteler
>  Inviato: martedì 4 marzo 2008 22.41
>  A: Marco Pasetti
>  Cc: grass-dev@lists.osgeo.org
>  Oggetto: Re: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support
>
>
>
>  Hi Marco,
>
>  please don't build GDAL with direct GRASS support but use the plugin instead
>  (way easier...). See
>
>  http://grass.gdf-hannover.de/wiki/Compile_and_install_GRASS_and_QGIS_with_GD
>  AL/OGR_Plugin
>
>  cheers
>  Markus
>
>  On Tue, Mar 4, 2008 at 9:24 PM, Marco Pasetti <[EMAIL PROTECTED]>
>  wrote:
>  >
>  >
>  > Problem fixed
>  >
>  > needed only to add --with-local=/usr/local in configure
>  >
>  > Marco
>  >
>  >  
>  >  Da: [EMAIL PROTECTED]
>  > [mailto:[EMAIL PROTECTED] Per conto di
>  > [EMAIL PROTECTED]
>  > Inviato: martedì 4 marzo 2008 18.03
>  > A: grass-dev@lists.osgeo.org
>  > Oggetto: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support
>  >
>  >
>  >
>  >
>  >
>  > Hi,
>  >
>  > I'm building GDAL 1.5.0 with GRASS support; it gives the following
>  > error:
>  >
>  > In file included from grass57dataset.cpp:45:
>  > C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22:
>  > proj_api.h: No such file or directory In file included from
>  > grass57dataset.cpp:45:
>  > C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO
>  > C++ forbids declaration of `projPJ' with no type
>  > C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error:
>  > expected `;' before '*' token
>  > make[2]: *** [../o/grass57dataset.o] Error 1
>  > make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
>  > make[1]: *** [grass-install-obj] Error 2
>  > make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
>  > make: *** [frmts-target] Error 2
>  >
>  > proj_api.h is present in /usr/local/include, while
>  > /usr/local/grass-6.3.0RC5/include/grass has gproj_api.h should I force
>  > GRASS code to include gproj_api.h instead of proj_api.h or walk around
>  > the problem adding /usr/local/include to PATH before launch make
>  > command?
>  >
>  > 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/
>
>



-- 
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] GDAL 1.5.0 Build Error With GRASS Support

[Marco Pasetti]

Hi Markus,

I already checked it out... but it seems that there's still not a
grass-plugin for latest gdal release (1.5.0); the last I found is for gdal
1.4.3

Marco

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di
Markus Neteler
Inviato: martedì 4 marzo 2008 22.41
A: Marco Pasetti
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support

Hi Marco,

please don't build GDAL with direct GRASS support but use the plugin instead
(way easier...). See

http://grass.gdf-hannover.de/wiki/Compile_and_install_GRASS_and_QGIS_with_GD
AL/OGR_Plugin

cheers
Markus

On Tue, Mar 4, 2008 at 9:24 PM, Marco Pasetti <[EMAIL PROTECTED]>
wrote:
>
>
> Problem fixed
>
> needed only to add --with-local=/usr/local in configure
>
> Marco
>
>  
>  Da: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Per conto di 
> [EMAIL PROTECTED]
> Inviato: martedì 4 marzo 2008 18.03
> A: grass-dev@lists.osgeo.org
> Oggetto: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support
>
>
>
>
>
> Hi,
>
> I'm building GDAL 1.5.0 with GRASS support; it gives the following 
> error:
>
> In file included from grass57dataset.cpp:45:
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: 
> proj_api.h: No such file or directory In file included from 
> grass57dataset.cpp:45:
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO 
> C++ forbids declaration of `projPJ' with no type
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: 
> expected `;' before '*' token
> make[2]: *** [../o/grass57dataset.o] Error 1
> make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
> make[1]: *** [grass-install-obj] Error 2
> make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
> make: *** [frmts-target] Error 2
>
> proj_api.h is present in /usr/local/include, while 
> /usr/local/grass-6.3.0RC5/include/grass has gproj_api.h should I force 
> GRASS code to include gproj_api.h instead of proj_api.h or walk around 
> the problem adding /usr/local/include to PATH before launch make 
> command?
>
> 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

Re: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support

[Markus Neteler]

Hi Marco,

please don't build GDAL with direct GRASS support but use the plugin instead
(way easier...). See

http://grass.gdf-hannover.de/wiki/Compile_and_install_GRASS_and_QGIS_with_GDAL/OGR_Plugin

cheers
Markus

On Tue, Mar 4, 2008 at 9:24 PM, Marco Pasetti <[EMAIL PROTECTED]> wrote:
>
>
> Problem fixed
>
> needed only to add --with-local=/usr/local in configure
>
> Marco
>
>  
>  Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> [EMAIL PROTECTED]
> Inviato: martedì 4 marzo 2008 18.03
> A: grass-dev@lists.osgeo.org
> Oggetto: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support
>
>
>
>
>
> Hi,
>
> I'm building GDAL 1.5.0 with GRASS support;
> it gives the following error:
>
> In file included from grass57dataset.cpp:45:
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: proj_api.h: No
> such file or directory
> In file included from grass57dataset.cpp:45:
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO C++
> forbids declaration of `projPJ' with no type
> C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: expected
> `;' before '*' token
> make[2]: *** [../o/grass57dataset.o] Error 1
> make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
> make[1]: *** [grass-install-obj] Error 2
> make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
> make: *** [frmts-target] Error 2
>
> proj_api.h is present in /usr/local/include, while
> /usr/local/grass-6.3.0RC5/include/grass has gproj_api.h
> should I force GRASS code to include gproj_api.h instead of proj_api.h or
> walk around the problem adding /usr/local/include to PATH before launch make
> command?
>
> 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] [GRASS GIS] #80: Convert tcl grc to wxpython version

[GRASS GIS]

#80: Convert tcl grc to wxpython version
-+--
 Reporter:  dersh|   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  minor|   Milestone:  6.4.0
Component:  Python   | Version:  unspecified  
 Keywords:  gis tcl wx   |  
-+--
 When using the wxpython gui there is no way to open an older grc file that
 was created with gis.m.
 As the intent is that the wxpython GUI take-over for the tcl GUI, then it
 is important that users will be able to open their existing files.  Long
 time users will not be willing to move to the wx interface if they can't
 open existing files.
 So it is important that a converter be created to keep backward
 compatibility.  This could be either a stand-alone tool, or it could just
 be a part of the open command within the wxpython gui.

 Thanks,

-- 
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] #77: Change wxGui workspace file extension away from .grc

[GRASS GIS]

#77: Change wxGui workspace file extension away from .grc
--+-
  Reporter:  hamish   |   Owner:  martinl  
  Type:  task |  Status:  assigned 
  Priority:  blocker  |   Milestone:  6.3.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  wx, gui  
--+-
Changes (by martinl):

  * status:  new => assigned
  * owner:  grass-dev@lists.osgeo.org => martinl
 * cc: grass-dev@lists.osgeo.org (added)

-- 
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] #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
Resolution:   |Keywords:  wx, gui  
--+-
Comment (by martinl):

 From grass-dev ML by Michael Barton:

 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.

 Martin: yes, gws is already taken (1) moreover !GeoMedia -- too much
 related, 'gwsf' would be better.

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

 Martin: I agree.

 Anyone have any objection to *.gwsf?

 Martin: not really, just like 3-letter extensions. But I haven't found
 something reasonable, some more ideas here?

 (1) http://filext.com/file-extension/gws

-- 
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] GDAL 1.5.0 Build Error With GRASS Support

[Marco Pasetti]

Problem fixed
 
needed only to add --with-local=/usr/local in configure
 
Marco

  _  

Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per conto di
[EMAIL PROTECTED]
Inviato: martedì 4 marzo 2008 18.03
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support


Hi,
 
I'm building GDAL 1.5.0 with GRASS support;
it gives the following error:
 
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: proj_api.h: No
such file or directory
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO C++
forbids declaration of `projPJ' with no type
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: expected
`;' before '*' token
make[2]: *** [../o/grass57dataset.o] Error 1
make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
make[1]: *** [grass-install-obj] Error 2
make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
make: *** [frmts-target] Error 2
 
proj_api.h is present in /usr/local/include, while
/usr/local/grass-6.3.0RC5/include/grass has gproj_api.h
should I force GRASS code to include gproj_api.h instead of proj_api.h or
walk around the problem adding /usr/local/include to PATH before launch make
command?
 
Thanks
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

RE: [GRASS-dev] image rectification from command line only ?

[Nicolas MERLET]

So that's what I'll do. I let you know if I'm successful.
Thank you so much. Have a nice day.

Nicolas 

 

> -Original Message-
> From: Michael Barton [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 04, 2008 7:59 PM
> To: Nicolas MERLET
> Cc: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] image rectification from command line only ?
> 
> I don't know of any documentation for this. I guess just look at  
> existing examples. Perhaps make a test case and rectify them in.  
> That's what I did when working out the format for the GUI 
> versions of  
> this. You'll have to make a group and put the file into the group  
> folder.
> 
> Michael
> __
> Michael Barton, Professor
> Professor of Anthropology
> Director of Graduate Studies
> School of Human Diversity & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> Tempe, AZ  85287-2402
> USA
> 
> voice: 480-965-6262; fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> On Mar 4, 2008, at 11:32 AM, Nicolas MERLET wrote:
> 
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Michael  
> >> Barton
> >> Sent: Tuesday, March 04, 2008 6:38 PM
> >> To: grass-dev@lists.osgeo.org
> >> Subject: Re: [GRASS-dev] image rectification from command 
> line only ?
> >>
> >>
> >>
> >> On Mar 4, 2008, at 10:00 AM, 
> [EMAIL PROTECTED] wrote:
> >>
> >>> Date: Tue, 4 Mar 2008 17:04:27 +0100
> >>> From: "Nicolas MERLET" <[EMAIL PROTECTED]>
> >>> Subject: [GRASS-dev] image rectification from command line only ?
> >>> To: 
> >>> Message-ID: <[EMAIL PROTECTED]>
> >>> Content-Type: text/plain; charset="us-ascii"
> >>>
> >>>
> >>> hi all,
> >>>
> >>> i need to rectify an image automatically (i assume using
> >> i.points and
> >>> i.rectify). as far as i've been able to see, i.points is to use in
> >>> graphical
> >>> monitor mode ? so does anyone know how to use it from the command
> >>> line (and
> >>> only from the command line) ?
> >>>
> >>> thanks for helping...
> >>>
> >>> nicolas
> >>
> >> i.points lets a user interactively set ground control points (GCPs)
> >> for an unrectified image, using a rectified image. This particular
> >> process cannot be automated since it is interactive by definition.
> >>
> >> However, if you already know the ground coordinates of a set of xy
> >> points for an image, you can build a POINTS file and i.rectify will
> >> georectify the image from the command line.
> >>
> >> Michael
> >>
> >
> > that would be enough as my GCP are pre-calculated. however 
> i haven't  
> > found
> > any documentation about the POINTS files structure. where 
> can i find  
> > it ? (i
> > just have http://grass.itc.it/gdp/html_grass63/i.rectify.html)
> >
> > moreover, assuming we use i.rectify there's no paramater to give  
> > points, so
> > i suppose i just have to copy my POINT file in my image 
> group so that
> > i.rectify will be able to find it ?
> >
> > again, thank you very much for helping !
> >
> > Nicolas
> >
> >
> >
> >
> >
> >
> 
> 


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

Re: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text selectionbutton gives error

[Martin Landa]

Hi,

2008/3/4, Michael Barton <[EMAIL PROTECTED]>:
>  >> What do you mean by "text selection button": "legend text font",
>  >> "text
>  >> color", or something else?
>  >
>  > I meant the button labeled 'legend text font'. Sorry about that.
>  >
>  > ~ Eric.
>
>
> OK. It 'works for me' but I haven't tried the svn from today. I saw a
>  bunch of changes by Martin. Perhaps one of these broke something else.

I don't think so, I am not touching anything from TCL/TK-based GUI.

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] image rectification from command line only ?

[Michael Barton]

I don't know of any documentation for this. I guess just look at  
existing examples. Perhaps make a test case and rectify them in.  
That's what I did when working out the format for the GUI versions of  
this. You'll have to make a group and put the file into the group  
folder.


Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Mar 4, 2008, at 11:32 AM, Nicolas MERLET wrote:





-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael  
Barton

Sent: Tuesday, March 04, 2008 6:38 PM
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] image rectification from command line only ?



On Mar 4, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Tue, 4 Mar 2008 17:04:27 +0100
From: "Nicolas MERLET" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] image rectification from command line only ?
To: 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="us-ascii"


hi all,

i need to rectify an image automatically (i assume using

i.points and

i.rectify). as far as i've been able to see, i.points is to use in
graphical
monitor mode ? so does anyone know how to use it from the command
line (and
only from the command line) ?

thanks for helping...

nicolas


i.points lets a user interactively set ground control points (GCPs)
for an unrectified image, using a rectified image. This particular
process cannot be automated since it is interactive by definition.

However, if you already know the ground coordinates of a set of xy
points for an image, you can build a POINTS file and i.rectify will
georectify the image from the command line.

Michael



that would be enough as my GCP are pre-calculated. however i haven't  
found
any documentation about the POINTS files structure. where can i find  
it ? (i

just have http://grass.itc.it/gdp/html_grass63/i.rectify.html)

moreover, assuming we use i.rectify there's no paramater to give  
points, so

i suppose i just have to copy my POINT file in my image group so that
i.rectify will be able to find it ?

again, thank you very much for helping !

Nicolas








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

Re: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text selectionbutton gives error

[Michael Barton]

On Mar 4, 2008, at 11:01 AM, Patton, Eric wrote:


Eric,

What do you mean by "text selection button": "legend text font",  
"text

color", or something else?


I meant the button labeled 'legend text font'. Sorry about that.

~ Eric.


OK. It 'works for me' but I haven't tried the svn from today. I saw a  
bunch of changes by Martin. Perhaps one of these broke something else.


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

RE: [GRASS-dev] image rectification from command line only ?

[Nicolas MERLET]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael Barton
> Sent: Tuesday, March 04, 2008 6:38 PM
> To: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] image rectification from command line only ?
> 
> 
> 
> On Mar 4, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:
> 
> > Date: Tue, 4 Mar 2008 17:04:27 +0100
> > From: "Nicolas MERLET" <[EMAIL PROTECTED]>
> > Subject: [GRASS-dev] image rectification from command line only ?
> > To: 
> > Message-ID: <[EMAIL PROTECTED]>
> > Content-Type: text/plain;   charset="us-ascii"
> >
> >
> > hi all,
> >
> > i need to rectify an image automatically (i assume using 
> i.points and
> > i.rectify). as far as i've been able to see, i.points is to use in  
> > graphical
> > monitor mode ? so does anyone know how to use it from the command  
> > line (and
> > only from the command line) ?
> >
> > thanks for helping...
> >
> > nicolas
> 
> i.points lets a user interactively set ground control points (GCPs)  
> for an unrectified image, using a rectified image. This particular  
> process cannot be automated since it is interactive by definition.
> 
> However, if you already know the ground coordinates of a set of xy  
> points for an image, you can build a POINTS file and i.rectify will  
> georectify the image from the command line.
> 
> Michael
> 

that would be enough as my GCP are pre-calculated. however i haven't found
any documentation about the POINTS files structure. where can i find it ? (i
just have http://grass.itc.it/gdp/html_grass63/i.rectify.html)

moreover, assuming we use i.rectify there's no paramater to give points, so
i suppose i just have to copy my POINT file in my image group so that
i.rectify will be able to find it ?

again, thank you very much for helping !

Nicolas






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

RE: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text selectionbutton gives error

[Patton, Eric]

>Eric,
>
>What do you mean by "text selection button": "legend text font", "text  
>color", or something else?

I meant the button labeled 'legend text font'. Sorry about that.

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

Re: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text selection button gives error

[Michael Barton]

On Mar 4, 2008, at 10:21 AM, [EMAIL PROTECTED] wrote:


Date: Tue, 04 Mar 2008 17:08:29 -
From: "GRASS GIS" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text
selection button gives error
To: undisclosed-recipients:;
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"

#79: gis.m: Raster Legend text selection button gives error
- 
+--

Reporter:  epatton  |   Owner:  grass-dev@lists.osgeo.org
Type:  defect   |  Status:  new
Priority:  minor|   Milestone:  6.4.0
Component:  default  | Version:  svn-trunk
Keywords:  gis.m|
- 
+--

Using today's svn, I've noticed that the text selection button on the
Raster Legend in gis.m gives a tcl pop-up dialog with the attached  
error

log. FWIW, none of the other text selection tools in gis.m give this
error.

~ Eric.

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



Eric,

What do you mean by "text selection button": "legend text font", "text  
color", or something else?


Michael

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

Re: [GRASS-dev] image rectification from command line only ?

[Michael Barton]

On Mar 4, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:


Date: Tue, 4 Mar 2008 17:04:27 +0100
From: "Nicolas MERLET" <[EMAIL PROTECTED]>
Subject: [GRASS-dev] image rectification from command line only ?
To: 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="us-ascii"


hi all,

i need to rectify an image automatically (i assume using i.points and
i.rectify). as far as i've been able to see, i.points is to use in  
graphical
monitor mode ? so does anyone know how to use it from the command  
line (and

only from the command line) ?

thanks for helping...

nicolas


i.points lets a user interactively set ground control points (GCPs)  
for an unrectified image, using a rectified image. This particular  
process cannot be automated since it is interactive by definition.


However, if you already know the ground coordinates of a set of xy  
points for an image, you can build a POINTS file and i.rectify will  
georectify the image from the command line.


Michael

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

[GRASS-dev] Re: [GRASS GIS] #72: gis.m: boundary rendering is off by one pixel

[GRASS GIS]

#72: gis.m: boundary rendering is off by one pixel
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.3.0
 Component:  Tcl | Version:  svn-trunk
Resolution:  |Keywords:  gis.m, rendering 
-+--
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #45: NVIZ Nget_real_position somtimes after Nload_3dview returns wrong FROM_HEIGHT value

[GRASS GIS]

#45: NVIZ Nget_real_position somtimes after Nload_3dview returns wrong
FROM_HEIGHT value
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.4.0
 Component:  Tcl | Version:  svn-trunk
Resolution:  |Keywords:  nviz 
-+--
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #52: NVIZ fails to display all points in a point vector map

[GRASS GIS]

#52: NVIZ fails to display all points in a point vector map
--+-
  Reporter:  tvrusso  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Tcl  | Version:  unspecified  
Resolution:   |Keywords:  NVIZ, display, points
--+-
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #49: NVIZ displays points (sites) allways as thematic

[GRASS GIS]

#49: NVIZ displays points (sites) allways as thematic
---+
  Reporter:  marisn|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Tcl   | Version:  svn-trunk
Resolution:|Keywords:  nviz 
---+
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #47: NVIZ load 3D settings (3d.view) issues

[GRASS GIS]

#47: NVIZ load 3D settings (3d.view) issues
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.4.0
 Component:  Tcl | Version:  svn-trunk
Resolution:  |Keywords:  nviz 
-+--
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #79: gis.m: Raster Legend text selection button gives error

[GRASS GIS]

#79: gis.m: Raster Legend text selection button gives error
--+-
  Reporter:  epatton  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  minor|   Milestone:  6.4.0
 Component:  Tcl  | Version:  svn-trunk
Resolution:   |Keywords:  gis.m
--+-
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #31: NVIZ in GRASS6.2.3 (some problems)

[GRASS GIS]

#31: NVIZ  in GRASS6.2.3 (some problems)
--+-
  Reporter:  clerici  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Tcl  | Version:  6.2.3
Resolution:   |Keywords:  nviz 
--+-
Changes (by martinl):

  * component:  default => Tcl

-- 
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] #79: gis.m: Raster Legend text selection button gives error

[GRASS GIS]

#79: gis.m: Raster Legend text selection button gives error
-+--
 Reporter:  epatton  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  minor|   Milestone:  6.4.0
Component:  default  | Version:  svn-trunk
 Keywords:  gis.m|  
-+--
 Using today's svn, I've noticed that the text selection button on the
 Raster Legend in gis.m gives a tcl pop-up dialog with the attached error
 log. FWIW, none of the other text selection tools in gis.m give this
 error.

 ~ Eric.

-- 
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] GDAL 1.5.0 Build Error With GRASS Support

[marco.pasetti]

Hi,
 
I'm building GDAL 1.5.0 with GRASS support;
it gives the following error:
 
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: proj_api.h: No 
such file or directory
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO C++ 
forbids declaration of `projPJ' with no type
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: expected `;' 
before '*' token
make[2]: *** [../o/grass57dataset.o] Error 1
make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
make[1]: *** [grass-install-obj] Error 2
make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
make: *** [frmts-target] Error 2
 
proj_api.h is present in /usr/local/include, while 
/usr/local/grass-6.3.0RC5/include/grass has gproj_api.h
should I force GRASS code to include gproj_api.h instead of proj_api.h or walk 
around the problem adding /usr/local/include to PATH before launch make command?
 
Thanks
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GDAL 1.5.0 Build Error With GRASS Support

[marco.pasetti]

Hi,
 
I'm building GDAL 1.5.0 with GRASS support;
it gives the following error:
 
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:23:22: proj_api.h: No 
such file or directory
In file included from grass57dataset.cpp:45:
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: ISO C++ 
forbids declaration of `projPJ' with no type
C:/MSYS/local/grass-6.3.0RC5/include/grass/gprojects.h:36: error: expected `;' 
before '*' token
make[2]: *** [../o/grass57dataset.o] Error 1
make[2]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts/grass'
make[1]: *** [grass-install-obj] Error 2
make[1]: Leaving directory `/usr/local/src/gdal-1.5.0/frmts'
make: *** [frmts-target] Error 2
 
proj_api.h is present in /usr/local/include, while 
/usr/local/grass-6.3.0RC5/include/grass has gproj_api.h
should I force GRASS code to include gproj_api.h instead of proj_api.h or walk 
around the problem adding /usr/local/include to PATH before launch make command?
 
Thanks
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] image rectification from command line only ?

[Nicolas MERLET]

 
hi all,

i need to rectify an image automatically (i assume using i.points and
i.rectify). as far as i've been able to see, i.points is to use in graphical
monitor mode ? so does anyone know how to use it from the command line (and
only from the command line) ?

thanks for helping...

nicolas



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

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

[benjamin . ducke]

OK, compiling GDAL with Xerces-C and Expat works, with
some minor tweaks.


1. MinGW's Win32 API (3.11) collides with a function definition in
GDAL. Just move it out of the way:

Open ogr/ogrsf_frmts/ili/iom/iom_utilities.cpp and rename the _searchenv
() function so it does not collide with MinGW's own version. Change the
line (ca. 67):

static void _searchenv(const char *name, const char *envname, char *hitfile)

to:

static void _searchenv2(const char *name, const char *envname, char *hitfile)


2. As Marco suspected, libexpat.dll.a needs to be
present in /usr/lib (or wherever you keep your MinGW
libs), so not a good idea to delete it.
(still have to find my way out of the DLL hell ...)


Now I would like to work on the SWIG Python and Perl bindings
for GDAL. Does anyone have experience with those on MinGW?

Best,

Benjamin

[EMAIL PROTECTED] wrote:
> Hi Benjamin,
>
> I'm afraid that you're doing that work right now, and not a week before :-)
> because I just released a new MSYS GRASS environment, while it would be
> perfect to also add Xerces and Expat support to both GDAL and GRASS
> (only Xerces)
> it will be on the next time
>
> anyway I'm not sure about Expat; did you read this?
> http://trac.osgeo.org/gdal/wiki/BuildingWithMinGW
>
> the libexpat.dll.a is the import static library used while building the
> shared one; it is used (with the -lexpat.dll istruction) while building
> executables
> but I hope to fail and you're right ;-)
>
> Marco
>
> 
> *Da:* [EMAIL PROTECTED] per conto di
> [EMAIL PROTECTED]
> *Inviato:* mar 04/03/2008 14.41
> *A:* grass-dev@lists.osgeo.org
> *Oggetto:* Re: R: [GRASS-dev] WinGRASS: Xerces-C and Expat under MingW
>
> ... and on to Expat:
> that one is very simple to fix. After the "make install", just
> stay in the Expat source dir and do:
>
> rm /usr/lib/libexpat.dll.a
>
> install .libs/libexpat-1.dll /usr/lib/libexpat.dll
>
> (that's assuming you have Expat installed in /usr/lib,
> of course).
>
> I have not actually tried compiling the whole of GDAL with
> Xerces-C and Expat support yet, only got the configure
> script to run through.
>
> So there might be more trouble waiting ...
>
> 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

-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
[EMAIL PROTECTED]




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

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

[Martin Landa]

Hi,

2008/3/4, 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.
>
>  > It will most likely do since the messages are different now from
>  > the previous version.
>
>  Is any modification of an existing message going to break it's translations?

yes, when a message is already translated then translation is marked as fuzzy

>  > We should be really careful with the messages. Once someone has
>  > translated 5000 messages s/he will be "happy" to do it again just for the
>  > introduction of a period.
>
>  I changed much more in the messages than periods only. Will that be a
>  problem?

Changing messages is not forbidden;-)) Just bear in mind that it will
break translations, so the change should be reasonable and follow the
message standardization effort (should be better documented)

Regards, 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: m.distance / SWIG-Python interface + passingpointers with SWIG [was: d.measure w/ bearing]

[Michael Barton]

On Mar 4, 2008, at 4:50 AM, Patton, Eric wrote:


This means that for the specific issue at hand, i.e. d.measure with
bearing, I strongly plead for adding the possibility of giving  
start /
end coordinates as parameters to the module. This would then allow  
other

uses beyond the wxgrass gui such as web apps, shell scripts, etc.



As I have mentioned before, I am afraid that slowly but surely the
wxgrass gui will multiply functionality which is only available  
via the

gui, but should, in my eyes, also be available from the command line.
I'm thinking of things like profiling, measuring, etc.



Moritz


I agree; the ability to use and script modules on the command line  
is a
key feature that I rely on. GUI lock-in of certain features would  
really

be frustrating.

~ Eric.


This is why we should have a non-interactive version of d.measure.  
We've been slowly getting non-interactive versions of key command  
modules over the past couple years. A command that returns the  
distance between two xy coordiates would be useful. As I said  
earlier, modifying d.measure (or as Hamish has suggested, creating a  
new m.measure) would be desirable.


FWIW, there are already 2 non-interactive profiling commands that can  
be used in scripts that have existed for a long time, r.transect and  
r.profile. The GUI (both TclTk and wxPython) simply display the  
results of running r.profile. As far as I am concerned, this is the  
ideal model: a GRASS command that can be used in scripting, also used  
in a GUI script to produce an interactive display.


The issue is not that we are losing functionality to a GUI. It is the  
difference between a command that returns a new map (or other file,  
such as a graphic image) or returns information, and a command that  
has a hard-coded interactive interface built in. When GRASS was first  
developed, there weren't any widely used, easy ways to control an  
interactive interface. So a suite of commands were developed in which  
interfaces were hard-coded into the modules. Because this was done,  
we are still dealing with 20-year-old interface design and it's  
headaches (e.d., i.orthophoto). I agree with Glynn that we are better  
off in terms of current and future flexibility to use a dedicated GUI  
scripting platform that sits on top of GRASS to create the  
interactive user interface and handle interactive displays. This is  
much easier to update as the technology changes (e.g., moving from  
TclTk to wxPython).


This does not mean getting rid of GRASS commands. It simply means  
that we need to take the hard-coded interactive interfaces out of  
GRASS commands so that you can type them on the command line and they  
run without further intervention on the part of the user. In fact,  
this makes them much easier to script (e.g., you can't script  
i.orthophoto or i.points). Tightly coupling command line tools and an  
interactive interface in the same module limits both ways of  
manipulating GIS data. There are simply some things you can do in a  
good GUI that you can't do with commands and vice versa. You can't  
drag a box to zoom a display on the command line--but you can enter  
extents into g.region and have the same computational result. For  
profiling, r.profile returns detailed information on the elevations  
between a series of xy points. This information can be viewed and  
manipulated in a variety of ways. You could drop it into a  
spreadsheet or gnuplot and plot it, for example. The GUI provides a  
visually appealing, interactive way to access this information. That  
is what it supposed to do, but doing this does not decrease the  
functionality or value of the underlying command that produced the  
information.



Michael

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

[GRASS-dev] twekaing messages [was: r30420 - grass/trunk/scripts/v.db.renamecol]

[Maciej Sieczka]

Markus Neteler pisze:

On Mon, Mar 3, 2008 at 5:29 PM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:

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.



It will most likely do since the messages are different now from
the previous version.


Is any modification of an existing message going to break it's translations?


We should be really careful with the messages. Once someone has
translated 5000 messages s/he will be "happy" to do it again just for the
introduction of a period.


I changed much more in the messages than periods only. Will that be a 
problem?



 OK. I'm deleting them. Though a sentence with no period is crippled.



Well, it's not literature...


Indeed it's not.

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

Re: [GRASS-dev] winGRASS-6.3.0RC5

[Martin Landa]

Hi,

2008/3/4, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Then a little OT (to not open a new thread): I'm willing to post a thread on
> Gfoss and GRASS Italia (friend italian lists) to announce my new GRASS
> building guide. Does someone "better graduate" than me want to do the job
> first on GRASS official lists, thus I can forward later to friend lists?

BTW I have created in Trac the page

http://trac.osgeo.org/grass/wiki/BuildingOnWindows

(feel free to improve)

linked from

http://trac.osgeo.org/grass/wiki/BuildHints

Martin

PS: BTW sorry for being rude;-) Are you planning to transfer your
guide to GRASS Wiki or Trac, it would simplify updating this text in
the future.

-- 
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-6.3.0RC5

[marco.pasetti]

Hi,
 
I tried to use the same subject of the last week, to keep continuity to the 
thread, even if my web-based mail client starts a new thread for each mail I 
send (sorry!)
I rebuilt GRASS hacking ..man/Makefile and using Tcl-Tk 8.5.1 (built from 
source), and now the errors with menu commands "GRASS Help" and "GIS Manager 
Help" disappeared! I don't kow why... but it's good, don't you agree? ;-)))
 
Then a little OT (to not open a new thread): I'm willing to post a thread on 
Gfoss and GRASS Italia (friend italian lists) to announce my new GRASS building 
guide. Does someone "better graduate" than me want to do the job first on GRASS 
official lists, thus I can forward later to friend lists?
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] i.topo.corr

[ejtizado]

Hi all,

I send today a grass-addon i.topo.corr to make topographic corrections 
(cosine, minnaert, c-correction) of reflectance files. I like known your 
comments and possible bugs or improvements.

Thanks

Jorge
___
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]

Some functions, primarily from Gm.tcl, were moved into a gmlib.tcl

It's probably simply a replacement of gmlib::[proc] with gm::[proc].

I'll have to look into it. Today is pretty busy. Maybe tonight or  
tomorrow.


Michael

On Mar 3, 2008, at 10:52 PM, Hamish wrote:


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] WinGRASS RC5 man/man1/d.ask.1 Error 127

[Moritz Lennert]

On 04/03/08 15:07, [EMAIL PROTECTED] wrote:

Hi,
 
I modified ../man/Makefile at line 13 replacing


|default: $(MANPAGES)|

with

|default:|

then I rebuilt GRASS, and man/man1/d.ask.1 Error 127 disappeared... 
along with ../man/man1 directory!

Anyway I don't care that, because in previous built it was always empty!


I don't think that man pages are of any use in Windows...

Moritz

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

Re: [GRASS-dev] WinGRASS Building Guide

[Markus Neteler]

On Mon, Mar 3, 2008 at 5:31 PM,  <[EMAIL PROTECTED]> wrote:
> 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?

Excellent! I have linked it into the GRASS wiki.

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

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

[benjamin . ducke]

[EMAIL PROTECTED] wrote:
> Hi Benjamin,
>
> I'm afraid that you're doing that work right now, and not a week before :-)
> because I just released a new MSYS GRASS environment, while it would be
> perfect to also add Xerces and Expat support to both GDAL and GRASS
> (only Xerces)
> it will be on the next time

That's OK, there are plenty more things that need further work, anyway.

>
> anyway I'm not sure about Expat; did you read this?
> http://trac.osgeo.org/gdal/wiki/BuildingWithMinGW
>
> the libexpat.dll.a is the import static library used while building the
> shared one; it is used (with the -lexpat.dll istruction) while building
> executables
> but I hope to fail and you're right ;-)

Welcome to Windows' "DLL hell". You would not believe the mess that
shared libraries are under Win32. Apparently, symbols to be used at
linking tine can be included in the actual DLL or an external library
file, the format of which depends on the C compiler. So you have .dll,
.dll.a, .lib, .a, .la, .lai files floating around ...

As far as I can see, in the case of Expat, all necessary symbols
are in expat-1.dll. At least the little test program I compiled worked
alright with it.

If anything comes up, I will report it to the list.

Best,

Benjamin

>
> Marco
>
> 
> *Da:* [EMAIL PROTECTED] per conto di
> [EMAIL PROTECTED]
> *Inviato:* mar 04/03/2008 14.41
> *A:* grass-dev@lists.osgeo.org
> *Oggetto:* Re: R: [GRASS-dev] WinGRASS: Xerces-C and Expat under MingW
>
> ... and on to Expat:
> that one is very simple to fix. After the "make install", just
> stay in the Expat source dir and do:
>
> rm /usr/lib/libexpat.dll.a
>
> install .libs/libexpat-1.dll /usr/lib/libexpat.dll
>
> (that's assuming you have Expat installed in /usr/lib,
> of course).
>
> I have not actually tried compiling the whole of GDAL with
> Xerces-C and Expat support yet, only got the configure
> script to run through.
>
> So there might be more trouble waiting ...
>
> 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

-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
[EMAIL PROTECTED]




___
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

[marco.pasetti]

Hi,
 
I modified ../man/Makefile at line 13 replacing
default: $(MANPAGES)
with
default:
then I rebuilt GRASS, and man/man1/d.ask.1 Error 127 disappeared... along with 
../man/man1 directory!
Anyway I don't care that, because in previous built it was always empty!
 
Aa a consequence, I decided to add this Makefile hacking to the building guide, 
now updated.
 
Marco
 
 


Da: [EMAIL PROTECTED] per conto di Marco Pasetti
Inviato: mar 04/03/2008 0.55
A: GRASS Developer Mailing List
Oggetto: [GRASS-dev] WinGRASS RC5 man/man1/d.ask.1 Error 127



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


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

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

[marco.pasetti]

Hi Benjamin,
 
I'm afraid that you're doing that work right now, and not a week before :-)
because I just released a new MSYS GRASS environment, while it would be perfect 
to also add Xerces and Expat support to both GDAL and GRASS (only Xerces)
it will be on the next time
 
anyway I'm not sure about Expat; did you read this? 
http://trac.osgeo.org/gdal/wiki/BuildingWithMinGW
 
the libexpat.dll.a is the import static library used while building the shared 
one; it is used (with the -lexpat.dll istruction) while building executables
but I hope to fail and you're right ;-)
 
Marco



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



... and on to Expat:
that one is very simple to fix. After the "make install", just
stay in the Expat source dir and do:

rm /usr/lib/libexpat.dll.a

install .libs/libexpat-1.dll /usr/lib/libexpat.dll

(that's assuming you have Expat installed in /usr/lib,
of course).

I have not actually tried compiling the whole of GDAL with
Xerces-C and Expat support yet, only got the configure
script to run through.

So there might be more trouble waiting ...

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: R: [GRASS-dev] WinGRASS: Xerces-C and Expat under MingW

[benjamin . ducke]

... and on to Expat:
that one is very simple to fix. After the "make install", just
stay in the Expat source dir and do:

rm /usr/lib/libexpat.dll.a

install .libs/libexpat-1.dll /usr/lib/libexpat.dll

(that's assuming you have Expat installed in /usr/lib,
of course).

I have not actually tried compiling the whole of GDAL with
Xerces-C and Expat support yet, only got the configure
script to run through.

So there might be more trouble waiting ...

Best,

Benjamin


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

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

[benjamin . ducke]

One more thing re. GDAL:

For Xerces-C support: the GDAL configure script will attempt to compile a
little test program. There is a definition for LDFLAGS (ca. line 23509),
which may include -lpthread (no matter whether it's actually installed on
your system or not):

LDFLAGS="$LDFLAGS $xerces_lib_flags -lpthread"

If you don't have the pthread library installed, delete the corresponding
item from the definition above.

Benjamin


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

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

[benjamin . ducke]

I figured out how to create valid Xerces-C DLLs on MinGW.

(note: I am keeping my source code in /src, where I also download
the tgz file from the Xerces project page):

***

export XERCESCROOT=/src/xerces-c-src_2_8_0

cd /src

tar -xzf xerces-c-src_2_8_0.tar.gz

cd xerces-c-src_2_8_0/src/xercesc

./runConfigure -p mingw-msys -c gcc -x g++ -n fileonly -r none -z
-mno-cygwin -C --host=i686-mingw32

Before we can run make, we need to fix some of the Makefiles a little bit
(we need to add an extra colon in some places).

In file C:\msys\1.0\src\xerces-c-src_2_8_0\src\xercesc\Makefile.incl, near
the top, change

ALL: all

to

ALL:: all

In file
C:\msys\1.0\src\xerces-c-src_2_8_0\src\xercesc\util\Makefile.util.submodule,
near the top, change

all: includes $(CPP_OBJECTS)

to

all:: includes $(CPP_OBJECTS)

In file C:\msys\1.0\src\xerces-c-src_2_8_0\obj\Makefile you will find the
following definition at line 104:

all: ${FQ_REAL_NAME} ${FQ_REAL_DEPDOM}

Change it to read:

all:: ${FQ_REAL_NAME} ${FQ_REAL_DEPDOM}

Now the source code can be compiled (There will be many warnings. You can
safely ignore them):

make

make install

This will create the Windows DLLs and copy them and all header files into
/usr/local.

***

This was done using MinGW 5.1.3, MSYS 1.0.11 (latest) and
GNU Make 3.81 with the MinGW Win32API version 3.11.

Best,

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
>
>

-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
[EMAIL PROTECTED]




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

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

[Patton, Eric]

>This means that for the specific issue at hand, i.e. d.measure with 
>bearing, I strongly plead for adding the possibility of giving start / 
>end coordinates as parameters to the module. This would then allow other 
>uses beyond the wxgrass gui such as web apps, shell scripts, etc.

>As I have mentioned before, I am afraid that slowly but surely the 
>wxgrass gui will multiply functionality which is only available via the 
>gui, but should, in my eyes, also be available from the command line. 
>I'm thinking of things like profiling, measuring, etc.

>Moritz

I agree; the ability to use and script modules on the command line is a
key feature that I rely on. GUI lock-in of certain features would really
be frustrating.

~ Eric.



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

[GRASS-dev] Re: document what number is NULL

[Markus Neteler]

On Tue, Feb 26, 2008 at 5:25 PM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
> Glynn Clements pisze:
>
>  > -2^31 (= 0x8000 = -2147483648) is the null value
>  > for the CELL type, so you'll never see that value in a map.
>
>  > The FP nulls are the all-ones bit patterns. These corresponds to NaN
>  > according to the IEEE-754 formats, although it isn't the "default" NaN
>  > pattern generated by most architectures (which is usually 7fc0 or
>  > ffc0 for float and 7ff8 or fff8 for
>  > double, i.e. an all-ones exponent, the top-bit of the mantissa set,
>  > and either sign).
>  >
>  > So far as arithmetic is concerned, any value with an all-ones exponent
>  > and a non-zero mantissa is treated as NaN. But the GRASS
>  > G_is_[fd]_null_value() functions only consider the all-ones bit
>  > pattern to be null. I intend to change this in 7.x so that all FP NaN
>  > values are treated as null. This will mean that code which can
>  > generate NaNs doesn't have to explicitly convert them to the GRASS
>  > null value.
>
>  These should go to "Raster data processing in GRASS GIS". As I don't
>  really understand the part about floating point, I won't do it myself.
>  Somebody more savvy please do, putting it some simpler words if possible.

Added like this as
http://trac.osgeo.org/grass/changeset/30458

Feel free to improve...

Markus
___
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 5:29 PM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
> 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.

It will most likely do since the messages are different now from
the previous version.
We should be really careful with the messages. Once someone has
translated 5000 messages s/he will be "happy" to do it again just for the
introduction of a period.


>  > 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.

Well, it's not literature...

>  Reader might suppose the message is incomplete or broken. Could this be
>  changed in GRASS 7?

I don't think so - too much wasted effort.

>  > 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.

See here how it works:
http://trac.osgeo.org/grass/browser/grass/trunk/locale/README

It's fairly easy.

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

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

[Moritz Lennert]

On 04/03/08 00:40, Hamish wrote:



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.




[...]



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.



I'm not sure I fully agree with the above (and I think Dylan's right in 
saying that we might need a more explicit discussion of the issue). 
Besides issues concerning state which Glynn has mentioned often on this 
list (but obviously I cannot find a reference now) and which might make 
the direct use of GRASS function by the GUI a bit hazardous, there is a 
fundamental choice to be made between only using modules or programming 
directly with GRASS functions.


In my eyes the general rule should be that all functionality should be 
available via modules from the command line if in any way possible. The 
GUI should only provide additional help in things like determining 
coordinates through mouse click and some (very limited) gui-specific issues.


This means that for the specific issue at hand, i.e. d.measure with 
bearing, I strongly plead for adding the possibility of giving start / 
end coordinates as parameters to the module. This would then allow other 
uses beyond the wxgrass gui such as web apps, shell scripts, etc.


As I have mentioned before, I am afraid that slowly but surely the 
wxgrass gui will multiply functionality which is only available via the 
gui, but should, in my eyes, also be available from the command line. 
I'm thinking of things like profiling, measuring, etc.


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