Re: R: [GRASS-dev] GRASS 6.3.0 to be released

[Moritz Lennert]

On 15/04/08 22:39, Marco Pasetti wrote:

Hi all,

It would be good also for me, even if it would better if we release it on
next week tough (I'm very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer...

Martin, do you think that we could add the needed python files into the
6.3.0 windows package, in order to let users start the pyGUI without the
need to install python stuffs by themselves?


-1

I don't think we should bloat the installer with everything that people 
might need. It really is not difficult to download and install the 
python installers...


The only thing we could consider is to add an option to automatically 
download and install the python stuff, but not add it to our installer 
directly.


Just my two cents...

Moritz



Regards

Marco

-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per conto di Martin Landa
Inviato: martedì 15 aprile 2008 19.04
A: Markus Neteler
Cc: GRASS developers list
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released

2008/4/15, Markus Neteler <[EMAIL PROTECTED]>:
 After 6 release candidates, even tested on MS-Windows,  I don't see 
any real blockers any more. I suggest to get out  6.3.0 this week and 
proceed with change to 6.4.release_branch/7.0.svn.


 We can have 6.3.1 if needed.

 Sounds ok?


+1

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 mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev



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

[GRASS-dev] Re: [GRASS GIS] #110: db/drivers/dbf fail to build due to undefined reference to 'SASetupDefaultHooks' (SHAPELIB)

[GRASS GIS]

#110: db/drivers/dbf fail to build due to undefined reference to
'SASetupDefaultHooks' (SHAPELIB)
---+
  Reporter:  marisn|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  6.4.0
 Component:  default   | Version:  svn-trunk
Resolution:  fixed |Keywords:  dbf  
---+
Changes (by marisn):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Seems to be fixed for now.
 Tested on 32bit Gentoo with GDAL-1.5.0 and GRASS trunk rev. 31009

-- 
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] GRASS 6.3.0 to be released

[Paul Kelly]

On Tue, 15 Apr 2008, Markus Neteler wrote:


(to continue on this thread)

After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.


Yes go for it I say; 6.3.0 is not a stable release and everything does 
not have to be perfect, but may I suggest that the new branch for 
continued 6.x development be called develbranch_6 and that a 6.4 release 
branch be created off there at a future date?


As some parts of GRASS will likely cease to exist in the 7.x HEAD I think 
it is likely that there will still be some opportunity for development and 
improvement of backward-compatible things in 6.x for some time to come. 
E.g. should I end up mentoring a Google Summer of Code student I will 
certainly recommend that he work in 6.x to avoid extra disruption caused 
by the 7.x upheaval - and changes can be forward-ported to 7.x later.


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

[GRASS-dev] Re: [GRASS GIS] #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]

[GRASS GIS]

#50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
--+-
  Reporter:  steko|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  6.3.0 RCs
Resolution:  fixed|Keywords:  g.copy   
--+-
Changes (by marisn):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Seems to be fixed - g.copy doesn't fail anymore. Tested with GRASS trunk
 rev. 31009 on 32bit Gentoo.

-- 
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: R: [GRASS-dev] GRASS 6.3.0 to be released

[Glynn Clements]

Moritz Lennert wrote:

> > It would be good also for me, even if it would better if we release it on
> > next week tough (I'm very busy now). BTW, there are few thing to do for me,
> > just some improvements for windows installer...
> > 
> > Martin, do you think that we could add the needed python files into the
> > 6.3.0 windows package, in order to let users start the pyGUI without the
> > need to install python stuffs by themselves?
> 
> -1
> 
> I don't think we should bloat the installer with everything that people 
> might need. It really is not difficult to download and install the 
> python installers...

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.

An ideal solution would be to use Cygwin's Setup utility, but I don't
know how much work would be involved.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

R: R: [GRASS-dev] GRASS 6.3.0 to be released

[marco.pasetti]

Hi Moritz,
 
>It really is not difficult to download and install the
python installers...
 
yes, I agree but: when I think to softwares packaging I always keep in my 
mind all the experiences *collected* during the years with many users, 
specially here at my university... specially among teachers and researchers. 
It's a consolidated fact, here in my country, that not electronic engineers, 
specially civil and environmental ones, have a *bad relationships* with 
calculators and softwares in general (except with CAD softwares, supposed that 
they are easy to install...). Since the main target of GIS software is, I 
guess, exactly this category of professionals (along with geologists)[1], I 
believe that they would have difficulties, specially on Windows (where users 
are used to install only self-contained, full-featured packages), to 
*understand* exactly what to do; there's the possibility (note, this is only a 
personal point of view, but based on direct experience with windows users) that 
they would not consider to use GRASS because it's too difficult to install, 
thus moving to not-opened GIS platforms.
 
>The only thing we could consider is to add an option to automatically
download and install the python stuff, but not add it to our installer
directly.

this would be a very good solution, but I still need to understand how to do 
that in a *clean* and tidy manner, 100% working on both XP and Vista (OT: on 
xext week I'll probably buy a new PC, with Vista installed, so I'll can test 
also on Vista).
 
Marco
 
[1] you could not believe that, but here at my university teachers don't 
know/use GIS softwares... this said, it's a main target of my future plans, 
after the degree on July, to *spread* the opend GIS (that is GRASS) *word* here 
;-)

 
 



Da: Moritz Lennert [mailto:[EMAIL PROTECTED]
Inviato: mer 16/04/2008 9.29
A: [EMAIL PROTECTED]
Cc: 'Martin Landa'; 'Markus Neteler'; 'GRASS developers list'
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released



On 15/04/08 22:39, Marco Pasetti wrote:
> Hi all,
>
> It would be good also for me, even if it would better if we release it on
> next week tough (I'm very busy now). BTW, there are few thing to do for me,
> just some improvements for windows installer...
>
> Martin, do you think that we could add the needed python files into the
> 6.3.0 windows package, in order to let users start the pyGUI without the
> need to install python stuffs by themselves?

-1

I don't think we should bloat the installer with everything that people
might need. It really is not difficult to download and install the
python installers...

The only thing we could consider is to add an option to automatically
download and install the python stuff, but not add it to our installer
directly.

Just my two cents...

Moritz

>
> Regards
>
> Marco
>
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di Martin Landa
> Inviato: martedì 15 aprile 2008 19.04
> A: Markus Neteler
> Cc: GRASS developers list
> Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released
>
> 2008/4/15, Markus Neteler <[EMAIL PROTECTED]>:
>>  After 6 release candidates, even tested on MS-Windows,  I don't see
>> any real blockers any more. I suggest to get out  6.3.0 this week and
>> proceed with change to 6.4.release_branch/7.0.svn.
>>
>>  We can have 6.3.1 if needed.
>>
>>  Sounds ok?
>
> +1
>
> 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 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: R: [GRASS-dev] GRASS 6.3.0 to be released

[marco.pasetti]

Glynn,
 
>I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.

we could do as follows:
 
1. a *complete*, *first time* GRASS installer, based on latest release, with 
all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check the 
WinGRASS repository looking for last GRASS updates, and download/install only 
the latest updated files (both for GRASS and dependencies). It would be not an 
easy work, but I think that I'll can do it... even if not very soon :-)
 
Marco
 



Da: Glynn Clements [mailto:[EMAIL PROTECTED]
Inviato: mer 16/04/2008 10.20
A: Moritz Lennert
Cc: [EMAIL PROTECTED]; 'Martin Landa'; 'GRASS developers list'
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released




Moritz Lennert wrote:

> > It would be good also for me, even if it would better if we release it on
> > next week tough (I'm very busy now). BTW, there are few thing to do for me,
> > just some improvements for windows installer...
> >
> > Martin, do you think that we could add the needed python files into the
> > 6.3.0 windows package, in order to let users start the pyGUI without the
> > need to install python stuffs by themselves?
>
> -1
>
> I don't think we should bloat the installer with everything that people
> might need. It really is not difficult to download and install the
> python installers...

I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.

An ideal solution would be to use Cygwin's Setup utility, but I don't
know how much work would be involved.

--
Glynn Clements <[EMAIL PROTECTED]>


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

Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Martin Landa]

Marco,

2008/4/16, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > Martin, do you think that we could add the needed python files into the
> > 6.3.0 windows package, in order to let users start the pyGUI without the
> > need to install python stuffs by themselves?
>
> -1
>
> I don't think we should bloat the installer with everything that people
> might need. It really is not difficult to download and install the
> python installers...
>
> The only thing we could consider is to add an option to automatically
> download and install the python stuff, but not add it to our installer
> directly.

I agree here with Moritz. Python/wxPython installation process on
Windows seems to me to be quite simple. I would not expect that the
user how is not able to install e.g. Python will be able to use GRASS
at the end;-)

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] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

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

 Hi, I've just added a new xmag screenshot showing that it is the area fill
 which is displaced, not the boundary line. (or both the boundary line and
 symbols travel together)

 {{{
 #spearfish
 v.out.ascii fields format=standard | sed -e '1,10d' | \
grep -v '^C\|^B' | grep -v '^ 1 ' > field_corners.dat


 v.in.ascii field_corners.dat fs=space x=1 y=2 out=field_corners

 # then display them both in gis.m
 }}}


 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] GRASS 6.3.0 to be released

