Re: R: [GRASS-dev] WinGRASS Plans

[Glynn Clements]

Marco Pasetti wrote:

> > Check carefully throughout your entire implementation of wxPython. 
> > For the Mac version, wx-config exists in the binaries, but in a
> > place very different from it Linux location.
> 
> I checked carefully. No wx-config file!
> Remember that Mac is Unix-like, so it's normal that you have it,
> even if in another location than on linux; while Windows it's
> definetly another *place to live* :-)

Apart from anything else, wx-config is a bash script, and most Windows
systems don't have bash (and even if they do, they don't understand
the #! mechanism used to run scripts on Unix).

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

[Glynn Clements]

[EMAIL PROTECTED] wrote:

> >When posting error messages, please include the command which
> >generated the error.
>  
> Sorry, I thought it was clear that it was simply the make command

No, I mean the "gcc ... -shared" command which actually links the
library. That's what is generating the errors.

>  
> >However, as OGSF uses av_free directly, configure should really be
> >testing explicitly for libavutil. It isn't necessary on Linux, but
> >Windows handles DLLs differently.
>  
> mmm... probably I need to make things more clear than they actually are now 
> for me!
> avutil.dll is in the same place where the other ffmpegs DLLs are!

The problem is that lib/OGSF/Makefile doesn't actually specify that
-lavutil is required when building the OGSF DLL.

It isn't needed on e.g. Linux, because shared libraries are allowed to
contain unresolved symbols. Those symbols need to be supplied at
run-time, but that happens because libavformat and libavcodec both
depend upon libavutil, so it gets loaded anyhow.

But Windows requires all symbols to be resolved at the point that you
build a DLL. As the OGSF DLL uses av_free() directly, -lavutil must be
specified.

> but there's another thing that I don't undestand: when I create a ddl with 
> gcc on MinGW I usually do as follows:
> 
> gcc -shared -s -o libname.dll -Wl,--out-implib,libname.a  $LIBOBJECTS
> 
> where libname.dll and libname.a are usually installed in
> /usr/local/bin and /usr/local/lib respectively; and when I create an
> executable that uses that library I do:
> 
> gcc -s -g -O2 -o exename.exe $EXEOBJECTS -L./ -lname
>  
> I'm mainly referring to those articles:
> http://www.mingw.org/docs.shtml#compilingandbuilding
> http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
> 
> The strange thing is that there are no *.a import library files
> created by FFMPEG, while I always have them for each library I
> compiled!

AFAICT, you don't actually need import libraries; you can just link
directly against the DLL.

> Last thing: the FFMPEG make script installed the DLLs in
> /ffmpeg/bin,

Windows doesn't have a separate search path for DLLs, it just looks in
$PATH. For Cygwin/MinGW, the "lib" directories are only used for
import libraries; DLLs go in the "bin" directory as that will already
be in $PATH.

> while the /ffmpeg/lib dir is empty, except for the
> pkgconfig folder, that contains the libav*.pc files; I googled for
> them, but I didn't find relevant information on what they exaclty
> are. Do you know some useful articles about that, please?

*.pc are pkg-config files. On Linux, the "official" way to determine
the CFLAGS/LDFLAGS required to use a particular package is e.g.:

$ pkg-config --cflags libavcodec
-I/usr/include/ffmpeg  
$ pkg-config --libs libavcodec
-lavcodec -lz -la52 -lmp3lame -lx264 -lxvidcore -lfaac -lfaad -ldl 
-lX11 -lXext -ltheora -lvorbisenc -lavutil -lvorbis -lm -logg  

Except that most of the -l switches are only necessary if you're using
static libraries, so everyone now adds -Wl,--as-needed to ignore the
redundant -l switches from pkg-config (and from libtool's .la files). 
We don't use pkg-config for FFMPEG (we only use it for cairo at the
moment), so this isn't an issue.

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

Re: [GRASS-dev] SoC Report: v.buffer/v.parallel reimplementation

[Hamish]

Hi,

I know it is very much a work in progress, but some minor comments/suggestions.

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

v.parallel2/main.c
-side_opt->options = "left,right";
+side_opt->options = "both,left,right";
?

v.parallel2/vlib_buffer.c
+#define LENGTH(DX, DY) (sqrt((DX*DX)+(DY*DY)))

