Re: [GRASS-user] Character encoding problem

[Markus Neteler]

On Wed, Jan 21, 2009 at 4:55 AM, Glynn Clements
 wrote:
> I can't comment on GDAL/OGR issues, but the display library will
> accept data in any encoding recognised by iconv[1] when using FreeType
> fonts. You just need to specify the encoding via the charset= option.

[ ... of d.font ]

> [1] Provided that GRASS was built to use iconv(); this is
> autodetected. Otherwise, text is treated as ISO-8859-1.

Could we issue a warning in this case that iconv support is
missing? To give the user a hint?

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

[GRASS-user] Character encoding problem

[Jana Krajcovicova]

That's correct Glynn, I've just tested that. The trick is as simple as to
use *Truetype* font and set charset to the encoding used in the input vector
map (Apparently, my GRASS was not built to use iconv() :-)

Anyway, GRASS is so nice, thanks to all of you :-)

Jana



>
> I can't comment on GDAL/OGR issues, but the display library will
> accept data in any encoding recognised by iconv[1] when using FreeType
> fonts. You just need to specify the encoding via the charset= option.
>
> [1] Provided that GRASS was built to use iconv(); this is
> autodetected. Otherwise, text is treated as ISO-8859-1.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] interactive multiple selection

[Vincent Bain]

Hello,
considering a vector map, do you know a simple way to perform multiple
selections (e.g. highlighting a set of polygons) interactively either on
the display (tcltk or wxpython) or through a X monitor ? the aim in the
end is to update database records on the basis of a cat list.

I tried the addon v.digatt but I can't run it correctly (I think a
possible reason is my vector is linked to a pg db driver, and the module
was tested only with dbf driver).

Thank you,
Vincent.

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

Re: [GRASS-user] interactive multiple selection

[Markus Neteler]

On Wed, Jan 21, 2009 at 9:25 AM, Vincent Bain  wrote:
> Hello,
> considering a vector map, do you know a simple way to perform multiple
> selections (e.g. highlighting a set of polygons) interactively either on
> the display (tcltk or wxpython) or through a X monitor ? the aim in the
> end is to update database records on the basis of a cat list.
>
> I tried the addon v.digatt but I can't run it correctly (I think a
> possible reason is my vector is linked to a pg db driver, and the module
> was tested only with dbf driver).

Coudl this help?

d.extract help

Description:
 Selects and extracts vectors with mouse into new vector map.

It's not perfect but maybe a starter.

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

[GRASS-user] Listing subgroups and signature files

[Ned Horning]

All -

Is there a command to list signature files? I created a few signature 
files but I haven't figured out how to list them to see their file names 
in GRASS. The same goes for subgroups although I can see the subgroup 
names in the group directory (not via a GRASS command). Last week I'm 
pretty sure I listed the subgroups of a group in GRASS but I don't 
remember how I did it. I tried "i.group" with the various flags and 
"g.list group". I am using 6.3.0 but will soon try 6.4.0.ORC2.


Ned

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

[GRASS-user] Fwd: mosaicing classified images

[maning sambale]

Hi,
I am reposting this hoping for some answers.  Manually reclassifying
conflicting values seem to be a pain.  Any advice?



-- Forwarded message --
From: maning sambale 
Date: Wed, Jan 7, 2009 at 11:04 AM
Subject: mosaicing classified images
To: grass mailing list 


Hi,
I have a series of classified rasters from different landsat images
(various dates).  I want to moasic/stitch them to a one raster.  The
problem is there are subtle differences in the classified output. Any
advise in mosaicing them?

--
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Character encoding problem

[Jana Krajcovicova]

CORRECTION:
It is still desirable to change the character encoding directly in the .dbf
file after import.
Reason is that setting truetype and character encoding  using
d.font.freetype only affects display commands, but reading database (e.g.,
using db.select) is still scrambled.

Maybe there is an environmental variable in GRASS which can be used to
change the default UTF8 encoding? But I would say that it is better to use
OpenOffice to change .dbf file encoding in single cases.

Jana

On Wed, Jan 21, 2009 at 9:22 AM, Jana Krajcovicova  wrote:

>
>
>
> That's correct Glynn, I've just tested that. The trick is as simple as to
> use *Truetype* font and set charset to the encoding used in the input
> vector map (Apparently, my GRASS was not built to use iconv() :-)
>
> Anyway, GRASS is so nice, thanks to all of you :-)
>
> Jana
>
>
>
>>
>> I can't comment on GDAL/OGR issues, but the display library will
>> accept data in any encoding recognised by iconv[1] when using FreeType
>> fonts. You just need to specify the encoding via the charset= option.
>>
>> [1] Provided that GRASS was built to use iconv(); this is
>> autodetected. Otherwise, text is treated as ISO-8859-1.
>>
>> --
>> Glynn Clements 
>>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

R: Re: [GRASS-user] problems with v.edit

[chiaraerc...@tiscali.it]

> I have a problem with v-edit.
> I have to break a vector line
> 
into two parts near a point. I gave this command:
>
> v.edit 
map=ret_125
> layer=1 type=line tool=break thresh=$ris_edit 
coords=$x,$y snap=no
>
>
> where " $ris_edit "  depends on the 
resolution of the DEM raster map,
> "$x" and "$y" are the coordinates 
of the point.

are you sure that threshold value is enough to select 
vector feature
which you want to break?

v.edit map=ret_125 
tool=select  thresh=$ris_edit coords=$x,$y

?

Martin

-- 
Martin Landa 
 * http://gama.fsv.cvut.cz/~landa *





Hi 
all, 
the point is 6 meters far from the line and I used a threshold of 
100 meters.
Thanks you all,
 Chiara.



Attiva Tiscali Tutto Incluso: telefoni e navighi senza limiti A SOLI €10 AL 
MESE FINO ALL'ESTATE. Attiva entro il 22/01/09! 
http://abbonati.tiscali.it/promo/tuttoincluso/
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Character encoding problem

[Miha Staut]

The same holds true for hardcopy output command ps.map as far as I know. 
Correct me if I am wrong. Miha



--- On Wed, 21/1/09, Jana Krajcovicova  wrote:

