[GRASS-dev] (no subject)

[Helmut Kudrnovsky]

Stefan Blumentrath :
>To underpin Jürgens point:
>In my company we used "creatensis.pl" to create custom OSGeo4W installations 
>with modified startup scripts (so users get prepared configurations.
>
>That worked quite well. Doing so for a "GRASS GIS standalone" installer might 
>reduce maintenance, risk of bugs and confusion among users. So, I would 
>definitely recommend to follow Jürgens suggestion.

winGRASS standalone is based upon OSGeo4W and the (dependency) packages there. 
just a simple re-packaging and adapting paths.

what do you mean by "Doing so for a "GRASS GIS standalone" installer might 
reduce maintenance, risk of bugs and confusion among users."?

kind regards
Helmut

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

[GRASS-dev] (no subject)

[Kartik kumar]

Hello Grass-Developers
My name is Kartik, I am a C/C++ and graphic programmer. I have a good
experience of OpenGL as well.
I was looking to contribute in OSGeo/Grass.

   - I have read the project ideas on:

https://trac.osgeo.org/grass/wiki/GSoC/2020
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] (no subject)

[Paulo van Breugel]

Hi Maris

Thanks, your suggestion made me realize that I did not recompiled the 
gdal-grass plugin (which was still pointing to a grass 7.5 version). 
Great, all working again.


Cheers,

Paulo


On 5/27/19 11:33 AM, Maris Nartiss wrote:

Hello,
usually it indicates on some remnants of previous version lying around
somewhere. Check out also for all extensions or your own custom
modules as they need to be rebuilt too.

Māris.

piektd., 2019. g. 24. maijs, plkst. 18:18 — lietotājs Paulo van
Breugel () rakstīja:

Hi devs

I just did a completely fresh install of grass 7.6.2. The whole compilation is 
completed without issues. But when starting grass up, I am getting the 
following message.

GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so: 
cannot open shared object file: No such file or directory
ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No such 
file or directory

I started completely anew, removed everything before compiling (as far as I 
know), including the .grass7 folder, so I wonder what else I could have done 
wrong? Any idea how I can find out where the problem lies?

Cheers,

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

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

Re: [GRASS-dev] (no subject)

[Maris Nartiss]

Hello,
usually it indicates on some remnants of previous version lying around
somewhere. Check out also for all extensions or your own custom
modules as they need to be rebuilt too.

Māris.

piektd., 2019. g. 24. maijs, plkst. 18:18 — lietotājs Paulo van
Breugel () rakstīja:
>
> Hi devs
>
> I just did a completely fresh install of grass 7.6.2. The whole compilation 
> is completed without issues. But when starting grass up, I am getting the 
> following message.
>
> GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so: 
> cannot open shared object file: No such file or directory
> ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No such 
> file or directory
>
> I started completely anew, removed everything before compiling (as far as I 
> know), including the .grass7 folder, so I wonder what else I could have done 
> wrong? Any idea how I can find out where the problem lies?
>
> Cheers,
>
> Paulo
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[Paulo van Breugel]

Hi devs

I just did a completely fresh install of grass 7.6.2. The whole compilation
is completed without issues. But when starting grass up, I am getting the
following message.

GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so:
cannot open shared object file: No such file or directory
ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No
such file or directory

I started completely anew, removed everything before compiling (as far as I
know), including the .grass7 folder, so I wonder what else I could have
done wrong? Any idea how I can find out where the problem lies?

Cheers,

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

Re: [GRASS-dev] (no subject)

[Anna Petrášová]

Hi Paulo,

my colleague who is the author of the extension is currently
traveling, so you might need to wait for the answer a bit. Let me know
if I can help with something else though.

Best,

Anna

On Sat, Dec 16, 2017 at 9:21 AM, Paulo van Breugel
 wrote:
>
> Hi Anna and other GRASS GIS devs,
>
> I am trying to build a tangible landscape system at our school. I got most
> things installed, but I got stuck at installing the
> tangible-landscape-immersive-extension.
>
> The question is where to find the "immersive_extention.blend" &
> "immersive_extention.py" files (mentioned in step 5 and 7 in the README
> file.
>
> There is already the issue
> 'https://github.com/tangible-landscape/tangible-landscape-immersive-extension/issues/3'
> filed in August, but with no reply yet, so I am hoping you can provide some
> guidance.
>
> Best wishes,
>
> Paulo
>
>
> --
>
> Paulo van Breugel, PhD
>
> Lecturer Geo Data Analyst
>
> Geomedia & Design
>
> Tel: +31 (0)88-890 3218
>
>
>
> HAS University of Applied Sciences
>
> Onderwijsboulevard 221
>
> 5223 DE ‘s-Hertogenbosch
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[Lorenzo Bottaccioli]

Hi everyone,

I have just compiled grass with phtreds but when I run r.mapcalc it runs in
only with one theard. How ca I fix this? Is it possible to check if is
correclty compiled with phtreads?
Before this I was using grass 7.0.0 r.mapcalc was ussing multithreading and
I had better performance.
Tnx
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Email subject standards

[Glynn Clements]

Vaclav Petras wrote:

 please note that changing subject when you reply an email breaks the email
 thread, so then there are two threads instead of one.

If the mail client uses the Subject header to identify threads, that's
a defect in the mail client.

What *does* break threading is using a mail client which doesn't set
the In-Reply-To or References headers when sending a reply.

For more details, see RFC 2822:

http://www.ietf.org/rfc/rfc2822.txt

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Email subject standards

[Vaclav Petras]

Hi Michael and others,

please note that changing subject when you reply an email breaks the email
thread, so then there are two threads instead of one.

Even adding some words to the subject line is usually considered as a
change, so it creates a new thread.

Keeping one topic with one subject is better because it works well with
Mozilla Thunderbird Conversations, Gmail conversations and most importantly
with Pipermail/Mailman archive [1]. It does help Gmane or Nabble too
(although Nabble seems to handle some cases).

Tickets also have the same name even when they are solved or there is some
progress. Moreover, they have number, so they are archived in the right way
even when the name was changed. But the only identifier for emails is the
subject, so we should keep it unless the topic changed.

If we all agree about it, we might consider writing some (short)
instructions somewhere.

Vaclav

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-October/thread.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Email subject standards

[Hamish]

Vaclav wrote:
 please note that changing subject when you reply an
 email breaks the email thread, so then there
 are two threads instead of one.

 Even adding some words to the subject line is
 usually considered as a change, so it
 creates a new thread.

Hi,

it depends on your software, many email clients and online archives know about 
 use email header lines to signify the relationships regardless of the subject 
line. Other email clients ignore all that and simply go by the strict subject 
line or their own fuzzy intelligence sorting method (eg gmail?).

see for example 

http://www.jwz.org/doc/threading.html

http://people.dsv.su.se/~jpalme/ietf/message-threading.html


regards,
Hamish

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

[GRASS-dev] (no subject)

[Vaclav Petras]

Hi,

in the ticket #1778 Glynn [1] says that:

it would be nice if we could train users to use that so that we can remove
the argv[1]==help check; although help isn't likely to be particularly
common as an option value, I dislike having special cases on principle

But in the manual pages, there is only a `help` and nothing about `--help`
(e.g. [2]). If the majority shares an opinion that `--help` is preferred
over `help` than we should change this in the manual pages generation.

I agree that `--help` is more standard but I use `help` because no shorter
option (such as -h or ?) is available.

Vaclav

[1] https://trac.osgeo.org/grass/ticket/1778#comment:26
[2] http://grass.osgeo.org/grass70/manuals/r.composite.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[张思阳]

Hi Eva, glad to see that we have the same research direction, and I'm very
excited an expected to cooperate with you.

On 04/24/2013 03:48 PM, anast...@centrum.sk wrote:

 Hi Corey, hi Ben,

 I am new at mailing list, but I deal with 3D kriging module for GRASS
 GIS as a PhD student for my dissertation thesis. The module enables
 to krige 2D and also 3D data (using 3D variogram), nowadays I
 continue testing and optimizing performance to make the module
 appropriate for publishing for other users.

 Best regards

 Eva Stopkova Bratislava, Slovak republic
 __**_ grass-dev mailing
 list grass-dev@lists.osgeo.org
 http://lists.osgeo.org/**mailman/listinfo/grass-devhttp://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] (no subject)

[Maris Nartiss]

Hello Ken,
--enable-64bit doesn't deal with GRASS 64bitness in direct way. What
You should had looking for was compiling 32bit apps on 64bit OS.

Regarding float overflow - it makes sense. Can You attach a patch to
trac ticket? I (or somebody else) will take a look at it and commit to
SVN.

Thanks for spotting this. Moving conversation to -dev.

Maris.

2010/6/16 Ken Kwasnicki ken.kwasni...@gmail.com:
 Yes, I my slackware can run 32bit apps. I tried recompiling grass without
 the --enable-64bit option but still had the same nviz problem , although i
 expect i'm still compiling to 64bit.

 However, I've looked at the togl_flythrough.c code and found the problem.
 Or at least found a change the fixes this on my system.

 I had added some debug output to mouse_valuator just to show the thisTime
 value, initially I just wanted to see if I would even see the output from a
 printf statement when running nviz.  What I noticed was that the seconds
 value for thisTime was not incrementing, only the decimal part was changing,
 which I guess is why the view would return to its original position after a
 1 second lapse.

 in the function this_time the time values are being cast to float which is
 maxing out so i changed them to double which is the return value anyway.
 so, i changed this line [320]:
 return ((float)tv.tv_sec + ((float)tv.tv_usec / 100.0));
 to:
 return ((double)tv.tv_sec + ((double)tv.tv_usec / 100.0));

 and that appears to have fixed the problem.  the same change may need to be
 made for the MINGW32 version of the code, but I left that alone.

 i've made this change in my download of the 6.4.0RC6 version of the code but
 for now I'll leave it up to you, or others to make this change as I'm
 currently not set up to submit code.

 thanks!
 ken


 On 06/15/2010 12:53 PM, Maris Nartiss wrote:

 Hello,
 at first - You can compile 32bit version on 64bit machine (if it's
 possible on Slackware).

 Second - once I took a look at code. It was not good, still I didn't
 managed to find the root cause.
 Fly mode is TCL/C hybrid.
 TCL part is here:
 http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/visualization/nviz/scripts
 (flythrough.tcl)
 Some support is located in nviz/src/ (togl_flythrough.c)
 Main rendering is done by OGSF lib/ogsf

 OGSF should be fine, problem is somewhere in nviz part. Probably in
 C/TCL interaction.

 Good luck.
 If You need some help with coding, feel free to as at grass-dev ML. We
 are short on resources and thys any help is wecomed.

 Maris.


 2010/6/15, Ken Kwasnicki ken.kwasni...@gmail.com:


 Hi Maris,
 Thanks for the reply!  Too bad. I guess I'll have to install on a 32bit
 system.  For what it's worth my system is Slackware 13.0 64bit and also
 Nvidia driver, so nothing really new to add to the bug report other than the
 variance in linux distribution.

 Any speculation where this bug might occur in the nviz code?  Just in case
 I'm feeling ambitious enough to take a crack at debugging it.

 Thanks,
 Ken


 On 06/15/2010 12:14 AM, Maris Nartiss wrote:


 Known issue, currently no fix.

 http://trac.osgeo.org/grass/ticket/46

 Maris.


 2010/6/14, Kwas ken.kwasni...@gmail.com:



 Helo,
 I've used NVIZ in the past and not had this problem but after rebuilding
 Grass/Nviz for a new system (Slackware 13 64bit)  I now find when I try
 to
 fly to move the landscape it keeps resetting back to its originall
 position after a few frames.ie: it will start to move in the
 direction
 of my mouse motion but then keeps jumping back so that I am unable to
 zoom
 in or position the view where I want.

 Has anybody seen this problem before or know what I should do to fix it?
 Appreciate any assistance.
 Thanks,
 Ken
 --
 View this message in context:
 http://osgeo-org.1803224.n2.nabble.com/NVIZ-help-fly-keeps-resetting-jumping-back-to-center-tp5178852p5178852.html
 Sent from the Grass - Users mailing list archive at Nabble.com.
 ___
 grass-user mailing list
 grass-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user







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

[GRASS-dev] (no subject)

[Mohammed Rashad]

 first of all sorry for this offtopic. I am sending mail to grass-dev ML 
because i can get good response from wxgui developers.
How can I use wxLayoutAlgorithm ?
--
Rashad



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

[GRASS-dev] (no subject)

[Helmut Kudrnovsky]

Dear GRASS-PSC,

together with Daniel McInerney I designed a GRASS Poster. We want to make it 
available to the GRASS community. It might be useful at conferences and fairs 
and maybe even translated into further languages. I was encouraged to store 
the English and German version thereof in the grass addons repository parallel 
to the grassflyer. 
cheers,
 robert

it would be nice to have a link on the start page http://grass.osgeo.org/ to 
the poster.

best regards
Helmut
___
WEB.DE DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://produkte.web.de/go/02/


smime.p7s
Description: S/MIME Cryptographic Signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[Andruit]

It seems that the files are not closed, but I use

if((elev_fd = G_open_cell_old (name, mapset))  0)
G_fatal_error( _(can't open %s), name);
   
if((output_fd = G_open_cell_new(outname))  0)
G_fatal_error( _(can't open outname %s), outname);

to open the files and

G_close_cell(output_fd);
G_close_cell(elev_fd);

to close the files again.

Is there anything wrong?

Andi

Glynn Clements wrote:
 [EMAIL PROTECTED] wrote:

 I am writing a Grass programm which creates a raster, reads the values
 of the raster map at certain points and creates a new rastermap having
 the same name as the old one.

 I am using the function

 G_open_cell_new()  to overwrite the existing raster map.

 and the function

  G_close_cell()


 It works fine.

 But after about 1000 loops I get the following messsage.

 WARNING: opencell opening temp null file: no temp files available

 Does anyone know what it means. I have enough space left in my ./tmp
 folder. And I also have write permissions on it.

 It probably means that files aren't getting closed, so you are
 exceeding the limit on the number of open files per process (by
 default 1024, check with ulimit -n).

 On Linux, you can check which files a process has open by looking in
 the /proc/pid/fd directory, where pid is the PID of the process.

 If you're modifying a map in-place, you'll need to close and re-open
 the input map in order to see the changes. Opening a map for write
 creates a temporary file, which is renamed over the original when
 closed. If the original cell/fcell file is still open for read at that
 point, it will still exist and still be open (it will show up as
 (deleted) in /proc/pid/fd).



-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] (no subject)

[benjamin . ducke]

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

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

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



Benjamin

[EMAIL PROTECTED] wrote:
 Hi Benjamin,

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

 Marco


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