why not use hypot() ? There are vector library versions too, for both Cartesian 
and lat/lon. Vect_line_length(), Vect_line_geodesic_length() and the rest in 
lib/vector/Vlib/line.c
Vect_line_geodesic_length() will switch to hypot if location is not lat/lon, 
otherwise it uses the great circle calc.

any thoughts in general on how to deal with parallel lines in lat/lon? I would 
guess to make them parallel "on the ground" rather than as simple parallel 
rhumblines.

3D?


+G_message("tol=%f atol=%f", tol, angular_tol);
I would recommend making good use of G_debug() there. You can set the level to 
"0" to always show the message when developing then adjust that to something 
higher later on.


that's all,
Hamish






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

Re: [GRASS-dev] [SoC] Status Report: Reimplementation of v.voronoi and v.delaunay in GRASS GIS

[Wolf Bergenheim]

Thanks for the update Martin! Yes the quad-edge is a nice structure, 
unfortunately it is quite expensive memory-wise. You might want to look 
at the winged-edge data structure also, which is very memory 
conservative. An idea could be to use different algorithms basing on 
size of the map and perhaps as a user choice.


Some references you should look up:

* Worboys, M.: GIS: A computing Perspective (http://worboys.duckham.org/)

* Delaunay triangulations in TIN creation: an overview and a linear-time 
algorithm (http://tinyurl.com/3s4s4h)


(I have more references should you want more)
--Wolf

On 14.06.2008 00:51, Martin Pavlovsky wrote:

Hello everybody,

Status report #2 for week ending on 13th June, 2008.

This week I studied Guibas-Stolfi algorithm in much more depth. I am 
getting a pretty good understanding of
the underlying quad-edge data structure, which has some very neat 
properties, such as is stores a graph and its dual, which is great, 
since Voronoi diagram and Delaunay triangulation are dual to each other. 
This can be used for very cheap switching from one to the other.


Next week I will be implementing the above mentioned algorithm.

There has not been any blockers so far. However, I had some duties at 
the college,

therefore my progress was slower than I expected.

Regards,

Martin Pavlovsky




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


--

<:3 ) Wolf Bergenheim ( 8:>

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

[GRASS-dev] [SoC] Status Report: Reimplementation of v.voronoi and v.delaunay in GRASS GIS

[Martin Pavlovsky]

Hello everybody,

Status report #2 for week ending on 13th June, 2008.

This week I studied Guibas-Stolfi algorithm in much more depth. I am getting
a pretty good understanding of
the underlying quad-edge data structure, which has some very neat
properties, such as is stores a graph and its dual, which is great, since
Voronoi diagram and Delaunay triangulation are dual to each other. This can
be used for very cheap switching from one to the other.

Next week I will be implementing the above mentioned algorithm.

There has not been any blockers so far. However, I had some duties at the
college,
therefore my progress was slower than I expected.

Regards,

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

Re: R: [GRASS-dev] WinGRASS Plans

[Moritz Lennert]

Marco,

Just saw this:

http://wxconfig.googlepages.com/


Maybe it can help you.

Moritz

On 13/06/08 20:34, Marco Pasetti wrote:

Hi Michael,
 
Check carefully throughout your entire implementation of wxPython. For 
the Mac version, wx-config exists in the binaries, but in a place very 
different from it Linux location.

I checked carefully. No wx-config file!
Remember that Mac is Unix-like, so it's normal that you have it, even if 
in another location than on linux; while Windows it's definetly another 
*place to live* :-)

We'll solve it in another way, soon or later...
 
Regards,
 
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] GRASS 7 development started

[Markus Neteler]

On Tue, Jun 10, 2008 at 7:04 AM, Markus Neteler <[EMAIL PROTECTED]> wrote:
...
> Procedure:
> Server-side:
> - announce date/time of "indent" code reformatting
> - publish the final parameter set
> - run on 7.x.trunk, submit
> - run on 6.4.branch, submit
>
> You local SVN copy:
> - DON'T UPDATE YET but run
>svn status
> - files with local uncommitted changes ("M") need to be treated
>   with the indent command on the *unsubmitted* changed files
>   to avoid later update conflicts
> - *then* update from SVN to re-sync with "svn update"
>
> Makes sense? Can we go ahead?