> From: Jana Krajcovicova 
> Subject: Re: [GRASS-user] Character encoding problem
> To: grass-user@lists.osgeo.org
> Date: Wednesday, 21 January, 2009, 11:15 AM
> CORRECTION:
> It is still desirable to change the character encoding
> directly in the .dbf
> file after import.
> Reason is that setting truetype and character encoding 
> using
> d.font.freetype only affects display commands, but reading
> database (e.g.,
> using db.select) is still scrambled.
> 
> Maybe there is an environmental variable in GRASS which can
> be used to
> change the default UTF8 encoding? But I would say that it
> is better to use
> OpenOffice to change .dbf file encoding in single cases.
> 
> Jana
> 
> On Wed, Jan 21, 2009 at 9:22 AM, Jana Krajcovicova
>  wrote:
> 
> >
> >
> >
> > That's correct Glynn, I've just tested that.
> The trick is as simple as to
> > use *Truetype* font and set charset to the encoding
> used in the input
> > vector map (Apparently, my GRASS was not built to use
> iconv() :-)
> >
> > Anyway, GRASS is so nice, thanks to all of you :-)
> >
> > Jana
> >
> >
> >
> >>
> >> I can't comment on GDAL/OGR issues, but the
> display library will
> >> accept data in any encoding recognised by iconv[1]
> when using FreeType
> >> fonts. You just need to specify the encoding via
> the charset= option.
> >>
> >> [1] Provided that GRASS was built to use iconv();
> this is
> >> autodetected. Otherwise, text is treated as
> ISO-8859-1.
> >>
> >> --
> >> Glynn Clements 




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

Re: R: Re: [GRASS-user] problems with v.edit

[Martin Landa]

Hi,

2009/1/21 chiaraerc...@tiscali.it :
> v.edit map=ret_125
> tool=select  thresh=$ris_edit coords=$x,$y
> the point is 6 meters far from the line and I used a threshold of
> 100 meters.

so should I understand that result of tool=select no feature is found?
Can you send me sample data?

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] mosaicing classified images

[Markus Neteler]

On Wed, Jan 7, 2009 at 4:04 AM, maning sambale
 wrote:
> Hi,
> I have a series of classified rasters from different landsat images
> (various dates).  I want to moasic/stitch them to a one raster.  The
> problem is there are subtle differences in the classified output. Any
> advise in mosaicing them?

(I am afraid that it is easier to first mosaic (e.g., with OSSIM), then
 do the classification...)

You could vectorize the raster areas and then try some SQL
magic to match close polygons. Also v.clean to remove tiny
areas from the map if needed.

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

Re: [GRASS-user] interactive multiple selection

[Vincent Bain]

Thank you Markus,

I tried several methods like d.extract, or
d.where | v.what map=zonpi > test and extracting cat values from the
test file. Now I am wondering if it is worth (let's better say realistic
given my skills) to try and write a custom module, inspired from
v.digatt.

As I already had a little experience in perl and wxwidget (frontend for
data capture in postgres database) I would appreciate later on to
involve in writing a python add-on, but like everyone, my principal
ennemy is the lack of time !

Beside data storing, treatment, analysis, I think it would be great to
improve data *production* tools, and it's what I would like to
contribute.

Vincent.



Le mercredi 21 janvier 2009 à 09:32 +0100, Markus Neteler a écrit :
> On Wed, Jan 21, 2009 at 9:25 AM, Vincent Bain  wrote:
> > Hello,
> > considering a vector map, do you know a simple way to perform multiple
> > selections (e.g. highlighting a set of polygons) interactively either on
> > the display (tcltk or wxpython) or through a X monitor ? the aim in the
> > end is to update database records on the basis of a cat list.
> >
> > I tried the addon v.digatt but I can't run it correctly (I think a
> > possible reason is my vector is linked to a pg db driver, and the module
> > was tested only with dbf driver).
> 
> Coudl this help?
> 
> d.extract help
> 
> Description:
>  Selects and extracts vectors with mouse into new vector map.
> 
> It's not perfect but maybe a starter.
> 
> Markus
> 

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

[GRASS-user] wxGui - display labels on layer 2

[Paolo Craveri]

Hi to all.

in wxGui:

1)load a vector map with at least 2 layers ( table on layer 2 with
some values to display)
2)properties:
  Selection-->layer number, set to 2
  Optional:--> check shape and attr
  Labels-->Layer number set to 2
  Labels--> "set of column to be displayed": there are only
columns from table on layer 1; no possibility to write directly in
drop-down list the field name on layer 2.


Where I'm wrong?

ciao
-- 
-- 
Paolo C.
Lat. 44° 39' 11.08'' N  Long. 7° 23' 25.26'' E
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Character encoding problem

[Craig Leat]

Hi

Glynn wrote:
> I can't comment on GDAL/OGR issues, but the display library will
> accept data in any encoding recognised by iconv[1] when using FreeType
> fonts. You just need to specify the encoding via the charset= option.
>
> [1] Provided that GRASS was built to use iconv(); this is
> autodetected. Otherwise, text is treated as ISO-8859-1.

Jana wrote:
> That's correct Glynn, I've just tested that. The trick is as simple as to
> use *Truetype* font and set charset to the encoding used in the input vector
> map (Apparently, my GRASS was not built to use iconv() :-)

There is no reference to iconv in the grass configure options, so I
suspect that what Glynn means is that iconv is autodetected in the
build process. There's no autodetection of the encoding when it comes
to using d.font.

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

Re: [GRASS-user] Aspect direction in r.slope.aspect

[Doc Robinson]

Date: Tue, 20 Jan 2009 21:22:41 -0700 From: Michael Barton  
Subject: Re: [GRASS-user] Aspect direction in r.slope.aspect 

>To: grass-user@lists.osgeo.org

Jan 20, 2009, at 8:38 PM,  wrote:

> Date: Tue, 20 Jan 2009 14:05:41 -0800
> From: Dylan Beaudette 
> Subject: Re: [GRASS-dev] Re: [GRASS-user] Aspect direction in
>r.slope.aspect
> To: grass-...@lists.osgeo.org
> Cc: grass-user@lists.osgeo.org, Helena Mitasova
>
> Message-ID: <200901201405.41907.dylan.beaude...@gmail.com>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Tuesday 20 January 2009, Helena Mitasova wrote:

>> On Jan 20, 2009, at 3:16 PM, Markus Neteler wrote:

>>> Helena,
>>>
>>> I guess this is a question for you. If you post from
>>> hmit...@unity.ncsu.edu it
>>> reaches grass-user directly.
>>>
>>> Markus
>>>
>>> On Tue, Jan 20, 2009 at 8:39 PM, Moskovitz, Bob
>>>
>>>  wrote:

 Hello Grass Users,

 I was just wondering why aspect is measured from the east and
 increased
 counterclockwise instead of the north and clockwise?  It seems to  
 run

 counter to what is done in other GISs.

>>
>> at the time when it was implemented there was no other major raster
>> GIS (no Spatial Analyst, only
>> some research software and each used different rule, based on the
>> background
>> of the developer), so it was done to conform how the angles are
>> measured in math (east is your +x
>> and the values increase counterclockw).
>> I vaguely remember discussions on whether to change it to conform  
>> with

>> the "aspect as azimuth" concept with 0 pointing towards North but
>> there were already too many
>> people used to the way it was originally implemented that it was
>> safer to keep it.
>> (we had to make the decision for aspect in v.surf.rst as well and we
>> decided
>> to keep the math convention to make it consistent with  
>> r.slope.aspect).

>>
>> GRASS7 provides opportunity to change it and make sure that all
>> modules that compute and use
>> aspect or flow direction conform to the same rule. But it would be a
>> major undertaking that could
>> break a lot of scripts - I am not sure it is worth it and whether
>> anybody would actually be
>> willing to do it - it really depends on what your background is.
>> So if there are people who think this is really important and there
>> is some official standard that
>> says what it should be and there are some volunteers to actually work
>> on it, please post
>> to the grass-dev list,
>>
>> Helena

>
> Good topic for discussion. I think that GRASS7 should stick with the  
> current
> conventions to retain backwards compatibility. Since the reference  
> of the
> aspect calculation is clearly spelled out in the manual there should  
> be no
> problem- as long as people read the manual. Perhaps a careful check  
> of all of
> the manual pages associated with directional calculation should be  
> checked to

> make sure that there is a note.
>
> Cheers,
>
> Dylan


For my 2 cents worth, it seems to make a lot more sense for a  
*geographic* information system for all output to follow the same  
spatial organizational standards. I understand the history of the east  
is 0 convention for parts of GRASS. And I also appreciate the  
importance of not breaking code-dependent features within versions.  
However, that does not mean that we should keep a non-standard way of  
measuring direction for select modules (like r.slope.aspect), while  
measuring from north for others, simply because the program started  
out that way. Version changes are a time when we can rethink and  
standardize different modules that have evolved independently. Scripts  
are likely to break across the 6/7 transition for other reasons anyway.


That said, a functionally simple approach that would not be quite so  
disruptive would be to add a flag to switch to count from east mode  
(with count from north as the default) or even a flag to switch to  
count from north mode (with count from east being the default if  
backward compatibility is indeed very important in this case).


It is important to get an idea of how many things actually would need  
to be changed.


Michael




Here are my two cents on the topic as I have been using/teaching GRASS 
for more than a decade now.


1. I see no compelling reason to change r.slope.aspect. Actually I use 
it in my courses as a way to motivate students to read the manual and be 
aware of what their software is doing.
2. It is so simple to convert, it seems a waste of valuable time to 
change it. Having a simple flag for the option would be ok - users would 
still have to 'read the manual'. OR on the manual page just have simple 
example of how to convert it.
3. I have students write a simple script to that same thing. It is a 
useful exercise and quite a simple mind exercise.
4. What then about r.param.scale? Output is in the 0 +/- 180 range 
rather than 0-360. Will this also need changing? I have a similar 
comment on this. It is so simple t

Re: [GRASS-user] Aspect direction in r.slope.aspect

[Glynn Clements]

Michael Barton wrote:

>  I was just wondering why aspect is measured from the east and increased
>  counterclockwise instead of the north and clockwise?  It seems to run
>  counter to what is done in other GISs.

> For my 2 cents worth, it seems to make a lot more sense for a  
> *geographic* information system for all output to follow the same  
> spatial organizational standards. I understand the history of the east  
> is 0 convention for parts of GRASS. And I also appreciate the  
> importance of not breaking code-dependent features within versions.  
> However, that does not mean that we should keep a non-standard way of  
> measuring direction for select modules (like r.slope.aspect), while  
> measuring from north for others, simply because the program started  
> out that way. Version changes are a time when we can rethink and  
> standardize different modules that have evolved independently. Scripts  
> are likely to break across the 6/7 transition for other reasons anyway.
> 
> That said, a functionally simple approach that would not be quite so  
> disruptive would be to add a flag to switch to count from east mode  
> (with count from north as the default) or even a flag to switch to  
> count from north mode (with count from east being the default if  
> backward compatibility is indeed very important in this case).

I would suggest generalising it to scale and offset, so that you can
use degrees, grad, radians, etc. E.g.:

scale   offset  description
360 0   degrees CCW from east
-36090  degrees CW from north
2*pi0   radians CCW from east
-400100 grad CW from north

We also need a flag to indicate whether angles are signed or unsigned,
e.g. 0..360 vs -180..180. Off the top of my head:

struct angles {
double scale, offset;
int is_signed;
};

double G_import_angle(const struct angles *f, double a)
{
return (a - f->offset) * (2*M_PI) / f->scale;
}

double G_export_angle(const struct angles *f, double a)
{
a = f->offset + a * f->scale / (2*M_PI);
return a - f->scale * floor(a / f->scale + f->is_signed ? 0.5 : 
0);
}

We would also want a function to set the conversion parameters from a
string, so that common cases can be named (e.g. "deg,geo" for
degrees/CW/north, "rad,math" for radians CW from east).

Then, modules such as r.slope.aspect would get an angles= parameter,
with the existing interpretation as the default.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Character encoding problem

[Glynn Clements]

[CC to grass-dev]

Jana Krajcovicova wrote:

> It is still desirable to change the character encoding directly in the .dbf
> file after import.
> Reason is that setting truetype and character encoding  using
> d.font.freetype only affects display commands, but reading database (e.g.,
> using db.select) is still scrambled.
> 
> Maybe there is an environmental variable in GRASS which can be used to
> change the default UTF8 encoding? But I would say that it is better to use
> OpenOffice to change .dbf file encoding in single cases.