[Martin Landa]

Hi,

2008/4/16, Paul Kelly <[EMAIL PROTECTED]>:
>  Yes go for it I say; 6.3.0 is not a stable release and everything does not
> have to be perfect, but may I suggest that the new branch for continued 6.x
> development be called develbranch_6 and that a 6.4 release branch be created
> off there at a future date?

+1

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] GRASS 6.3.0 to be released

[Glynn Clements]

Hamish wrote:

> > After 6 release candidates, even tested on MS-Windows,
> > I don't see any real blockers any more. I suggest to get out
> > 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
> > 
> > We can have 6.3.1 if needed.
> > 
> > Sounds ok?
> 
> to me, trac bug #72 is a blocker (PNG driver rendering offset)
>   http://trac.osgeo.org/grass/ticket/72

That issue has always been there, and isn't easily fixed.

Lines are drawn along the "nearest" axis. E.g. for a line which is
closer to the horizontal than to the vertical, the loop iterates over
the X coordinates, with the Y coordinate determined using Bressenham's
algorithm. The slope is always less than or equal to one, so at each
step the Y coordinate either remains unchanged or increments by one,
according to a test which only uses integer arithmetic.

Polygons are drawn from top to bottom as a single entity (as opposed
to the outline, which is a sequence of individual line segments). For
each row, the X coordinates of the left and right edges are calculated
using floating-point coordinates, then rounded to the nearest integer. 
A horizontal line (actually, a one-pixel-high rectangle) is drawn
between the two edge points.

It wouldn't be particularly hard to make the closer-to-vertical case
match, by using the same algorithm in both cases. Making the
closer-to-horizontal case match is harder (and messy).

But ultimately, this is just one aspect of a more fundamental problem:
integer coordinates and odd line widths simply don't mix. You cannot
get this case "right"; you just have to choose which flavour of
"wrong" you prefer.

[X11 largely ducked the issue by stating that single-pixel lines are
implementation dependent. Apart from shielding the X developers from
flak from users who would have preferred a different flavour of
"wrong" (even to the point of insisting that a particular flavour is
actually "the right one"), it allows the use of any line-drawing
functionality which is provided by the video hardware, regardless of
which flavour the hardware uses.]

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #111: r.los error "r.los.exe there are encountered to problem and needs to close"

[GRASS GIS]

#111: r.los error "r.los.exe there are encountered to problem and needs to 
close"
--+-
  Reporter:  gsancho  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  unspecified  
Resolution:   |Keywords:  wingrass r.los   
--+-
Changes (by 4everskiff):

 * cc: [EMAIL PROTECTED] (added)

Comment:

 Replying to [ticket:111 gsancho]:
 > Hello.
 >
 > I have a problem with the operation r.los in winGrass(native). I have
 been testing different maps and when a distance is greater than 80-100
 pixels (map pixels) a system error is thrown.
 >
 > To put an example, in spearfish data base and the elevation.dem map,
 grass fails from 2524m on up  (with the height of the observer set to 1m)
 >
 > The command would be:
 > r.los input=elevation.dem output=los coordinate=599505,4921010
 max_dis=2525
 >
 > The error that is reported is a system error: "r.los.exe there are
 encountered to problem and needs to close"
 >
 > Thanks and regards.

 Hi,

 I checked the command on WinGRASS-6.3.0RC6 (WinXP). It's the same for me.
 BTW, the error seems to be not related to WinGRASS, but to the map in use
 or to the module as cross-platform error (maybe related to the dimension
 of data to be processed?). For example, I launched the command on another
 raster dem map (with a resolution of 20m) with dist set to 3000, and it
 works fine, while it fails with 3001!
 Could someone test it also on linux or mac?

 Thank you

 Marco

-- 
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] #111: r.los error "r.los.exe there are encountered to problem and needs to close"

[GRASS GIS]

#111: r.los error "r.los.exe there are encountered to problem and needs to 
close"
--+-
  Reporter:  gsancho  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  unspecified  
Resolution:   |Keywords:  wingrass r.los   
--+-
Comment (by mlennert):

 I cannot confirm this on Debian GNU/Linux with recent svn, so it seems to
 be win-specific.

 Moritz

-- 
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] GRASS 6.3.0 to be released

[Markus Neteler]

On Wed, Apr 16, 2008 at 6:28 AM, Hamish <[EMAIL PROTECTED]> wrote:
> Markus Neteler wrote:
>  > (to continue on this thread)
>  >
>  > After 6 release candidates, even tested on MS-Windows,
>  > I don't see any real blockers any more. I suggest to get out
>  > 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
>  >
>  > We can have 6.3.1 if needed.
>  >
>  > Sounds ok?
>
>  to me, trac bug #72 is a blocker (PNG driver rendering offset)
>   http://trac.osgeo.org/grass/ticket/72
>
>  even spearfish fields map looks bad (vertical slivers) when displayed in
>  the GUI.

given the answer by Glynn:
  http://lists.osgeo.org/pipermail/grass-dev/2008-April/037267.html
do you want to keep your veto?

I fear that we never go ahead like this.


>  As promised, I will work on rewriting the release announcement in the
>  next day or two.
>
>
>  other lower priority things todo:
>
>  
> http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.3.0

OK, low priority, so we can do it in 6.3.1. It's a *technology preview*, nothing
else what we want to publish now. Bugfree software of this size does not exist.

>   http://grass.osgeo.org/wiki/GRASS_6.3_Feature_Plan#6.3.0_final

Can you revise your opinion?

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

Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Moritz Lennert]

On 16/04/08 10:41, [EMAIL PROTECTED] wrote:

Glynn,
 
 >I would suggest two installers: one for GRASS alone, and one for the

various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:
 
1. a *complete*, *first time* GRASS installer, based on latest release, 
with all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check 
the WinGRASS repository looking for last GRASS updates, and 
download/install only the latest updated files (both for GRASS and 
dependencies). It would be not an easy work, but I think that I'll can 
do it... even if not very soon :-)


This actually sounds much more sophisticated than what Glynn proposed. 
Could you not simply propose one installer with only the latest 
(complete) GRASS binaries. This installer could check for any existing 
installation of GRASS and propose to erase that before installing the 
new version, or install the new version next to the old.


The question then is: do we need a "complete" installer with everything 
in it (as you suggest), or can we impose the burden of two installers on 
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies 
installer. I think this would be the best solution for us, but it would 
mean that at least for the first installation, users will have to 
install two packages. If the GRASS installer could test for the 
installation of the other package and propose to download it and lauch 
its installation autmagically, then this might be the best solution.


But you're the one doing the work, so the ultimate decision will be 
yours ;-)


Moritz

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

[GRASS-dev] Re: [GRASS GIS] #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]

[GRASS GIS]

#50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
--+-
  Reporter:  steko|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  6.3.0 RCs
Resolution:  fixed|Keywords:  g.copy   
--+-
Comment (by neteler):

 Should this be backported to 6.3.0 release branch?

 Markus