Getting curious now :)

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

Re: R: [GRASS-dev] WinGRASS Plans

[Marco Pasetti]

Re: R: [GRASS-dev] WinGRASS PlansHi Michael,

>Check carefully throughout your entire implementation of wxPython. For the Mac 
>version, wx-config exists in the binaries, but in a place very different from 
>it Linux location.

I checked carefully. No wx-config file!
Remember that Mac is Unix-like, so it's normal that you have it, even if in 
another location than on linux; while Windows it's definetly another *place to 
live* :-)
We'll solve it in another way, soon or later...

Regards,

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

[GRASS-dev] SoC Report: v.buffer/v.parallel reimplementation

[Росен Матев]

Hi, all

1. What did you get done this week: Elliptical distances feature is
working properly now. Round corners option is working.
2. What do you plan on doing next week: Implement loop removal and by
that finish v.parallel. Then I'll announce it on grass-dev ml so that
the new module could be tested by others. Start working on v.buffer
(around Wednesday).
3. Are you blocked on anything: No

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

[GRASS-dev] Re: [GRASS GIS] #187: CUPS warning when starting wxpython gui.

[GRASS GIS]

#187: CUPS warning when starting wxpython gui.
-+--
  Reporter:  brian   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  minor   |   Milestone:  6.4.0
 Component:  Python  | Version:  svn-trunk
Resolution:  |Keywords:  wxpython g.gui   
-+--
Changes (by martinl):

  * milestone:  => 6.4.0

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

[GRASS-dev] Re: [GRASS GIS] #135: wxgrass: Some statusbar modes obscure mouse-over help text of gui tools

[GRASS GIS]

#135: wxgrass: Some statusbar modes obscure mouse-over help text of gui tools
--+-
  Reporter:  epatton  |   Owner:  martinl  
  Type:  defect   |  Status:  assigned 
  Priority:  trivial  |   Milestone:  6.4.0
 Component:  Python   | Version:  svn-trunk
Resolution:   |Keywords:  wxgrass, gui, window, tootips
--+-
Changes (by martinl):

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

Comment:

 Now fixed in devbr6 and trunk, r31700, r31701.

 Help text printed to the statusbar is disabled for given statusbar modes
 ('Show comp. extent', 'Display mode' and 'Map scale').

 Martin

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

[GRASS-dev] minor trac timeline tweak

[Hamish]

Hi,

Is it possible to adjust the Trac timelime page to only look back 7-10
days by default? It would save some bits... Or do OSGeo server people
have to do that?

  http://trac.osgeo.org/grass/timeline
  http://trac.osgeo.org/grass/wiki/TracIni#timeline-section

/conf/trac.ini
[timeline] 
default_daysback


changeset_show_files would be very nice too.
and changeset_long_messages ...?


with a shorter daysback those more verbose modes wouldn't be as annoying..


comments?

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

Re: R: [GRASS-dev] WinGRASS Plans

[Michael Barton]

Marco,

Check carefully throughout your entire implementation of wxPython. For the
Mac version, wx-config exists in the binaries, but in a place very different
from it Linux location.

Michael


On 6/12/08 3:23 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Hi Michael,
>  
>> >Maybe this is what you have in mind, but I think that the wx-config is only
>> >needed for compiling vdigit, not for using it. Also, I'm pretty sure that if
>> >you install the Windows dev package, it has wx-config.
>  
> I downloaded the Windows dev package, but unfortunately it doesn't contain the
> wx-config file; maybe because it has been built using MS Visual C++. I think
> I'll need to build wxPython from source using MinGW to have the wx-config file
> and, thus, build the new GRASS v.digit.
>  
> I'll let you know.
>  
> 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: R: R: [GRASS-dev] GRASS FFMPEG support

[marco.pasetti]

Hi Glynn,
 
>I know building GRASS on Windows is slower than Linux, but that's
>crazy. On my Linux system, it takes around 4 minutes:
 