There is a GRASS variable, GRASS_DB_ENCODING. However, it appears that
only the form library (used to display attribute information via
Tcl/Tk) actually uses this variable.

Modules which read text from databases and pass the text to the
R_text() should use R_encoding() to set the encoding accordingly. GUI
code should do something similar (the wx GUI reads this from
os.environ, although it's actually a GRASS variable).

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aspect direction in r.slope.aspect

[Michael Barton]

On Jan 21, 2009, at 7:26 AM, Glynn Clements wrote:



Michael Barton wrote:

I was just wondering why aspect is measured from the east and  
increased
counterclockwise instead of the north and clockwise?  It seems  
to run

counter to what is done in other GISs.



For my 2 cents worth, it seems to make a lot more sense for a
*geographic* information system for all output to follow the same
spatial organizational standards. I understand the history of the  
east

is 0 convention for parts of GRASS. And I also appreciate the
importance of not breaking code-dependent features within versions.
However, that does not mean that we should keep a non-standard way of
measuring direction for select modules (like r.slope.aspect), while
measuring from north for others, simply because the program started
out that way. Version changes are a time when we can rethink and
standardize different modules that have evolved independently.  
Scripts
are likely to break across the 6/7 transition for other reasons  
anyway.


That said, a functionally simple approach that would not be quite so
disruptive would be to add a flag to switch to count from east mode
(with count from north as the default) or even a flag to switch to
count from north mode (with count from east being the default if
backward compatibility is indeed very important in this case).


I would suggest generalising it to scale and offset, so that you can
use degrees, grad, radians, etc. E.g.:

scale   offset  description
360 0   degrees CCW from east
-36090  degrees CW from north
2*pi0   radians CCW from east
-400100 grad CW from north

We also need a flag to indicate whether angles are signed or unsigned,
e.g. 0..360 vs -180..180. Off the top of my head:

struct angles {
double scale, offset;
int is_signed;
};

double G_import_angle(const struct angles *f, double a)
{
return (a - f->offset) * (2*M_PI) / f->scale;
}

double G_export_angle(const struct angles *f, double a)
{
a = f->offset + a * f->scale / (2*M_PI);
return a - f->scale * floor(a / f->scale + f->is_signed ? 0.5 : 
0);
}

We would also want a function to set the conversion parameters from a
string, so that common cases can be named (e.g. "deg,geo" for
degrees/CW/north, "rad,math" for radians CW from east).

Then, modules such as r.slope.aspect would get an angles= parameter,
with the existing interpretation as the default.

--
Glynn Clements 


Great ideas!

Michael

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

Re: [GRASS-user] Character encoding problem

[Glynn Clements]

Markus Neteler wrote:

> > [1] Provided that GRASS was built to use iconv(); this is
> > autodetected. Otherwise, text is treated as ISO-8859-1.
> 
> Could we issue a warning in this case that iconv support is
> missing? To give the user a hint?

Under what circumstances? We probably don't want to issue a warning if
the encoding isn't being set explicitly by the user, or if the
encoding is set to ISO-8859-1 or US-ASCII (and a string comparison
won't handle aliases).

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Character encoding problem

[Glynn Clements]

Miha Staut wrote:

> The same holds true for hardcopy output command ps.map as far as I
> know. Correct me if I am wrong. Miha

ps.map requires that text uses ISO-8859-1; whenever you select a font,
it creates an ISO-8859-1 version of the font (if it doesn't already
exist) and uses that.

PostScript only has two named encoding vectors for text:
StandardEncoding and ISOLatin1Encoding. StandardEncoding is only used
by PostScript; you are unlikely to have any text in that format.

Using other encodings in PostScript requires defining the encoding
vector, and it requires the PostScript implementation to have suitable
fonts. And using a non-unibyte encoding is quite complex.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] FOSSGIS 2009 - program finished - registration open

[Marco Lechner - FOSSGIS e.V.]

sorry for crossposting:
The following is the official "Call for registration" announcement for
the german speaking FOSSGIS conference (NOT FOSS4G !!!), which will take
place in Hannover, 17.-19. of March 2009. The FOSSGIS is the annual
conference of the FOSSGIS e.V. who represents the germanlanguage local
chapter D-A-CH of OSGeo. Sorry for german language
only but everybody is invited to join the conference.
Get more details on the conference wiki: http://www.fossgis.de/konferenz/

--
Sehr geehrte Damen und Herren,

vom 17. bis 19. März 2009 präsentiert sich die Open Source GIS Branche
in Hannover auf der FOSSGIS 2009, der größten deutschsprachigen
Anwenderkonferenz für Freie Geo-Informationssysteme und Freie Geodaten.
Veranstalter ist der FOSSGIS e.V. (http://www.fossgis.de), der im
deutschen Sprachraum die Vertretung der OSGeo Foundation
(http://www.osgeo.org) darstellt.

Das Vortragsprogramm für die FOSSGIS-Konferenz wurde nun vom
Organisationsteam bekannt gegeben. Alle Interessierten sind herzlich
eingeladen, sich für die Konferenz, die Workshops und die
vielversprechende Abendveranstaltung anzumelden.

http://www.fossgis.de/konferenz

Es werden zahlreiche Vorträge aus dem technischen und nicht-technischen
Bereich präsentiert. Die Vielzahl von Anwenderberichten wendet sich
gleichermaßen an Entscheider, Anwender und Entwickler. Das
Themenspektrum reicht dabei von Geoprozessierung und Linux-Migrationen
im GIS-Umfeld über kommunale GDI, Metadaten und INSPIRE sowie Freien
Geodaten bis zu Cloud Computing und anwendungspezifischen Vorträgen aus
Forschung, Lehre und Praxis.

Im Mittelpunkt der Workshops stehen die Software-Projekte UMN MapServer,
gvSIG, GRASS GIS, OpenLayers, Quantum GIS, GDAL, PostGIS, GeoServer und
thematische Workshops die aktuelle Themen wie Metadaten, Sicherheit von
Webdiensten, Geodateninfarstrukturen, die Nutzung von ALKIS-Daten,
INSPIRE, die OGC-Dienste WMS, WFS und WFS-T sowie Web Processing Dienste
praktisch vermitteln. Damit zeigt sich ein Trend von
anwendungsspezifischen zu problemorientierten Themen auch im
Workshopbereich.

http://www.fossgis.de/konferenz/wiki/Workshops_2009

Die Teilnahmegebühr der Workshops beträgt 100,- € pro Person und
Workshop. Die Einnahmen der Workshops gehen wie auch die Jahre zuvor
vollständig in die Finanzierung der Konferenz ein.

Am Rande der Konferenz werden auch wieder zahlreiche Entwickler- und
Anwendertreffen sowie Code-Sprints einiger Open Source Projekte
stattfinden. Diese bieten die Möglichkeit die Entwicklung der
Anwendungen kennen zu lernen und direkten Kontakt zu den Entwicklern der
Projekte zu bekommen.

Gelegenheit zur Vertiefung von Inhalten und der Präsentation von
Lösungen bieten sich einerseits im Rahmen der Firmenausstellung, die
parallel zu den Vorträgen und Workshops stattfindet und zum anderen in
gemütlicher Runde bei der Abendveranstaltung am 17. März.

Interessenten können sich auf der Webseite der FOSSGIS 2009 informieren
und für den Besuch der Anwenderkonferenz anmelden. Der Eintritt ist
kostenfrei, eine Registrierung ist allerdings bis zum 25. Februar
notwendig, da wieder über 500 Teilnehmende erwartet werden.

Weitere Informationen unter: http://www.fossgis.de/konferenz


Mit freundlichen Grüßen,

i.A. des Organisationsteam der FOSSGIS 2009

Marco Lechner





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

[GRASS-user] connect points to end points via v.net

[Christopher Mire]

Hello, I have a problem that I am considering doing some manual coding for,
but thought I would check here for easier way first.  I'm new to grass, so
there
are still alot of things I don't know.

Basically I have this huge vector map which
is mostly connected.  Problem is that there are a bunch of intersections of
lines
that dont actually connected together, due to way data was put together.
Instead I
have another vector map which is just a bunch of points.  Usually these
points all
correspond to one of these disconnected intersections.  What I want to do is
connect each point to all of the unconnected end points within some
threshold
distance.  My plan is to use v.net.path on network, but I need to have it
all
connected so this is why I am doing this.  I know there is v.net, but this
connects points to a line, where as I only want to connected points to the
end points of a line, or even connecting to line, but only if endpoint of
line is
within threshold.

I was thinking about modifying v.net to have option on what to connect to,
to
specify option to only connect to endpoints instead of anywhere on line.
Does
this sound reasonable, or is there way to get this behavior another way?

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

Re: [GRASS-user] connect points to end points via v.net

[Moritz Lennert]

On 21/01/09 16:33, Christopher Mire wrote:

Hello, I have a problem that I am considering doing some manual coding for,
but thought I would check here for easier way first.  I'm new to grass, 
so there

are still alot of things I don't know.

Basically I have this huge vector map which
is mostly connected.  Problem is that there are a bunch of intersections 
of lines
that dont actually connected together, due to way data was put 
together.  Instead I
have another vector map which is just a bunch of points.  Usually these 
points all

correspond to one of these disconnected intersections.  What I want to do is
connect each point to all of the unconnected end points within some 
threshold
distance.  My plan is to use v.net.path on network, but I need to have 
it all
connected so this is why I am doing this.  I know there is v.net 
, but this

connects points to a line, where as I only want to connected points to the
end points of a line, or even connecting to line, but only if endpoint 
of line is

within threshold.

I was thinking about modifying v.net  to have option on 
what to connect to, to
specify option to only connect to endpoints instead of anywhere on 
line.  Does

this sound reasonable, or is there way to get this behavior another way?


Not sure I understand exactly what you want to do, but I have the 
feeling that v.edit should help you do the job.


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

Re: [GRASS-user] connect points to end points via v.net

[Christopher Mire]

On Thu, Jan 22, 2009 at 10:00 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 21/01/09 16:33, Christopher Mire wrote:
>
>> Hello, I have a problem that I am considering doing some manual coding
>> for,
>> but thought I would check here for easier way first.  I'm new to grass, so
>> there
>> are still alot of things I don't know.
>>
>> Basically I have this huge vector map which
>> is mostly connected.  Problem is that there are a bunch of intersections
>> of lines
>> that dont actually connected together, due to way data was put together.
>>  Instead I
>> have another vector map which is just a bunch of points.  Usually these
>> points all
>> correspond to one of these disconnected intersections.  What I want to do
>> is
>> connect each point to all of the unconnected end points within some
>> threshold
>> distance.  My plan is to use v.net.path on network, but I need to have it
>> all
>> connected so this is why I am doing this.  I know there is v.net <
>> http://v.net>, but this
>> connects points to a line, where as I only want to connected points to the
>> end points of a line, or even connecting to line, but only if endpoint of
>> line is
>> within threshold.
>>
>> I was thinking about modifying v.net  to have option on
>> what to connect to, to
>> specify option to only connect to endpoints instead of anywhere on line.
>>  Does
>> this sound reasonable, or is there way to get this behavior another way?
>>
>
> Not sure I understand exactly what you want to do, but I have the feeling
> that v.edit should help you do the job.
>
> Moritz
>

Hmm, basically there are a bunch connected lines in this vector map.  In
certain regions of this map
the lines don't actually intersect, but just really close to each other.
Luckily I happen to have ,roughly,
the coordinate of each of these intersections where the points don't
actually touch.  What I want to do
is use this coordinate to connect all the close endpoints to it, therefore
completing the connections in
graph so I am able to traverse with other GRASS modules.  By endpoints, I
mean I don't want to
connect the point to the closest line, but rather the closest endpoint of a
line, if within threshold.  This
is because there might be lines passing through intersection which I don't
want to connect to, but
rather only the lines which end there.

I had tried v.edit snap tool, but I ended up just merging lines together,
which I don't want.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aspect direction in r.slope.aspect

[Dylan Beaudette]

On Wednesday 21 January 2009, Glynn Clements wrote:
> Michael Barton wrote:
> >  I was just wondering why aspect is measured from the east and
> >  increased counterclockwise instead of the north and clockwise?  It
> >  seems to run counter to what is done in other GISs.
> >
> > For my 2 cents worth, it seems to make a lot more sense for a
> > *geographic* information system for all output to follow the same
> > spatial organizational standards. I understand the history of the east
> > is 0 convention for parts of GRASS. And I also appreciate the
> > importance of not breaking code-dependent features within versions.
> > However, that does not mean that we should keep a non-standard way of
> > measuring direction for select modules (like r.slope.aspect), while
> > measuring from north for others, simply because the program started
> > out that way. Version changes are a time when we can rethink and
> > standardize different modules that have evolved independently. Scripts
> > are likely to break across the 6/7 transition for other reasons anyway.
> >
> > That said, a functionally simple approach that would not be quite so
> > disruptive would be to add a flag to switch to count from east mode
> > (with count from north as the default) or even a flag to switch to
> > count from north mode (with count from east being the default if
> > backward compatibility is indeed very important in this case).
>
> I would suggest generalising it to scale and offset, so that you can
> use degrees, grad, radians, etc. E.g.:
>
>   scale   offset  description
>   360 0   degrees CCW from east
>   -36090  degrees CW from north
>   2*pi0   radians CCW from east
>   -400100 grad CW from north
>
> We also need a flag to indicate whether angles are signed or unsigned,
> e.g. 0..360 vs -180..180. Off the top of my head:
>
>   struct angles {
>   double scale, offset;
>   int is_signed;
>   };
>
>   double G_import_angle(const struct angles *f, double a)
>   {
>   return (a - f->offset) * (2*M_PI) / f->scale;
>   }
>
>   double G_export_angle(const struct angles *f, double a)
>   {
>   a = f->offset + a * f->scale / (2*M_PI);
>   return a - f->scale * floor(a / f->scale + f->is_signed ? 0.5 : 
> 0);
>   }
>
> We would also want a function to set the conversion parameters from a
> string, so that common cases can be named (e.g. "deg,geo" for
> degrees/CW/north, "rad,math" for radians CW from east).
>
> Then, modules such as r.slope.aspect would get an angles= parameter,
> with the existing interpretation as the default.

If it wouldn't be too hard to implement, this seems like a nice generalized 
solution. I had forgotten about the output from r.param.scale...

Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: grass-user Digest, Vol 33, Issue 39

[Moritz Lennert]

Richard,

(almost missed you question because of the digest subject line...)

On 20/01/09 05:10, Richard Chirgwin wrote:
I think that a GRASS module for connecting lines between chosen points 
is a definite yes (think of point coordinates of airports with 
information about flight connections between airports). Up to now I've 
been doing it with a simple script + v.in.ascii.
  

I think a module would be wonderful, since I've struggled with this task
a few times. Would it be rude to ask about your script, Moritz?


Now that Martin has implemented it in v.net, this is probably mostly 
hypothetical, but I just used very simple awk magic to massage point 
ascii data into lines. I.e. from an ascii file in the format of


StartX,StartY,EndX,EndY,LineCat

this command line creates the GRASS lines map:

awk -F"," 'BEGIN{i=0} {i++;print "L 2 1";print $1,$2,i;i++;print
$3,$4,i;print "1", $5 }' YourFile | v.in.ascii -n format=standard
out=YourMapName fs=" "

How to get to the input ascii file depends on your data setup, but I 
would use something like this (assuming you use a real db, have one map 
with points of which you would like to connect some and that you have a 
table called Connections in your db in the form of StartCat, EndCat, Value):


v.addcol PointMap col="x double precision"
v.addcol PointMap col="y double precision"
v.to.db PointMap option=coor

Then, some SQL to add StartX,StartY,EndX,EndY to your table Connections.

Then update your Connections table with something like:

UPDATE Connections SET StartX = PointMap.x, StartY=PointMap.y FROM PointMap
  WHERE StartCat=PointMap.cat

UPDATE Connections SET EndX = PointMap.x, EndY=PointMap.y FROM PointMap
  WHERE EndCat=PointMap.cat

And then extract the relevant values in an ascii file which you can then 
feed into the above awk line.


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

Re: [GRASS-user] interactive multiple selection

[Michael Barton]

On Jan 21, 2009, at 7:27 AM,  wrote:


Date: Wed, 21 Jan 2009 12:21:57 +0100
From: Vincent Bain 
Subject: Re: [GRASS-user] interactive multiple selection
To: GRASS user list 
Message-ID: <1232536917.12409.37.ca...@vincent-desktop>
Content-Type: text/plain; charset=UTF-8

Thank you Markus,

I tried several methods like d.extract, or
d.where | v.what map=zonpi > test and extracting cat values from the
test file. Now I am wondering if it is worth (let's better say  
realistic

given my skills) to try and write a custom module, inspired from
v.digatt.

As I already had a little experience in perl and wxwidget (frontend  
for

data capture in postgres database) I would appreciate later on to
involve in writing a python add-on, but like everyone, my principal
ennemy is the lack of time !

Beside data storing, treatment, analysis, I think it would be great to
improve data *production* tools, and it's what I would like to
contribute.

Vincent.


Vincent,

Very much related to this, please see my suggestions for updates to  
the GRASS query functions. Most should be relatively minor changes,  
but would make querying much easier. And it would make it easier to  
implement GUI wrappers for interactive querying.


 "Updates to  
vector querying "


Thanks much for your interest.

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

Re: [GRASS-user] interactive multiple selection

[Vincent Bain]

> Very much related to this, please see my suggestions for updates to  
> the GRASS query functions. Most should be relatively minor changes,  
> but would make querying much easier. And it would make it easier to  
> implement GUI wrappers for interactive querying.
> 
>  "Updates to  
> vector querying "

OK, good perspective !

Concerning the GUI wrapping of commands such as v.what or v.select,
will it imply the ability to query directly within the display window ?

Vincent.

> 
> Thanks much for your interest.

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

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

RE: [GRASS-user] Aspect direction in r.slope.aspect

[Moskovitz, Bob]

Thank you for the tip.  Btw, I was made aware of this "problem" when a coworker 
took our landslide hazard workflow and tried to apply it to grass.  Everything 
look great, but when we took another look at the various layers, we were 
shocked to see how aspect was defined.  I know...we should have read the 
manuals, but everybody knows how aspect is defined.  Anyways, we can live with 
another step in our process, but it would be great if there was a document that 
shows the differences between GIS systems (such as ESRI, MapInfo, etc), so that 
we can keep surprises at a minimum. :-)

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the 
individual or entity to which it is addressed. This message contains 
information from the State of California, California Geological Survey, which 
may be privileged, confidential and exempt from disclosure under applicable 
law, including the Electronic Communications Privacy Act. If the reader of this 
communication is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited.



> -Original Message-
> From: Hamish [mailto:hamis...@yahoo.com]
> Sent: Tuesday, January 20, 2009 12:50 PM
> To: Grass-User (E-mail); Moskovitz, Bob
> Subject: Re: [GRASS-user] Aspect direction in r.slope.aspect
> 
> 
> Bob Moskovitz wrote:
> > I was just wondering why aspect is measured from the east
> > and increased counterclockwise instead of the north and
> > clockwise?  It seems to run counter to what is done in other
> > GISs.
> 
> 
> It is just measuring theta positive from the x-axis, in the 
> mathematical
> sense.
> 
> It stays like that for historical reasons, probably been that 
> way for 20+
> years. (aka we can only guess at the original logic)
> 
> Convert between that and the compass (CW from north) convention with
> "90 - angle". Most modules which deal with aspect maps should already
> have an option to read the different type.
> 
> 
> Hamish
> 
> 
> 
>   
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Aspect direction in r.slope.aspect

[Moskovitz, Bob]

Sounds like a great idea!  If sometrhing like this can be done, we would have 
one less reason to shy away from FOSS.

> 
> For my 2 cents worth, it seems to make a lot more sense for a  
> *geographic* information system for all output to follow the same  
> spatial organizational standards. I understand the history of 
> the east  
> is 0 convention for parts of GRASS. And I also appreciate the  
> importance of not breaking code-dependent features within versions.  
> However, that does not mean that we should keep a 
> non-standard way of  
> measuring direction for select modules (like r.slope.aspect), while  
> measuring from north for others, simply because the program started  
> out that way. Version changes are a time when we can rethink and  
> standardize different modules that have evolved 
> independently. Scripts  
> are likely to break across the 6/7 transition for other 
> reasons anyway.
> 
> That said, a functionally simple approach that would not be quite so  
> disruptive would be to add a flag to switch to count from east mode  
> (with count from north as the default) or even a flag to switch to  
> count from north mode (with count from east being the default if  
> backward compatibility is indeed very important in this case).
> 
> It is important to get an idea of how many things actually 
> would need  
> to be changed.
> 
> Michael
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wxGui - display labels on layer 2

[Martin Landa]

Hi,

2009/1/21 Paolo Craveri :
> 1)load a vector map with at least 2 layers ( table on layer 2 with
> some values to display)
> 2)properties:
>  Selection-->layer number, set to 2
>  Optional:--> check shape and attr
>  Labels-->Layer number set to 2
>  Labels--> "set of column to be displayed": there are only
> columns from table on layer 1; no possibility to write directly in
> drop-down list the field name on layer 2.

