[GRASS-windows] Re: grass-windows Digest, Vol 26, Issue 1

[Zahid Parvez]

I got some problem in v.in.ogr command.
There may be some problem locating shape file location.
I don't know why

On 10/1/08, [hidden email]
<[hidden email]> wrote:

> Send grass-windows mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osgeo.org/mailman/listinfo/grass-windows
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-windows digest..."
>
>
> Today's Topics:
>
>    1. Re: r.report, r.patch (Helena Mitasova)
>    2. Re: r.report, r.patch (Glynn Clements)
>    3. Re: r.report, r.patch (Markus Neteler)
>    4. ESRI shape files import (Zahid Parvez)
>    5. Re: r.report, r.patch (Helena Mitasova)
>    6. Re: r.report, r.patch (Glynn Clements)
>    7. Re: Re[2]: [GRASS-windows] GRASS MSYS Console problems
>       (Marco Pasetti)
>    8. Re: r.report, r.patch (Marco Pasetti)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Sep 2008 10:45:17 -0400
> From: Helena Mitasova <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: Moritz Lennert <[hidden email]>
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Sep 30, 2008, at 10:03 AM, Moritz Lennert wrote:
>
>> On 30/09/08 15:42, Helena Mitasova wrote:
>>> 2. r.patch does not work for one student on VISTA-
>>> it is exactly the same problem reported as bug #118 but
>>> according to bug tracker it was fixed and closed
>>> http://trac.osgeo.org/grass/ticket/118
>>> The command works for me and others on XP. Is there anybody else
>>> who still has this problem? Michael did your students get it working?
>>
>> Did you follow Marco's advice of disabling UAC ?
>
> I looked at it and as this is not my computer I would be hesitant to
> have
> the student ask to disable it on her laptop.
> Everything else is working well for her.
>
> After reading about UAC troubles that people have I would say go back
> to XP or you have to deal with it. But this would explain why r.patch
> works
> for some people and not for others.
>
> thanks a lot for the hint,
>
> Helena
>>
>>> 6. When using GUI - what is the simplest way to draw a legend next
>>> to the
>>> image? When using d.mon I just stretch the window to create some
>>> white space
>>> and draw the legend there - fast and simple. When I try to do that
>>> using GUI
>>> the legend is always written into the image. Am I missing something?
>>
>>
>> http://lists.osgeo.org/pipermail/grass-user/2008-September/046703.html
>>
>> Moritz
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Sep 2008 23:06:01 +0100
> From: Glynn Clements <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: Helena Mitasova <[hidden email]>
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
>
> Helena Mitasova wrote:
>
>> 1. r.report does not work for two students (one has VISTA one has XP)
>> it does not print anything - it works for me
>> and others - has anybody had a similar problem?
>
> Maybe a problem with writing temporary files?
>
> This (amongst other things[1]) will fail if there are spaces in
> $GISDBASE. r.report constructs and executes (with system()) an r.stats
> command which redirects to a temporary file, and the temporary
> filename isn't quoted.
>
> I've worked around the issue in 7.0 with r33627, which quotes the
> filename.
>
> More generally, we need to start eradicating the use of system() in
> favour of e.g. G_spawn_ex(). Apart from anything else, this means that
> someone needs to do a proper port to Windows using CreateProcess().
>
> [There's currently a half-baked Windows version based around
> spawnvpe(), but it doesn't handle redirection. Redirecting to a named
> file could be fudged with spawnvpe(), but not redirecting to an open
> handle.]
>
> FWIW, I count 41 occurrences of [G_]system and [G_]popen in 7.0.
>
> [1] In the process of converting the scripts to Python, I've noticed
> that the output from "v.db.connect -g" isn't suitable for its intended
> purpose, as it uses spaces to separate the fields, even though one of
> the fields is typically a filename.
>
>> 2. r.patch does not work for one student on VISTA-
>> it is exactly the same problem reported as bug #118 but
>> according to bug tracker it was fixed and closed
>> http://trac.osgeo.org/grass/ticket/118
>> The command works for me and others on XP. Is there anybody else
>> who still has this problem? Michael did your students get it working?
>
> I think that Windows users will ultimately need to ensure GISDBASE is
> within their "Documents" directory. But that will require fixing the
> myriad spaces-in-pathnames issues such as the above.
>
> If any non-Windows users want to help out, Unix doesn't prohibit the
> use of spaces in pathnames, so you can put a space in the name of the
> GISDBASE directory and report any errors you encounter.
>
> --
> Glynn Clements <[hidden email]>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 1 Oct 2008 00:13:31 +0200
> From: "Markus Neteler" <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: "Glynn Clements" <[hidden email]>
> Cc: Helena Mitasova <[hidden email]>,
> [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Oct 1, 2008 at 12:06 AM, Glynn Clements
> <[hidden email]> wrote:
> ...
>> This (amongst other things[1]) will fail if there are spaces in
>> $GISDBASE. r.report constructs and executes (with system()) an r.stats
>> command which redirects to a temporary file, and the temporary
>> filename isn't quoted.
>>
>> I've worked around the issue in 7.0 with r33627, which quotes the
>> filename.
>
> Backported to 6.4. with r33629.
>
> ...
>> If any non-Windows users want to help out, Unix doesn't prohibit the
>> use of spaces in pathnames, so you can put a space in the name of the
>> GISDBASE directory and report any errors you encounter.
>
> I did so for several weeks while intensively using it but didn't come
> across many problems. I'll guess I'll change again my "grassdata/"
> to "grass data/" to see what happens.
>
> Markus
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 1 Oct 2008 06:22:19 +0600
> From: "Zahid Parvez" <[hidden email]>
> Subject: [GRASS-windows] ESRI shape files import
> To: [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I am new in Grass GIS. I am learning Windows native GRASS 6.3 .
>
> I will be very grateful if any one could tell me in brief how i could
> import SHAPE files into
> GRASS and convert it into GRASS data.
>
>
> Sincerely
>
> Md. Zahid Parvez
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 30 Sep 2008 20:34:33 -0400
> From: Helena Mitasova <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: Glynn Clements <[hidden email]>
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Sep 30, 2008, at 6:06 PM, Glynn Clements wrote:
>
>>
>> Helena Mitasova wrote:
>>
>>> 1. r.report does not work for two students (one has VISTA one has XP)
>>> it does not print anything - it works for me
>>> and others - has anybody had a similar problem?
>>
>> Maybe a problem with writing temporary files?
>>
>> This (amongst other things[1]) will fail if there are spaces in
>> $GISDBASE. r.report constructs and executes (with system()) an r.stats
>> command which redirects to a temporary file, and the temporary
>> filename isn't quoted.
>
> The installer puts the sample data locations into a directory with a
> space[1]
> in its name so that may be it. For the lab computers I have moved the
> data into
> a directory that does not have space in its name but the students
> that have
> problems might have kept it in the original directory - I will check
> for that.
>
> [1]The sample data files will be installed into a directory called
> GIS DataBase,
> that will be created in your Documents folder
>
>>
>> I've worked around the issue in 7.0 with r33627, which quotes the
>> filename.
>>
>> More generally, we need to start eradicating the use of system() in
>> favour of e.g. G_spawn_ex(). Apart from anything else, this means that
>> someone needs to do a proper port to Windows using CreateProcess().
>>
>> [There's currently a half-baked Windows version based around
>> spawnvpe(), but it doesn't handle redirection. Redirecting to a named
>> file could be fudged with spawnvpe(), but not redirecting to an open
>> handle.]
>>
>> FWIW, I count 41 occurrences of [G_]system and [G_]popen in 7.0.
>>
>> [1] In the process of converting the scripts to Python, I've noticed
>> that the output from "v.db.connect -g" isn't suitable for its intended
>> purpose, as it uses spaces to separate the fields, even though one of
>> the fields is typically a filename.
>>
>>> 2. r.patch does not work for one student on VISTA-
>>> it is exactly the same problem reported as bug #118 but
>>> according to bug tracker it was fixed and closed
>>> http://trac.osgeo.org/grass/ticket/118
>>> The command works for me and others on XP. Is there anybody else
>>> who still has this problem? Michael did your students get it working?
>>
>> I think that Windows users will ultimately need to ensure GISDBASE is
>> within their "Documents" directory. But that will require fixing the
>> myriad spaces-in-pathnames issues such as the above.
>
> at least the sample data get installed there, but the GISDBASE directory
> name has a space. We are going quite systematically through GRASS,
> mostly raster, some vector commands and this is what we had so far.
> I will report whatever else we find.
>
> thanks a lot
>
> Helena
>
>>
>> If any non-Windows users want to help out, Unix doesn't prohibit the
>> use of spaces in pathnames, so you can put a space in the name of the
>> GISDBASE directory and report any errors you encounter.
>>
>> --
>> Glynn Clements <[hidden email]>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 1 Oct 2008 03:03:51 +0100
> From: Glynn Clements <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: Helena Mitasova <[hidden email]>
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
>
> Helena Mitasova wrote:
>
>> >> 1. r.report does not work for two students (one has VISTA one has XP)
>> >> it does not print anything - it works for me
>> >> and others - has anybody had a similar problem?
>> >
>> > Maybe a problem with writing temporary files?
>> >
>> > This (amongst other things[1]) will fail if there are spaces in
>> > $GISDBASE. r.report constructs and executes (with system()) an r.stats
>> > command which redirects to a temporary file, and the temporary
>> > filename isn't quoted.
>>
>> The installer puts the sample data locations into a directory with a
>> space[1]
>> in its name so that may be it. For the lab computers I have moved the
>> data into
>> a directory that does not have space in its name but the students
>> that have
>> problems might have kept it in the original directory - I will check
>> for that.
>>
>> [1]The sample data files will be installed into a directory called
>> GIS DataBase,
>> that will be created in your Documents folder
>
> Well, the Documents folder itself normally contains spaces in English
> installations, e.g.: "C:\Documents and Settings\<user>\My Documents".
>
> You can often get around this using 8.3 filenames, e.g.
> "c:\docume~1\<user>\mydocu~1\", but it sometimes falls down (e.g.
> getcwd() returns the "official" version).
>
> --
> Glynn Clements <[hidden email]>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 1 Oct 2008 08:38:00 +0200
> From: "Marco Pasetti" <[hidden email]>
> Subject: Re: Re[2]: [GRASS-windows] GRASS MSYS Console problems
> To: "Maxim Dubinin" <[hidden email]>
> Cc: [hidden email]
> Message-ID: <3A1355B41C214DD59D0FDE8A8FB237FB@HPMarco>
> Content-Type: text/plain; format=flowed; charset="koi8-r";
> reply-type=original
>
> Hi Maxim,
>
>> Unfortunately we were unable to run grass63 -text using your solution.
>> Still
>> getting the message: Redirection is not supported. I wrote "we"
>> because at least 3 other people confirmed the same behavior.
>>
>> This is what I did:
>> 1. Moved grass63 from GRASS\msys\home\C\Documents and Settings\USERNAME\
>> to GRASS\msys\home\USERNAME
>> 2. Removed .grassrc6 from GRASS\msys\home\C\Documents and
>> Settings\USERNAME\
>> 3. Removed .grassrc6 from C:\Documents and Settings\USERNAME\
>> 4. Ran GRASS MSYS Console
>> 5. Entered grass63 -text
>
> Ops... I get the same problem too.... and I don't know why. Unfortunately at
> the moment I'm too busy to investigate on that.
> Please, keep in mind that, if you need to run bourne shell commands or
> self-made scripts through a unix-like environment, you can launch the GRASS
> MSYS console and lauch GRASS (simply type grass63 and enter); once entered a
> GRASS session, selecting the location and mapset using the GUI, you can
> always run line commands using the (still active) MSYS session.
> The second option (recently preferred by the development community, and me
> too) is to run line commands using the native GRASS command line (DOS, cmd).
>
> Regards,
>
> Marco
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 1 Oct 2008 08:59:47 +0200
> From: "Marco Pasetti" <[hidden email]>
> Subject: Re: [GRASS-windows] r.report, r.patch
> To: "Helena Mitasova" <[hidden email]>,
> <[hidden email]>
> Message-ID: <E5CC4C4FFFC04D7A955E04C44122EAF1@HPMarco>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=response
>
> Hi Helena,
>
>>I have few issues from our class that I would like to ask about winGRASS
>
> First thing: thanks a lot for your feedbacks, I really appreciate your help,
> specially because comes from a high-professional GRASS user ;)
> Unfortunaltely I'm very busy in these months (yesterday I passed the first
> PhD entry test), so I cannot partecipate to the project as much I would...
> but the next months will be better...
>
>> 1. r.report does not work for two students (one has VISTA one has XP)
>> it does not print anything - it works for me
>> and others - has anybody had a similar problem?
>
> No, it's working for me
>
>> 2. r.patch does not work for one student on VISTA-
>> it is exactly the same problem reported as bug #118 but
>> according to bug tracker it was fixed and closed
>> http://trac.osgeo.org/grass/ticket/118
>> The command works for me and others on XP. Is there anybody else
>> who still has this problem? Michael did your students get it working?
>
> As it has been already discussed, I'm still convinced that for Vista it's
> due to the UAC's presence. About XP, I don't know, r.patch works on my old
> XP machine.
>
>> 3. copy and paste to cmd section of output window makes it copy it twice
>> - shift insert works- I have this problem too - is this a feature?
>
> Confirm. I don't know why.
>
>> 4. first one or two letters in output are sometimes skipped  - e.g. min
>> is n for r.univar and there are some others. Not a big deal but it is
>> somewhat confusing
>
> Yes. I already opened a ticket. It should be fixed in 6.4 trunk, but I don't
> have time to check it out (I should rebuild gdal libs, because I built them
> with GRASS 6.3.0 support for QGIS, and at the moment I need the maximum
> calculus power from my notebook... building on MinGW takes a lot of
> resoruces and time....)
>
> Well... about the differences within different machines running the same OS,
> I cannot tell you what could be the problem. Both XP and Vista are very
> delicate OS, specially XP (because more hackable from users and 3rd party
> applications); lacking or conflicting DLLs, wrong or unusual registry
> setting, anti-viruses or firewall applications may cause unexpected
> problems.
> The key should be, in this case, analyze the differences between a working
> setup and the failing ones, and try to identify what may cause the failure.
> It's not a really "scientific" way (it would be nice for a doctor, but not
> for an engineer...), but sometimes it's the smartest way to hit the target.
>
> Thank you very much for your care on the WinGRASS Project,
>
> Marco
>
>
>
> ------------------------------
>
> _______________________________________________
> grass-windows mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-windows
>
>
> End of grass-windows Digest, Vol 26, Issue 1
> ********************************************
>

_______________________________________________
grass-windows mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-windows