-- 
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] #124: d.legend: apply arbitrary labels to a smooth floating-point colorbar

[GRASS GIS]

#124: d.legend: apply arbitrary labels to a smooth floating-point colorbar
--+-
  Reporter:  epatton  |   Owner:  hamish
  Type:  enhancement  |  Status:  assigned  
  Priority:  minor|   Milestone:  6.4.0 
 Component:  default  | Version:  svn-trunk 
Resolution:   |Keywords:  colorbar, d.legend
--+-
Comment (by epatton):

 Ok, for instance, see legend1.png; it shows a color bar divided into 6
 intervals on a floating-point bathymetry dataset; I don't want to use odd
 depth values like -188 and -92; I would prefer to label -200, -150, -100,
 etc. When I use the use= paramter, the legend gets chopped into squares,
 ruining the nice, continous color bar (legend2.png; also, the labels
 become huge for some reason).

 So basically, I would ideally like a color bar like legend1.png, but with
 arbitrary labels applied.

-- 
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: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Benjamin Ducke]

I would vote for a lean base installer to be distributed on
grass.itc.it. Other projects can build fatter installers based
on that and distribute them. A bare bones installer will be
much easier to maintain for us in the long run.

Benjamin

Moritz Lennert wrote:

On 16/04/08 10:41, [EMAIL PROTECTED] wrote:

Glynn,
 
 >I would suggest two installers: one for GRASS alone, and one for the

various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:
 
1. a *complete*, *first time* GRASS installer, based on latest 
release, with all the dependencies built-in
2. and *updater*, installed along the *first installation*, that check 
the WinGRASS repository looking for last GRASS updates, and 
download/install only the latest updated files (both for GRASS and 
dependencies). It would be not an easy work, but I think that I'll can 
do it... even if not very soon :-)


This actually sounds much more sophisticated than what Glynn proposed. 
Could you not simply propose one installer with only the latest 
(complete) GRASS binaries. This installer could check for any existing 
installation of GRASS and propose to erase that before installing the 
new version, or install the new version next to the old.


The question then is: do we need a "complete" installer with everything 
in it (as you suggest), or can we impose the burden of two installers on 
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies 
installer. I think this would be the best solution for us, but it would 
mean that at least for the first installation, users will have to 
install two packages. If the GRASS installer could test for the 
installation of the other package and propose to download it and lauch 
its installation autmagically, then this might be the best solution.


But you're the one doing the work, so the ultimate decision will be 
yours ;-)


Moritz

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




--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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

[GRASS-dev] Re: [GRASS GIS] #97: r.random fails with bus error on Mac OS X 10.5

[GRASS GIS]

#97: r.random fails with bus error on Mac OS X 10.5
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.3.0
 Component:  default   | Version:  unspecified  
Resolution:|Keywords:  r.random Mac 
---+
Comment (by kyngchaos):

 Just tested on current SVN and no crash.  Michael?

-- 
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] G_OPT_R_OUTPUT base or output?

[Roger Bivand]

On two very similar systems built today from the RC6 tarball (i686 RHEL5, 
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the 
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?


r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a 
different entry in the enum definition. I find this puzzling ...


Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]

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

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Dylan Beaudette]

On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> On two very similar systems built today from the RC6 tarball (i686 RHEL5,
> F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> traditional "output" on RHEL5. The tarballs have the same md5sums. Why?
>
>  r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
>
>  lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a
> different entry in the enum definition. I find this puzzling ...
>
>  Roger

Hi Roger,

Did you do a:

make distclean

before compiling the source?

Cheers,

Dylan


>
>  --
>  Roger Bivand
>  Economic Geography Section, Department of Economics, Norwegian School of
>  Economics and Business Administration, Helleveien 30, N-5045 Bergen,
>  Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
>  e-mail: [EMAIL PROTECTED]
>
>  ___
>  grass-dev mailing list
>  grass-dev@lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Roger Bivand]

On Wed, 16 Apr 2008, Dylan Beaudette wrote:


On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:

On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

 r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

 lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is a
different entry in the enum definition. I find this puzzling ...

 Roger


Hi Roger,

Did you do a:

make distclean

before compiling the source?


Hi,

I used the tarball, and untarred to a fresh directory. Should I still have 
said make distclean? I'll try - but why the different behaviour? The 
windows native binary is "output".


Best wishes,

Roger



Cheers,

Dylan




 --
 Roger Bivand
 Economic Geography Section, Department of Economics, Norwegian School of
 Economics and Business Administration, Helleveien 30, N-5045 Bergen,
 Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
 e-mail: [EMAIL PROTECTED]

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





--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]

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

Re: [GRASS-dev] GRASS 6.3.0 to be released

[Michael Barton]

On my way out of town. I have 3 quick comments

1) How the binary installers are packaged should not affect the 6.3.0
release. IMHO, go for it.

2) A separate dependency installer is an excellent idea for Windows. That is
what has been done on the Mac for years and is very successful.

3) Currently, while the wxPython GUI is in development, I think that is is
quite OK to require testers to install Python (and maybe wxPython),
especially since this is quite easy. Ultimately, I would hope that compiling
GRASS would also run Python distutilities (or something like that) to
provide a portable binary GUI that *doesn't* require installing Python or
anything else.

Michael 


On 4/16/08 1:50 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> Date: Wed, 16 Apr 2008 10:47:15 +0200
> From: "Martin Landa" <[EMAIL PROTECTED]>
> Subject: Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Cc: GRASS developers list 
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Marco,
> 
> 2008/4/16, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>>> Martin, do you think that we could add the needed python files into the
>>> 6.3.0 windows package, in order to let users start the pyGUI without the
>>> need to install python stuffs by themselves?
>> 
>> -1
>> 
>> I don't think we should bloat the installer with everything that people
>> might need. It really is not difficult to download and install the
>> python installers...
>> 
>> The only thing we could consider is to add an option to automatically
>> download and install the python stuff, but not add it to our installer
>> directly.
> 
> I agree here with Moritz. Python/wxPython installation process on
> Windows seems to me to be quite simple. I would not expect that the
> user how is not able to install e.g. Python will be able to use GRASS
> at the end;-)
> 
> Martin

__
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-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

[GRASS-dev] Re: [GRASS GIS] #97: r.random fails with bus error on Mac OS X 10.5

[Michael Barton]

I can't test on 10.5 until I get back in town next week.

Michael


On 4/16/08 7:14 AM, "GRASS GIS" <[EMAIL PROTECTED]> wrote:

> #97: r.random fails with bus error on Mac OS X 10.5
> ---+
>   Reporter:  cmbarton  |   Owner:  grass-dev@lists.osgeo.org
>   Type:  defect|  Status:  new
>   Priority:  critical  |   Milestone:  6.3.0
>  Component:  default   | Version:  unspecified
> Resolution:|Keywords:  r.random Mac
> ---+
> Comment (by kyngchaos):
> 
>  Just tested on current SVN and no crash.  Michael?

__
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-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Dylan Beaudette]

On Wed, Apr 16, 2008 at 7:47 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008, Dylan Beaudette wrote:
>
>
> > On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> >
> > > On two very similar systems built today from the RC6 tarball (i686
> RHEL5,
> > > F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> > > traditional "output" on RHEL5. The tarballs have the same md5sums. Why?
> > >
> > >  r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
> > >
> > >  lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE is
> a
> > > different entry in the enum definition. I find this puzzling ...
> > >
> > >  Roger
> > >
> >
> > Hi Roger,
> >
> > Did you do a:
> >
> > make distclean
> >
> > before compiling the source?
> >
>
>  Hi,
>
>  I used the tarball, and untarred to a fresh directory. Should I still have
> said make distclean? I'll try - but why the different behaviour? The windows
> native binary is "output".
>
>  Best wishes,
>
>  Roger

I have seen / heard / read that a make distclean can be of use-- but I
think that I spoke too soon. It is usually related to re-compiling
only portions of the source. Not sure what it could be.

Dylan

>
>
> >
> > Cheers,
> >
> > Dylan
> >
> >
> >
> > >
> > >  --
> > >  Roger Bivand
> > >  Economic Geography Section, Department of Economics, Norwegian School
> of
> > >  Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> > >  Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> > >  e-mail: [EMAIL PROTECTED]
> > >
> > >  ___
> > >  grass-dev mailing list
> > >  grass-dev@lists.osgeo.org
> > >  http://lists.osgeo.org/mailman/listinfo/grass-dev
> > >
> > >
> >
> >
>
>  --
>
>  Roger Bivand
>  Economic Geography Section, Department of Economics, Norwegian School of
>  Economics and Business Administration, Helleveien 30, N-5045 Bergen,
>  Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
>  e-mail: [EMAIL PROTECTED]
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] db commands on vectors stored in another mapset