fixed in r35533. Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] wxGUI, display

[Paolo Craveri]

Hi to all,

in wxGUI, Layer Manager, I've just tried these actions:

1) load some vector maps and set properties
2) save workspace as gxw file;
3) start new display (Display 2)
4) in Layer Manager, Display 2, try to load workspace saved previously
5) display 2 … vanish

It would be very useful to have the chance to copy layers from one
display to another, avoiding repetitive tasks of setting properties.

Many many thanks to all developers, from an enthusiastic end-user.

ciao

-- 
-- 
Paolo C.
Lat. 44° 39' 11.08'' N  Long. 7° 23' 25.26'' E
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] DBMI-DBF driver error

[Matt]

I'm still trying to understand why I can't get dbf related commds to
work in the Windows version running under Vista.  If I run the
database test from the GUI (Databases > Manage database > Test
database), I get reams of errors starting with:

 db.test test=test1

 create table grass_test1 (i1 integer, d1 double precision, c1 varchar(20))
 DBMI-DBF driver error:
 Cannot create dbf database: '$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'



 Unable to open database <'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'>

 EXECUTE:  ERROR 
 insert into grass_test1 values ( 1, 123.456, 'abcd' )
 DBMI-DBF driver error:
 Cannot create dbf database: '$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'



 Unable to open database <'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'>

 EXECUTE:  ERROR 
 insert into grass_test1 values ( 2, null, 'xxx' )
 DBMI-DBF driver error:
 Cannot create dbf database: '$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'