Consider that I'm on an Intel Core2 Duo 2.5GHz (T9300, with 6MB of L2 cache!) 
with 4Gb of RAM DDR2 (even if Vista actually uses only 3)!
When compiling the processors don't run at full speed, while on my old machine 
(AMD Athlon64 3000+, 1.8Gh and 1.25GB RAM DDR) the CPU ran at full throttle for 
3 hours, with the fan sounding like a Boeing taking off! The whole MSYS 
environment + GRASS compiling took more than 10 hours with the CPU at its 
100%...
 
>When posting error messages, please include the command which
>generated the error.
 
Sorry, I thought it was clear that it was simply the make command
 
>However, as OGSF uses av_free directly, configure should really be
>testing explicitly for libavutil. It isn't necessary on Linux, but
>Windows handles DLLs differently.
 
mmm... probably I need to make things more clear than they actually are now for 
me!
avutil.dll is in the same place where the other ffmpegs DLLs are!
but there's another thing that I don't undestand: when I create a ddl with gcc 
on MinGW I usually do as follows:

gcc -shared -s -o libname.dll -Wl,--out-implib,libname.a  $LIBOBJECTS

where libname.dll and libname.a are usually installed in /usr/local/bin and 
/usr/local/lib respectively; and when I create an executable that uses that 
library I do:

gcc -s -g -O2 -o exename.exe $EXEOBJECTS -L./ -lname
 
I'm mainly referring to those articles:
http://www.mingw.org/docs.shtml#compilingandbuilding
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options

The strange thing is that there are no *.a import library files created by 
FFMPEG, while I always have them for each library I compiled!
Last thing: the FFMPEG make script installed the DLLs in /ffmpeg/bin, while the 
/ffmpeg/lib dir is empty, except for the pkgconfig folder, that contains the 
libav*.pc files; I googled for them, but I didn't find relevant information on 
what they exaclty are. Do you know some useful articles about that, please?
 
Thanks for your help,
 
Marco
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] cell_misc

[Yann Chemin]

2008/6/13 Hamish <[EMAIL PROTECTED]>:
> Yann Chemin wrote:
>> I am generating 60,000 maps from 60,000 original ones
>>  (shell script looping r.mapcalc),
>>
>> it says unable to create mapset element cell_misc $filename
>
> cell_misc/ saves each map's data in a subdirectory, not a file like the other 
> raster element directories.  is this in a ext3 partition?

yes it is ext3

>
> can you break it up into mapsets of ~ 10k maps each, linked by g.mapsets 
> search path? (thus < 32768 subdirectories/cell_misc)

I would want to avoid doing that since I need to use the data (it is
TRMM) in r.hydro.CASC2D, and it reads straight a filename to which it
adds .

Of course I could do it yearly and save parameters (eventually I may
have to do that...)

>
>> Since it is a (very) long process, I would like to know if
>> I should stop it now, or if it is not impacting of maps and
>> data?
>
> I think NULL data will be missing, if that is important to you.

Not important at all

> is it possible to stop where you are now and modify the script to restart it 
> where it left off? or are later steps dependent on earlier?
>

yes it is possible to stop and restart (chronological datasets) even
at a different YYYMMDDHH

> it is sometimes nice to write variables to a small text file or so as it runs 
> so you can "reseed" the second half of the calculation from an arbitrary 
> point without having to rerun the first.
>
>

Yeah, I may have to do a yearly mapset structure, which would be ~5000
images (1/2 original, 1/2 processed)

> ?
> Hamish
>

Thanks Hamish



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] cell_misc

[Hamish]

Yann Chemin wrote:
> I am generating 60,000 maps from 60,000 original ones
>  (shell script looping r.mapcalc),
> 
> it says unable to create mapset element cell_misc $filename

cell_misc/ saves each map's data in a subdirectory, not a file like the other 
raster element directories.  is this in a ext3 partition?

can you break it up into mapsets of ~ 10k maps each, linked by g.mapsets search 
path? (thus < 32768 subdirectories/cell_misc)

> Since it is a (very) long process, I would like to know if
> I should stop it now, or if it is not impacting of maps and
> data?

I think NULL data will be missing, if that is important to you.
is it possible to stop where you are now and modify the script to restart it 
where it left off? or are later steps dependent on earlier?

it is sometimes nice to write variables to a small text file or so as it runs 
so you can "reseed" the second half of the calculation from an arbitrary point 
without having to rerun the first.


?
Hamish




  

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