[Dylan Beaudette]

Hi,

Using the spearfish dataset:

# start grass
grass63 grass/spearfish60/user1/

# dump the table associated with 'bugsites' in PERMANENT
db.select [EMAIL PROTECTED]

dbmi: Protocol error
dbmi: Protocol error

# one more try:
db.select bugsites

DBMI-DBF driver error:
Table 'bugsites' doesn't exist.
Error in db_open_select_cursor()


# now with some debugging:
db.select bugsites

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: DBF: db__driver_open_database() name =
'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
D3/5: tokens[0] = $GISDBASE
D3/5:-> /home/dylan/grass
D3/5: tokens[1] = $LOCATION_NAME
D3/5:-> spearfish60
D3/5: tokens[2] = $MAPSET
D3/5:-> user1
D3/5: tokens[3] = dbf
D2/5: db.name = /home/dylan/grass/spearfish60/user1/dbf/
D3/5: SQL statement parsed successfully: select * from bugsites
D2/5: find_table(): table = bugsites
DBMI-DBF driver error:
Table 'bugsites' doesn't exist.
Error in db_open_select_cursor()

# one more try with the @mapset notation:
db.select [EMAIL PROTECTED]
D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: DBF: db__driver_open_database() name =
'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
D3/5: tokens[0] = $GISDBASE
D3/5:-> /home/dylan/grass
D3/5: tokens[1] = $LOCATION_NAME
D3/5:-> spearfish60
D3/5: tokens[2] = $MAPSET
D3/5:-> user1
D3/5: tokens[3] = dbf
D2/5: db.name = /home/dylan/grass/spearfish60/user1/dbf/
dbmi: Protocol error
dbmi: Protocol error

Is this the normal behavior? i.e. I can "use" raster and vector files
across mapsets, but why not vector attributes?

This is on GRASS SVN (31012) x86 and AMD.

As a work-around, it is possible to first copy the vector from one
mapset to another, and then the regular db.* commands will work.

Cheers,

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

R: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[marco.pasetti]

Hi Moritz,
 
>This actually sounds much more sophisticated than what Glynn proposed.
 
yes, it is... but we could make a walkaround... I'll explain how later...
 
>Could you not simply propose one installer with only the latest
>(complete) GRASS binaries. This installer could check for any existing
>installation of GRASS and propose to erase that before installing the
>new version, or install the new version next to the old.
 
very good ;-) we are at the same *point* here. I already thought it some weeks 
ago, before ro release RC6... and that's why I already added in RC6 installer 
some registry key values that would let me the job (that is: let future 
installers recognise if GRASS is already istalled on the system, what version 
and where). I already talked with Markus about this option in future WinGRASS 
installers.
 
>The question then is: do we need a "complete" installer with everything
>in it (as you suggest), or can we impose the burden of two installers on
>people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>installer. I think this would be the best solution for us, but it would
>mean that at least for the first installation, users will have to
>install two packages. If the GRASS installer could test for the
>installation of the other package and propose to download it and lauch
>its installation autmagically, then this might be the best solution.
 
what do you mean about *dependencies*? the only dependencies that are 
indipendent to GRASS binaries is Python!
all the other DLLs are necessary to start GRASS. What would happen if we 
release GRASS with an additional support (jpeg, for example) not previously 
supported? we must provide the libjpeg with the installer, or update the 
*dependencies installer*?
IMHO, this is a sctrictly UNIX way to think... windows is very different: if 
you release binaries, you must provide all the DLLs needed by those binaries 
along with them.
It would be a *safer* solution to release future WinGRASS installers along with 
a separated updater: in that way new users would install the whole GRASS 
package (why provide 2 different installers when users absolutely need to 
install both GRASS bins and Deps?) or simply download and lunch a smaller 
updater, that would copy/replace only the new bins and libs.
 
BTW, I still think that providing separated installers for GRASS and its 
dependencies is a nonsense...
 
Best regards,
 
Marco




Da: Moritz Lennert [mailto:[EMAIL PROTECTED]
Inviato: mer 16/04/2008 15.07
A: [EMAIL PROTECTED]
Cc: Glynn Clements; Martin Landa; GRASS developers list
Oggetto: Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released



On 16/04/08 10:41, [EMAIL PROTECTED] wrote:
> Glynn,
> 
>  >I would suggest two installers: one for GRASS alone, and one for the
> various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> shouldn't have to download all of the dependencies each time a new
> version of GRASS is released.
> we could do as follows:
> 
> 1. a *complete*, *first time* GRASS installer, based on latest release,
> with all the dependencies built-in
> 2. and *updater*, installed along the *first installation*, that check
> the WinGRASS repository looking for last GRASS updates, and
> download/install only the latest updated files (both for GRASS and
> dependencies). It would be not an easy work, but I think that I'll can
> do it... even if not very soon :-)

This actually sounds much more sophisticated than what Glynn proposed.
Could you not simply propose one installer with only the latest
(complete) GRASS binaries. This installer could check for any existing
installation of GRASS and propose to erase that before installing the
new version, or install the new version next to the old.

The question then is: do we need a "complete" installer with everything
in it (as you suggest), or can we impose the burden of two installers on
people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
installer. I think this would be the best solution for us, but it would
mean that at least for the first installation, users will have to
install two packages. If the GRASS installer could test for the
installation of the other package and propose to download it and lauch
its installation autmagically, then this might be the best solution.

But you're the one doing the work, so the ultimate decision will be
yours ;-)

Moritz



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

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Markus Neteler]

Roger Bivand wrote:

On Wed, 16 Apr 2008, Dylan Beaudette wrote:

On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> 
wrote:
On two very similar systems built today from the RC6 tarball (i686 
RHEL5,

F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?

 r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.

 lib/gis/parser.c sets Opt->key to "output" in both, and 
G_OPT_R_BASE is a

different entry in the enum definition. I find this puzzling ...

 Roger


Hi Roger,

Did you do a:

make distclean

before compiling the source?


Hi,

I used the tarball, and untarred to a fresh directory. Should I still 
have said make distclean? I'll try - but why the different behaviour? 
The windows native binary is "output".



Dear Roger,

on a fresh tarball "make distclean" isn't needed.
I suspect that your binaries pick a wrong library. Could
you check with "ldd"?
I am using the release branch in production and didn't come
across this problem.

Markus

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

[GRASS-dev] [GRASS GIS] #127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window

[GRASS GIS]

#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
---+
 Reporter:  4everskiff |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:  6.3.0
Component:  Tcl| Version:  6.3.0 RCs
 Keywords:  Text output, winGRASS  |  
---+
 Tested with WinGRASS-6.3.0RC6 on Windows XP

 Tcl/Tk GUI
 Output window

 After running a command, with every text output that doesn't start with an
 icon (such as error or alarm icon), the firt letter of the output is
 placed in the upper line, instead to appear in *its* line.

 Screeshot example attached

 Marco

-- 
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] GRASS 6.3.0 to be released

[Michael Barton]

Marco,

I see what you mean on Windows. Actually, in this case, there are no
dependencies like you find on Unix systems. A separate install for
Msys/TclTk/Python might be useful. Then that part could be installed only as
needed and GRASS could be updated more often.

Michael