And so on.


Taking another approach, I tried using the GRASS plugins in QGIS.  In
QGIS I can display the roadsmajor map from the North Carolina dataset
(see details at beginning of this thread).  Using the QGis "Open
Table" icon I can open and move around the dbf file.  However, the
"Start editing" button is greyed out and does not work. So, the file
exists.  I'm running with administrator privileges.

Is anyone successfully working with dbf with Grass 6.3 under Vista?

On Mon, Jan 19, 2009 at 7:17 PM, Matt  wrote:
> You are correct.  'river.dbf' is a typo.  I did a cut and past, but
> the first character of the first line in the "Output - GIS.m" window
> always appears a couple of line up and to the right of the printer and
> "X" icons: it should have read "driver:dbf".
>
> The directory  'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf'
> does exist.
> This is probably grasping as straws, but could the difference between
> forward slash and back slash be important?  If I open a Windows
> Command Prompt window (a DOS window) and type
> cd C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
> I go to the correct directory.  If I then type dir in the Command
> Prompt window, I see the directory listing.
> BUT  if I am back at the root directory (c:\) and type
> dir C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
> I get an error message.  Repeating with the back slash gives the
> correct result in both cases.  For shorter examples "dir c:\" works,
> but "dir c:/" does not work (invalid switch).  Depending how GRASS and
> Windows interact, might this be a problem?
>
>
> On Mon, Jan 19, 2009 at 4:49 PM, Markus Neteler  wrote:
>> Matt,
>>
>> On Sat, Jan 17, 2009 at 7:21 PM, Matt  wrote:
>>> I have a problem working through the DBF driver example on pp 174-175
>>> of Neteler & Mitasova with the North Carolina dataset.  I''m running
>>> version 6.3.0-4 under Windows Vista.  The first two commands execute
>>> without any obvious errors when run from the bottom window of "GIS.m".
>>>  But the third command has problems.
>>>
>>> db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
>>> db.connect -p
>>> g.copy vect=roadsmajor,myroadsmajor
>>>
>>> Output from db.connect -p is
>>> river:dbf
>>
>> ("river" this is just a typo, no?)
>>
>>> database:'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf
>>> schema:
>>> group:
>>>
>>> Output from g.copy vect=roadsmajor,myroadsmajor is
>>> g.copy vect=roadsmajor,myroadsmajor
>>>
>>> Copy vector  to current mapset as 
>>> DBMI-DBF driver error:
>>> Cannot create dbf database:
>>> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
>>
>> Does the directory exist?
>> If no, can you create it manually?
>>
>> Markus
>>
>>> Cannot open database
>>> ''C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf'
>>> no database is open
>>>
>>> Unable to copy table 
>>>
>>> Cannot copy  to current mapset as 
>>>
>>> I've checked and the file
>>> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/roadsmajor.dbf'
>>> does indeed exist.  What am I doing wrong?
>>>
>>> Thanks in advance.
>>> Matt
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Aspect direction in r.slope.aspect

[Hamish]

Dylan:
> Good topic for discussion. I think that GRASS7 should stick with the
> current conventions 

I agree,  (in spite of my mapping background being from the navigation
end of things)


> to retain backwards compatibility.

most importantly-> backwards compatibility with existing maps, this is
not just about updating scripts.


Dylan:
> Since the reference of the aspect calculation is clearly spelled out
> in the manual there should be no problem- as long as people read the
> manual. Perhaps a careful check of all of the manual pages associated
> with directional calculation should be checked to make sure that there
> is a note.

by the way, what is a good name for the "CCW from +x" style? currently
we call it "grass" but surely there is a more self-explanatory name for
it.

related: "v.in.ascii format=standard" (yet not the default) is not clear.


Michael:
> However, that does not mean that we should keep a non-standard way of
> measuring direction

CCW from +x is in no way non-standard. It is just a different (equally
valid*) standard.   *(depending on your background/POV)

> for select modules (like r.slope.aspect), while measuring from north
> for others,

currently AFAIK there is:
r.slope.aspect, v.surf.rst:   degrees CCW from east

r.param.scale:0 is west, +/-180 is east, +90 north, -90 south
"Direction of maximum gradient (steepest slope
 direction=flow direction)"

Nothing AFAIK currently outputs aspect as CW from north, although
d.rast.arrow accepts type=grass,compass,agnps,answers. (AGNPS is
multiples of 15 deg, and ANSWERS is D8)  I'm not sure if modules for working 
with the AGNPS & ANSWERS models are still active in GRASS6.