On 4/16/08 9:00 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> Date: Wed, 16 Apr 2008 17:18:30 +0200
> From: <[EMAIL PROTECTED]>
> Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
> To: "Moritz Lennert" <[EMAIL PROTECTED]>
> Cc: Martin Landa <[EMAIL PROTECTED]>, Glynn Clements
> <[EMAIL PROTECTED]>, GRASS developers list
> 
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Moritz,
>  
>> This actually sounds much more sophisticated than what Glynn proposed.
>  
> yes, it is... but we could make a walkaround... I'll explain how later...
>  
>> Could you not simply propose one installer with only the latest
>> (complete) GRASS binaries. This installer could check for any existing
>> installation of GRASS and propose to erase that before installing the
>> new version, or install the new version next to the old.
>  
> very good ;-) we are at the same *point* here. I already thought it some weeks
> ago, before ro release RC6... and that's why I already added in RC6 installer
> some registry key values that would let me the job (that is: let future
> installers recognise if GRASS is already istalled on the system, what version
> and where). I already talked with Markus about this option in future WinGRASS
> installers.
>  
>> The question then is: do we need a "complete" installer with everything
>> in it (as you suggest), or can we impose the burden of two installers on
>> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>> installer. I think this would be the best solution for us, but it would
>> mean that at least for the first installation, users will have to
>> install two packages. If the GRASS installer could test for the
>> installation of the other package and propose to download it and lauch
>> its installation autmagically, then this might be the best solution.
>  
> what do you mean about *dependencies*? the only dependencies that are
> indipendent to GRASS binaries is Python!
> all the other DLLs are necessary to start GRASS. What would happen if we
> release GRASS with an additional support (jpeg, for example) not previously
> supported? we must provide the libjpeg with the installer, or update the
> *dependencies installer*?
> IMHO, this is a sctrictly UNIX way to think... windows is very different: if
> you release binaries, you must provide all the DLLs needed by those binaries
> along with them.
> It would be a *safer* solution to release future WinGRASS installers along
> with a separated updater: in that way new users would install the whole GRASS
> package (why provide 2 different installers when users absolutely need to
> install both GRASS bins and Deps?) or simply download and lunch a smaller
> updater, that would copy/replace only the new bins and libs.
>  
> BTW, I still think that providing separated installers for GRASS and its
> dependencies is a nonsense...
>  
> Best regards,
>  
> Marco

__
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-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


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

R: [GRASS-dev] GRASS 6.3.0 to be released

[marco.pasetti]

Michael,
 
>I see what you mean on Windows. Actually, in this case, there are no
>dependencies like you find on Unix systems
 
thx. it's difficult to be a Windows user here. GRASS people is used to work on 
too much advanced systems than I'm used to ;-) (even if I'm a linux user too)
 
>A separate install for Msys/TclTk/Python might be useful.
 
MSYS:
---
I think we could provide MSYS as install option or don't provide it at all... 
if people want MSYS they can download and install using the official MSYS 
installer (the GRASS installer could just check if MSYS is installed and create 
the grass63 file into /usr msys folder, according to selected GRASS install 
path, as it already does)
 
TclTk
---
This is needed, since GRASS is built with it and some binaries require tcl/tk 
DLLs. I think we must provide it along binaries
 
Python
---
I think that's the only indipendent package installer we could provide.
 
>Then that part could be installed only as
>needed and GRASS could be updated more often.
 
I think that's not a *frequency* problem, but just a *weight* problem of the 
installers provided.
 
If I had built a new version of GRASS to release, it's not absolutely a problem 
for me to package all the other files along with it (I mean the new GRASS 
build) as I as did with the WinGRASS-6.3.0RC5 and RC6 releases. I need to just 
run an automated batch file I wrote for the job, and then compile the NSIS 
script to create the related installer. The whole packaging job takes approx 5 
minutes!
 
I hope to have well described the *situation*
 
Best regards,
 
Marco
 



Da: [EMAIL PROTECTED] per conto di Michael Barton
Inviato: mer 16/04/2008 18.15
A: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released



Marco,

I see what you mean on Windows. Actually, in this case, there are no
dependencies like you find on Unix systems. A separate install for
Msys/TclTk/Python might be useful. Then that part could be installed only as
needed and GRASS could be updated more often.

Michael


On 4/16/08 9:00 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> Date: Wed, 16 Apr 2008 17:18:30 +0200
> From: <[EMAIL PROTECTED]>
> Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
> To: "Moritz Lennert" <[EMAIL PROTECTED]>
> Cc: Martin Landa <[EMAIL PROTECTED]>, Glynn Clements
> <[EMAIL PROTECTED]>, GRASS developers list
> 
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Moritz,
> 
>> This actually sounds much more sophisticated than what Glynn proposed.
> 
> yes, it is... but we could make a walkaround... I'll explain how later...
> 
>> Could you not simply propose one installer with only the latest
>> (complete) GRASS binaries. This installer could check for any existing
>> installation of GRASS and propose to erase that before installing the
>> new version, or install the new version next to the old.
> 
> very good ;-) we are at the same *point* here. I already thought it some weeks
> ago, before ro release RC6... and that's why I already added in RC6 installer
> some registry key values that would let me the job (that is: let future
> installers recognise if GRASS is already istalled on the system, what version
> and where). I already talked with Markus about this option in future WinGRASS
> installers.
> 
>> The question then is: do we need a "complete" installer with everything
>> in it (as you suggest), or can we impose the burden of two installers on
>> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>> installer. I think this would be the best solution for us, but it would
>> mean that at least for the first installation, users will have to
>> install two packages. If the GRASS installer could test for the
>> installation of the other package and propose to download it and lauch
>> its installation autmagically, then this might be the best solution.
> 
> what do you mean about *dependencies*? the only dependencies that are
> indipendent to GRASS binaries is Python!
> all the other DLLs are necessary to start GRASS. What would happen if we
> release GRASS with an additional support (jpeg, for example) not previously
> supported? we must provide the libjpeg with the installer, or update the
> *dependencies installer*?
> IMHO, this is a sctrictly UNIX way to think... windows is very different: if
> you release binaries, you must provide all the DLLs needed by those binaries
> along with them.
> It would be a *safer* solution to release future WinGRASS installers along
> with a separated updater: in that way new users would install the whole GRASS
> package (why provide 2 different installers when users absolutely need to
> install both GRASS bins and Deps?) or simply download and lunch a smaller
> updater, that would copy/replace only the new bins and libs.
> 
> BTW, I still think that providing separated installers for GRASS and its

[GRASS-dev] Re: [GRASS GIS] #127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window

[GRASS GIS]

#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
  Reporter:  4everskiff  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.3.0
 Component:  Tcl | Version:  6.3.0 RCs
Resolution:  |Keywords:  Text output, winGRASS
-+--
Comment (by pkelly):

 Does this really apply to every command? Can you give another example
 other than "g.region -p"?

 Also, how was the location created? Does the same behaviour occur in a
 location that wasn't created using WinGRASS (e.g. does it happen with
 spearfish?)

 Potential technical explanation:
 I suspect it might just be another example of G_getl() needing to be
 replaced by G_getl2() when reading the projections file and creating the
 PROJ_INFO - the newline character is stripped off but the carriage return
 isn't.

 IMHO the best solution to this is to audit all occurences of G_getl() and
 replace them with G_getl2() if there are no potential problems, then
 replace G_getl() itself with a wrapper to G_getl2().

-- 
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: R: [GRASS-dev] GRASS 6.3.0 to be released

[Michael Barton]

You have described it well. If it¹s easier to just do a single package, then
I think that is what you should do. That is what most Windows (and Mac)
users expect anyway.

Michael


On 4/16/08 9:40 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Michael,
>  
>> >I see what you mean on Windows. Actually, in this case, there are no
>> >dependencies like you find on Unix systems
>  
> thx. it's difficult to be a Windows user here. GRASS people is used to work on
> too much advanced systems than I'm used to ;-) (even if I'm a linux user too)
>  
>> >A separate install for Msys/TclTk/Python might be useful.
>  
> MSYS:
> ---
> I think we could provide MSYS as install option or don't provide it at all...
> if people want MSYS they can download and install using the official MSYS
> installer (the GRASS installer could just check if MSYS is installed and
> create the grass63 file into /usr msys folder, according to selected GRASS
> install path, as it already does)
>  
> TclTk
> ---
> This is needed, since GRASS is built with it and some binaries require tcl/tk
> DLLs. I think we must provide it along binaries
>  
> Python
> ---
> I think that's the only indipendent package installer we could provide.
>  
>> >Then that part could be installed only as
>> >needed and GRASS could be updated more often.
>  
> I think that's not a *frequency* problem, but just a *weight* problem of the
> installers provided.
>  
> If I had built a new version of GRASS to release, it's not absolutely a
> problem for me to package all the other files along with it (I mean the new
> GRASS build) as I as did with the WinGRASS-6.3.0RC5 and RC6 releases. I need
> to just run an automated batch file I wrote for the job, and then compile the
> NSIS script to create the related installer. The whole packaging job takes
> approx 5 minutes!
>  
> I hope to have well described the *situation*
>  
> Best regards,
>  
> Marco
>  
> 
> 
> Da: [EMAIL PROTECTED] per conto di Michael Barton
> Inviato: mer 16/04/2008 18.15
> A: grass-dev@lists.osgeo.org
> Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released
> 
> Marco,
> 
> I see what you mean on Windows. Actually, in this case, there are no
> dependencies like you find on Unix systems. A separate install for
> Msys/TclTk/Python might be useful. Then that part could be installed only as
> needed and GRASS could be updated more often.
> 
> Michael
> 
> 
> On 4/16/08 9:00 AM, "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]> wrote:
> 
>> > Date: Wed, 16 Apr 2008 17:18:30 +0200
>> > From: <[EMAIL PROTECTED]>
>> > Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
>> > To: "Moritz Lennert" <[EMAIL PROTECTED]>
>> > Cc: Martin Landa <[EMAIL PROTECTED]>, Glynn Clements
>> > <[EMAIL PROTECTED]>, GRASS developers list
>> > 
>> > Message-ID:
>> > <[EMAIL PROTECTED]>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > Hi Moritz,
>> > 
>>> >> This actually sounds much more sophisticated than what Glynn proposed.
>> > 
>> > yes, it is... but we could make a walkaround... I'll explain how later...
>> > 
>>> >> Could you not simply propose one installer with only the latest
>>> >> (complete) GRASS binaries. This installer could check for any existing
>>> >> installation of GRASS and propose to erase that before installing the
>>> >> new version, or install the new version next to the old.
>> > 
>> > very good ;-) we are at the same *point* here. I already thought it some
>> weeks
>> > ago, before ro release RC6... and that's why I already added in RC6
>> installer
>> > some registry key values that would let me the job (that is: let future
>> > installers recognise if GRASS is already istalled on the system, what
>> version
>> > and where). I already talked with Markus about this option in future
>> WinGRASS
>> > installers.
>> > 
>>> >> The question then is: do we need a "complete" installer with everything
>>> >> in it (as you suggest), or can we impose the burden of two installers on
>>> >> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>>> >> installer. I think this would be the best solution for us, but it would
>>> >> mean that at least for the first installation, users will have to
>>> >> install two packages. If the GRASS installer could test for the
>>> >> installation of the other package and propose to download it and lauch
>>> >> its installation autmagically, then this might be the best solution.
>> > 
>> > what do you mean about *dependencies*? the only dependencies that are
>> > indipendent to GRASS binaries is Python!
>> > all the other DLLs are necessary to start GRASS. What would happen if we
>> > release GRASS with an additional support (jpeg, for example) not previously
>> > supported? we must provide the libjpeg with the installer, or update the
>> > *dependencies installer*?
>> > IMHO, this is a sctrictly UNIX way to think... windows is very different:
>> if
>> > you release binaries, you must provide al

Re: [GRASS-dev] db commands on vectors stored in another mapset

[Maciej Sieczka]

Dylan Beaudette pisze:


Is this the normal behavior? i.e. I can "use" raster and vector files
across mapsets, but why not vector attributes?


Because you are using DBF driver and your database is in:

$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

(check with db.connect -p). This results in a different path from mapset 
to mapset. I guess this is a feature.


In order to use db.select cross-mapset with DBF driver you need to set 
database= explicitely.


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

Re: [GRASS-dev] db commands on vectors stored in another mapset

[Dylan Beaudette]

On Wednesday 16 April 2008, Maciej Sieczka wrote:
> Dylan Beaudette pisze:
> > Is this the normal behavior? i.e. I can "use" raster and vector files
> > across mapsets, but why not vector attributes?
>
> Because you are using DBF driver and your database is in:
>
> $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
>
> (check with db.connect -p). This results in a different path from mapset
> to mapset. I guess this is a feature.
>
> In order to use db.select cross-mapset with DBF driver you need to set
> database= explicitely.
>
> Maciek

Thanks Maciek.

I see that the following works as expected:

# not logged into the 'PERMANENT' mapset
db.select bugsites database=/home/dylan/grass/spearfish60/PERMANENT/dbf/


I suppose that altering the behavior of the db.* commands would be dangerous, 
and really should respect the current mapset's database connection. 

How hard would it be to parse the @mapset, remove it in the actual SQL, but 
pass it into the 'database' selection? Or more importantly, is there any way 
to make typing 'database=/home/dylan/grass/spearfish60/PERMANENT/dbf/' any 
less painfull?

Cheers,

Dylan


-- 
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: [GRASS GIS] #127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window

[GRASS GIS]

#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
  Reporter:  4everskiff  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.3.0
 Component:  Tcl | Version:  6.3.0 RCs
Resolution:  |Keywords:  Text output, winGRASS
-+--
Comment (by 4everskiff):

 Replying to [comment:1 pkelly]:
 > Does this really apply to every command? Can you give another example
 other than "g.region -p"?
 >
 > Also, how was the location created? Does the same behaviour occur in a
 location that wasn't created using WinGRASS (e.g. does it happen with
 spearfish?)
 >
 > Potential technical explanation:
 > I suspect it might just be another example of G_getl() needing to be
 replaced by G_getl2() when reading the projections file and creating the
 PROJ_INFO - the newline character is stripped off but the carriage return
 isn't.
 >
 > IMHO the best solution to this is to audit all occurences of G_getl()
 and replace them with G_getl2() if there are no potential problems, then
 replace G_getl() itself with a wrapper to G_getl2().

 Hi Paul,

 I confirm that I dedected the same bug with other commands (such as
 r.horizon, for example) and also with spearfish.

 Marco

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

R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Marco Pasetti]

Hi Michael,
 
>If it’s easier to just do a single package, then I think that is what you
should do. That is what most Windows (and Mac) users expect anyway.

...and that's very good to hear for me ;-)
 
Marco

  _  

Da: Michael Barton [mailto:[EMAIL PROTECTED] 
Inviato: mercoledì 16 aprile 2008 19.16
A: [EMAIL PROTECTED]; grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released


You have described it well. If it’s easier to just do a single package, then
I think that is what you should do. That is what most Windows (and Mac)
users expect anyway.

Michael


On 4/16/08 9:40 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:



Michael,

>I see what you mean on Windows. Actually, in this case, there are no
>dependencies like you find on Unix systems
 
thx. it's difficult to be a Windows user here. GRASS people is used to work
on too much advanced systems than I'm used to ;-) (even if I'm a linux user
too)
 
>A separate install for Msys/TclTk/Python might be useful.
 
MSYS:
---
I think we could provide MSYS as install option or don't provide it at
all... if people want MSYS they can download and install using the official
MSYS installer (the GRASS installer could just check if MSYS is installed
and create the grass63 file into /usr msys folder, according to selected
GRASS install path, as it already does)
 
TclTk
---
This is needed, since GRASS is built with it and some binaries require
tcl/tk DLLs. I think we must provide it along binaries
 
Python
---
I think that's the only indipendent package installer we could provide.
 
>Then that part could be installed only as
>needed and GRASS could be updated more often.
 
I think that's not a *frequency* problem, but just a *weight* problem of the
installers provided.
 
If I had built a new version of GRASS to release, it's not absolutely a
problem for me to package all the other files along with it (I mean the new
GRASS build) as I as did with the WinGRASS-6.3.0RC5 and RC6 releases. I need
to just run an automated batch file I wrote for the job, and then compile
the NSIS script to create the related installer. The whole packaging job
takes approx 5 minutes!
 