see also the aspect color rules.


> Scripts are likely to break across the 6/7 transition for other reasons
> anyway.

again, more important than scripts is existing data. New data should have
meta-data added to it specifying which conventions it uses. Old data
doesn't have that and it is hard to guess which it was, so the analysis
subtly gives you bad results without warning. +evil.

At minimum I think we should add a short "(degrees CCW from east)" note
to all option->descriptions which create aspect maps and ensure that
text is written in the raster output units/title/hist metadata structures
upon creation.

r.slope.aspect's r.info title and cats/ file (d.what.rast) goes to
great lengths to explain what the cell is.  r.param.scale does not.


> [...] add a flag to switch to count from east mode [...] or even a flag
> to switch to count from north mode

IMO that is a classic recipe for confusion and mayhem. It violates the
philosophy of creating strict output but reading sloppy input. It is
better to settle on a single way, document it well, and provide an
example of how to convert to something else if the user prefers.


Doc Robinson:
> 4. What then about r.param.scale? Output is in the 0 +/- 180 range
> rather than 0-360.

A similar issue there is meteorological vs. nautical conventions for flow
direction: southerly wind flows towards the north, southerly water flow
flow towards the south.  How do the groundwater flow people call it?
Also there is the convention that "north facing" is geo-centric.
Add to this radians vs degrees and true north vs magnetic and the result
is that you just have to be sure to document things really well so someone
from a different background doesn't make the wrong assumptions.

I suppose in a non-legacy world you could say that degrees are always
CW from north, and radians are always CCW from the +x axis, and not worry
about grads. but oh well.


Bob:
> Everything look great, but when we took another look at the various
> layers, we were shocked to see how aspect was defined.  I know...we
> should have read the manuals, but everybody knows how aspect is defined.

... for some values of "everybody". The way you expect to see it is
simply based on your background.


> it would be great if there was a document that shows the differences
> between GIS systems (such as ESRI, MapInfo, etc), so that we can keep
> surprises at a minimum. :-)

please help improve:
  http://grass.osgeo.org/wiki/GRASS_Help#Migration_from_other_GIS_Software



I am not fundamentally opposed to changing the default GRASS way to be CW
from north in GRASS 7 if there is strong consensus to change it, but I am
rather opposed to offering multiple ways.


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

Re: [GRASS-user] interactive multiple selection

[Michael Barton]

On Jan 21, 2009, at 11:05 PM,   
wrote:



Date: Wed, 21 Jan 2009 18:45:40 +0100
From: Vincent Bain 
Subject: Re: [GRASS-user] interactive multiple selection
To: GRASS user list 
Message-ID: <1232559940.6769.10.ca...@vincent-desktop>
Content-Type: text/plain


Very much related to this, please see my suggestions for updates to
the GRASS query functions. Most should be relatively minor changes,
but would make querying much easier. And it would make it easier to
implement GUI wrappers for interactive querying.

 "Updates to
vector querying "


OK, good perspective !

Concerning the GUI wrapping of commands such as v.what or v.select,
will it imply the ability to query directly within the display  
window ?


Yes. That's the idea. Martin Landa already has tried to implement this  
to some extent in the new wxPython GUI. But it involves a lot of  
workarounds for inadequacies in the GRASS vector querying. These  
updates to querying modules would make this easier and more robust.


Michael 
___

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

Re: [GRASS-user] interactive multiple selection

[Vincent Bain]

> Yes. That's the idea. Martin Landa already has tried to implement this  
> to some extent in the new wxPython GUI. But it involves a lot of  
> workarounds for inadequacies in the GRASS vector querying. These  
> updates to querying modules would make this easier and more robust.
> 
> Michael 

Nice,

Thank you all for that huge amount of work !

Vincent.

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

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