I hope to have well described the *situation*
 
Best regards,
 
Marco
 


  _  

Da: [EMAIL PROTECTED] per conto di Michael Barton
Inviato: mer 16/04/2008 18.15
A: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released

Marco,

I see what you mean on Windows. Actually, in this case, there are no
dependencies like you find on Unix systems. A separate install for
Msys/TclTk/Python might be useful. Then that part could be installed only as
needed and GRASS could be updated more often.

Michael


On 4/16/08 9:00 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> Date: Wed, 16 Apr 2008 17:18:30 +0200
> From: <[EMAIL PROTECTED]>
> Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
> To: "Moritz Lennert" <[EMAIL PROTECTED]>
> Cc: Martin Landa <[EMAIL PROTECTED]>, Glynn Clements
> <[EMAIL PROTECTED]>, GRASS developers list
> 
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Moritz,
> 
>> This actually sounds much more sophisticated than what Glynn proposed.
> 
> yes, it is... but we could make a walkaround... I'll explain how later...
> 
>> Could you not simply propose one installer with only the latest
>> (complete) GRASS binaries. This installer could check for any existing
>> installation of GRASS and propose to erase that before installing the
>> new version, or install the new version next to the old.
> 
> very good ;-) we are at the same *point* here. I already thought it some
weeks
> ago, before ro release RC6... and that's why I already added in RC6
installer
> some registry key values that would let me the job (that is: let future
> installers recognise if GRASS is already istalled on the system, what
version
> and where). I already talked with Markus about this option in future
WinGRASS
> installers.
> 
>> The question then is: do we need a "complete" installer with everything
>> in it (as you suggest), or can we impose the burden of two installers on
>> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>> installer. I think this would be the best solution for us, but it would
>> mean that at least for the first installation, users will have to
>> install two packages. If the GRASS installer could test for the
>> installation of the other package and propose to download it and lauch
>> its installation autmagically, then this might be the best solution.
> 
> what do you mean about *dependencies*? the only dependencies that are
> indipendent to GRASS binaries is Python!
> all the other DLLs are necessary to start GRASS. What would happen if we
> release GRASS with an additional support (jpeg, for example) not
previously
> supported? we must provide the libjpeg with the installer, or update the
> *dependencies installer*?
>

[GRASS-dev] [GRASS GIS] #128: NVIZ fails to load vector points without other map

[GRASS GIS]

#128: NVIZ fails to load vector points without other map
-+--
 Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.0
Component:  default  | Version:  svn-trunk
 Keywords:  tcl  |  
-+--
 I hoped to load a 2D or a 3D points map into NVIZ (Lidar points). But it
 crashes:

 {{{
 v.info -t lidar1map3d
 nodes=37997
 points=38008
 lines=0
 boundaries=0
 centroids=0
 areas=0
 islands=0
 faces=0
 kernels=0
 primitives=38008
 map3d=1

 v.out.ascii lidar1map3d |head -3
 512743.63|5403547.33|308.68|1
 512743.62|5403547.33|308.7|2
 512743.61|5403547.33|308.72|3

 nviz point=lidar1map3d
 WARNING: Adapted sites library used for vector points (module should be
  updated to GRASS 6 vector library).
 Site dim: 3
 Sites file lidar1map3d loaded.
 Error in startup script: can't use non-numeric floating-point value as
 operand of "*"
 while executing
 "expr int($curr * 1)"
 (procedure "Nv_mkFloatScale" line 16)
 invoked from within
 "Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height
 1"
 (procedure "mk_hgt_slider" line 12)
 invoked from within
 "mk_hgt_slider $BASE.midf"
 (procedure "mkmainPanel" line 143)
 invoked from within
 "mk$name\Panel $path"
 invoked from within
 "if [catch {set Nv_($path)}] {
 set file panel_$name.tcl
 set Nv_($path) [mk$name\Panel $path]
 }"
 (procedure "Nv_force_panel" line 8)
 invoked from within
 "Nv_force_panel main"
 (procedure "Nv_makeGUI" line 183)
 invoked from within
 "Nv_makeGUI .top"
 (file "/home/neteler/grass63/dist.x86_64-unknown-linux-
 gnu/etc/nviz2.2/scripts/nviz2.2_script" line 1046)
 }}}

 Markus

-- 
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] #46: NVIZ fly mode broken on 64bit systems

[GRASS GIS]

#46: NVIZ fly mode broken on 64bit systems
--+-
  Reporter:  marisn   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  nviz 
--+-
Comment (by neteler):

 Confirmed on Mandriva 2008.0/64bit with NVIDIA.

-- 
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] #128: NVIZ fails to load vector points without other map

[GRASS GIS]

#128: NVIZ fails to load vector points without other map
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  nviz 
--+-
Changes (by neteler):

  * keywords:  tcl => nviz

-- 
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] G_OPT_R_OUTPUT base or output?

[Roger Bivand]

On Wed, 16 Apr 2008, Markus Neteler wrote:


Roger Bivand wrote:

 On Wed, 16 Apr 2008, Dylan Beaudette wrote:

>  On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> 
>  wrote:
> >  On two very similar systems built today from the RC6 tarball (i686 
> >  RHEL5,

> >  F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> >  traditional "output" on RHEL5. The tarballs have the same md5sums. 
> >  Why?
> > 
> >   r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
> > 
> >  lib/gis/parser.c sets Opt->key to "output" in both, and G_OPT_R_BASE 
> >  is a

> >  different entry in the enum definition. I find this puzzling ...
> > 
> >   Roger
> 
>  Hi Roger,
> 
>  Did you do a:
> 
>  make distclean
> 
>  before compiling the source?


 Hi,

 I used the tarball, and untarred to a fresh directory. Should I still have
 said make distclean? I'll try - but why the different behaviour? The
 windows native binary is "output".


Dear Roger,

on a fresh tarball "make distclean" isn't needed.
I suspect that your binaries pick a wrong library. Could
you check with "ldd"?
I am using the release branch in production and didn't come
across this problem.


This is possible - both affected systems, the F7 system refered to above - 
documented here:



GRASS 6.3.0RC6 (spearfish60):~ > r.in.bin --interface-description




...

multiple="no">


Name for output raster map

...

GRASS 6.3.0RC6 (spearfish60):~ > R

R version 2.6.2 (2008-02-08)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
...


system("r.in.bin --interface-description")





...



Name of base raster map

...

and an odd problem on a Cygwin 6.2.3 installation
(key modules do not write to stderr or stdout, documented in: 
http://spatial.nhh.no/misc/cw.png) - problem started after updating cygwin 
packages last night,


have odd/stale things in the GRASS_LD_LIBRARY_PATH and in PATH (or LD 
path) environment variables. I don't have ldd on Cygwin, but will look 
under F7.


I was just checking a few extra systems to see how the R interface worked 
on the final RC before release, that's why I'm asking.


Roger



Markus





--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]

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

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Hamish]

Roger Bivand wrote:
> I don't have ldd on Cygwin, but will look under F7.


use cygcheck,

http://grass.osgeo.org/grass62/binary/mswindows/#trouble


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 GIS] #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]

[Glynn Clements]

GRASS GIS wrote:

> #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
> --+-
>   Reporter:  steko|   Owner:  grass-dev@lists.osgeo.org
>   Type:  defect   |  Status:  closed   
>   Priority:  major|   Milestone:  6.4.0
>  Component:  default  | Version:  6.3.0 RCs
> Resolution:  fixed|Keywords:  g.copy   
> --+-
> Comment (by neteler):
> 
>  Should this be backported to 6.3.0 release branch?

Yes.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Glynn Clements]

[EMAIL PROTECTED] wrote:

> >I would suggest two installers: one for GRASS alone, and one for the
> >various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> >shouldn't have to download all of the dependencies each time a new
> >version of GRASS is released.
> 
> we could do as follows:
>  
> 1. a *complete*, *first time* GRASS installer, based on latest release,
> with all the dependencies built-in
> 2. and *updater*, installed along the *first installation*, that check
> the WinGRASS repository looking for last GRASS updates, and
> download/install only the latest updated files (both for GRASS and
> dependencies). It would be not an easy work, but I think that I'll can
> do it... even if not very soon :-)

I don't see much point in doing both. If you have #2, it makes #1
rather pointless.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Glynn Clements]

Moritz Lennert wrote:

> >  >I would suggest two installers: one for GRASS alone, and one for the
> > various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> > shouldn't have to download all of the dependencies each time a new
> > version of GRASS is released.
> > we could do as follows:
> >  
> > 1. a *complete*, *first time* GRASS installer, based on latest release, 
> > with all the dependencies built-in
> > 2. and *updater*, installed along the *first installation*, that check 
> > the WinGRASS repository looking for last GRASS updates, and 
> > download/install only the latest updated files (both for GRASS and 
> > dependencies). It would be not an easy work, but I think that I'll can 
> > do it... even if not very soon :-)
> 
> This actually sounds much more sophisticated than what Glynn proposed. 
> Could you not simply propose one installer with only the latest 
> (complete) GRASS binaries. This installer could check for any existing 
> installation of GRASS and propose to erase that before installing the 
> new version, or install the new version next to the old.
> 
> The question then is: do we need a "complete" installer with everything 
> in it (as you suggest), or can we impose the burden of two installers on 
> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies 
> installer. I think this would be the best solution for us, but it would 
> mean that at least for the first installation, users will have to 
> install two packages. If the GRASS installer could test for the 
> installation of the other package and propose to download it and lauch 
> its installation autmagically, then this might be the best solution.

I don't think that you even need to go that far. If downloading and
running (in the correct order) two installers is beyond the user's
abilities, chances are that they'll spend a couple of days flooding
the grass-user ML with noob questions before giving up on GRASS
altogether.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released

[Glynn Clements]

[EMAIL PROTECTED] wrote:

> >The question then is: do we need a "complete" installer with everything
> >in it (as you suggest), or can we impose the burden of two installers on
> >people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
> >installer. I think this would be the best solution for us, but it would
> >mean that at least for the first installation, users will have to
> >install two packages. If the GRASS installer could test for the
> >installation of the other package and propose to download it and lauch
> >its installation autmagically, then this might be the best solution.
>  
> what do you mean about *dependencies*? the only dependencies that
> are indipendent to GRASS binaries is Python! all the other DLLs are
> necessary to start GRASS.

Yes, but there's no need to re-install those same binaries every time
a new version of GRASS comes out. GRASS (and especially WinGRASS) is a
relatively unstable project. I would expect that several GRASS updates
will be released before any of the dependencies need to be upgraded.

> What would happen if we release GRASS with an additional support
> (jpeg, for example) not previously supported? we must provide the
> libjpeg with the installer, or update the *dependencies installer*?
> 
> IMHO, this is a sctrictly UNIX way to think... windows is very
> different: if you release binaries, you must provide all the DLLs
> needed by those binaries along with them.

And the end result is commonly known as "DLL hell", where every
program tries to install a particular version of common DLLs, often
breaking other programs which rely upon those DLLs.

And whenever a security vulnerability is found in a library, you can't
just replace the library; you have to replace a dozen complete
applications (or, more likely, you just live with having hundreds of
unpatched vulnerabilities).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G_OPT_R_OUTPUT base or output?

[Glynn Clements]

Roger Bivand wrote:

> have odd/stale things in the GRASS_LD_LIBRARY_PATH and in PATH (or LD 
> path) environment variables. I don't have ldd on Cygwin, but will look 
> under F7.

On Cygwin, "cygcheck" lists the DLLs which a program uses.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] db commands on vectors stored in another mapset

[Hamish]

> > Dylan Beaudette pisze:
> > > Is this the normal behavior? i.e. I can "use" raster and vector
> > > files across mapsets, but why not vector attributes?
Maciek:
> > Because you are using DBF driver and your database is in:
> >
> > $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
> >
> > (check with db.connect -p). This results in a different path from
> > mapset to mapset. I guess this is a feature.
> > In order to use db.select cross-mapset with DBF driver you need to
> > set database= explicitely.

Dylan:
> I see that the following works as expected:
> 
> # not logged into the 'PERMANENT' mapset
> db.select bugsites
> database=/home/dylan/grass/spearfish60/PERMANENT/dbf/
> 
> I suppose that altering the behavior of the db.* commands would be
> dangerous, and really should respect the current mapset's database
> connection. 
> 
> How hard would it be to parse the @mapset, remove it in the actual SQL,
> but pass it into the 'database' selection? Or more importantly, is
> there any way to make typing
>  'database=/home/dylan/grass/spearfish60/PERMANENT/dbf/'
> any less painfull?


you could try to use v.db.connect on the original vector and hard code
the database= there instead of using the variables. That would mean you
couldn't easily move/backup the map then and it would be tied to that
dir. Also I'm not sure it would work, but it might.


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] Re: [GRASS GIS] #127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window

[GRASS GIS]

#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
  Reporter:  4everskiff  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.3.0
 Component:  Tcl | Version:  6.3.0 RCs
Resolution:  |Keywords:  Text output, winGRASS
-+--
Comment (by hamish):

 before ripping lots of code apart and applying a sledge hammer solution in
 the vague hope it might solve the problem, I think it better to look at
 the Tcl code and try to track down exactly what the problem is. (first
 step is to identify where in the code this is; 2nd is why)

 Of course fgets() + G_getl() -> G_get2() needs to be done in many places.
 Also we need to determine if all grass text files (including WIND and
 raster cellhd files, etc) are specified as using UNIX newlines or native
 newlines for strict writing. (keep reading loose)

 Is there any reason to keep the current G_getl() beyond backwards
 compatibility? (ie any reason not to make it a wrapper for G_getl2())


 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] #128: NVIZ fails to load vector points without other map

[GRASS GIS]

#128: NVIZ fails to load vector points without other map
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  nviz 
--+-
Comment (by hamish):

 FWIW, I've been able to plot a vector map in NVIZ which had 1 million
 faces*, it took some time to render but it worked ok.
 * NYC 3D buildings dataset


 (but points are treated differently than lines and faces in NVIZ)

 see also bug #49: NVIZ displays points (sites) always as thematic



 In the past I was able to plot 3D points, but created a new constant
 surface (so no mapname) from the raster panel and set transparency for it
 to 100%; a trick I'm sure you know. screenshot:
   http://grass.osgeo.org/wiki/Help_with_3D#Vector_3D_point_data



 does it work for you with fewer points or does it work with a surface
 (constant or raster map)? [what do you mean by "without other map"?]

 {{{
 Error in startup script: can't use non-numeric floating-point value as
 operand of "*"
 while executing
 "expr int($curr * 1)"
 (procedure "Nv_mkFloatScale" line 16)
 invoked from within
 "Nv_mkFloatScale   .
 }}}

 hmmm,


 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] G_OPT_R_OUTPUT base or output?

[Roger Bivand]

On Wed, 16 Apr 2008, Hamish wrote:


Roger Bivand wrote:

I don't have ldd on Cygwin, but will look under F7.



use cygcheck,

http://grass.osgeo.org/grass62/binary/mswindows/#trouble



Thanks to Hamish and Glynn - making a copy of the installed 
/bin/cygjasper-1.dll as /bin/cygjasper-1-701-1.dll (which cygcheck showed 
to be missing) appears to resolve the problem.


The F7 problems were the result of intrusive debris lying around from 
trying to build QGIS without success a little while ago. So ldd did 
resolve it in less than 10 rounds.


Roger




Hamish



 

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




--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]

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

Re: [GRASS-dev] Re: [GRASS GIS] #128: NVIZ fails to load vector points without other map

[Maciej Sieczka]

Comment (by hamish):



(but points are treated differently than lines and faces in NVIZ)

see also bug #49: NVIZ displays points (sites) always as thematic


Hi

Related: there is Bob Covill's patch fixing NVIZ sites dependency [1].
It would be too bad not to have it utilized. It's almost complete AFAICT.

http://wald.intevation.org/tracker/?func=detail&atid=205&aid=371&group_id=21

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