I'd like to recommend a very minor change in the default behavior of data
format conversion modules (e.g., m.in.e00, v.in.mif, v.in.shape). Rather
than the current assumption that the data are stored in someone's desk
drawer or the back floor of their automobile (necessitating a full-qualified
path name for the input file), I'd like to see the pwd as the default
directory.
If folks don't have the input file in the pwd, then a FQPN is justified.
But, most of the time, I think we're working from the mapset and that would
save a lot of typing.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Rich Shepard wrote:
I'd like to recommend a very minor change in the default behavior of data
format conversion modules (e.g., m.in.e00, v.in.mif, v.in.shape). Rather
than the current assumption that the data are stored in someone's desk
drawer or the back floor of their automobile (necessitating a full-qualified
path name for the input file), I'd like to see the pwd as the default
directory.
If folks don't have the input file in the pwd, then a FQPN is justified.
But, most of the time, I think we're working from the mapset and that would
save a lot of typing.
Rich
OK. If the supplied pathname contains no `/' it is assumed to be current
directory (?), if it does, it's FQ'. That' easy to change if it's OK
with everyone. In fact it might be a good default behaviour for all
modules. I recall we recently had a discussion about the special
directories `arc', `dlg' and so on, and generally they were considered
to be of little value.
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Mar 27, 2001 at 07:21:39AM -0800, Rich Shepard wrote:
I'd like to recommend a very minor change in the default behavior of data
format conversion modules (e.g., m.in.e00, v.in.mif, v.in.shape). Rather
than the current assumption that the data are stored in someone's desk
drawer or the back floor of their automobile (necessitating a full-qualified
path name for the input file), I'd like to see the pwd as the default
directory.
If folks don't have the input file in the pwd, then a FQPN is justified.
But, most of the time, I think we're working from the mapset and that would
save a lot of typing.
Me no grok!
Do relative paths not work somehow? I actually often am in a different
directory than the current mapset, but for all GRASS data, I don't need
to care. Personally, I like to keep all my non-GRASS files outside of
the GRASS database directories. So, you would trade one convenience for
another? I think the common behavior that non-GRASS files need a
correct path to wherever they may live (or will live) is pretty much in
line with just about any other command line tool (and hence is
"intuitive"). Changing that behavior is likely to trip people up as
much as it might provide convenience.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Personally, I like to keep all my non-GRASS files outside of
the GRASS database directories.
I am not sure whether I understand this correctly but
I think that the preferable behavior is that if just a name of this
non-GRASS file is provided (e.g. in s.in.ascii, r.in.ascii etc.)
GRASS looks for it into the current directory, full path is
needed only if it is located in a different directory.
I too prefer to keep non-GRASS files outside GRASS database,
but this issue is irrelevant to where those files are.
So, you would trade one convenience for
another? I think the common behavior that non-GRASS files need a
correct path to wherever they may live (or will live) is pretty much in
line with just about any other command line tool (and hence is
"intuitive").
I think that what Rich suggests is in line with how most of grass commands
work (except for some vector imports which use confusing arc directory),
he just blurred the issue by suggesting that the pwd is mapset - which,
for example, for me is almost never the case.
So if I understand it correctly he just asks that e.g. m.in.e00 behaves like
r.in.ascii
or s.in.ascii. I hope I have it right.
Helena
Changing that behavior is likely to trip people up as
much as it might provide convenience.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 27 Mar 2001, Eric G. Miller wrote:
Me no grok!
Aspirin helps.
Do relative paths not work somehow? I actually often am in a different
directory than the current mapset, but for all GRASS data, I don't need
to care. Personally, I like to keep all my non-GRASS files outside of
the GRASS database directories.
That's a good point I hadn't considered. It's more a matter of personal
preference, and that's just fine. BUT, ... if the default is to remain the
same as now, the man pages need to be modified to explain how to specify the
input file name. I looked very carefully yesterday at m.in.e00 and
v.in.shape looking for an explanation of how to specify the input file, and
I found nothing.
My "intuition" and, perhaps, that of many new GRASS users, is the file
will be sought in the pwd if it's not important enough to mention in the
docs.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 27 Mar 2001, Helena wrote:
I am not sure whether I understand this correctly but I think that the
preferable behavior is that if just a name of this non-GRASS file is
provided (e.g. in s.in.ascii, r.in.ascii etc.) GRASS looks for it into the
current directory, full path is needed only if it is located in a
different directory. I too prefer to keep non-GRASS files outside GRASS
database, but this issue is irrelevant to where those files are.
Helena,
It is just the opposite. The full path is needed regardless of where the
data files are located. And this is not documented anywhere.
So if I understand it correctly he just asks that e.g. m.in.e00 behaves
like r.in.ascii or s.in.ascii. I hope I have it right.
Looks good to me.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Mar 27, 2001 at 10:18:14AM -0800, Rich Shepard wrote:
On Tue, 27 Mar 2001, Helena wrote:
> I am not sure whether I understand this correctly but I think that the
> preferable behavior is that if just a name of this non-GRASS file is
> provided (e.g. in s.in.ascii, r.in.ascii etc.) GRASS looks for it into the
> current directory, full path is needed only if it is located in a
> different directory. I too prefer to keep non-GRASS files outside GRASS
> database, but this issue is irrelevant to where those files are.
Helena,
It is just the opposite. The full path is needed regardless of where the
data files are located. And this is not documented anywhere.
Rich,
this point I don't get. I can easily import data from the local directory.
Say, I have
supermap.asc in $HOME.
Then I
cd $HOME
r.in.arc in=supermap.asc out=supermap
ready. Actually I can't see the problem (except that I don't like the
behaviour of v.in.dxf and v.in.arc which read from $LOCATION/arc and
$LOCATION/dxf).
> So if I understand it correctly he just asks that e.g. m.in.e00 behaves
> like r.in.ascii or s.in.ascii. I hope I have it right.
Looks good to me.
Maybe you could send the command copy-pasted so that we get your
problem?
Thanks in advance,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 27 Mar 2001, Markus Neteler wrote:
Maybe you could send the command copy-pasted so that we get your
problem?
As I went to do this, I realized the source of my problem: pwd wasn't the
project directory. It was the directory from within which I launched GRASS.
I do find this interesting, though.
If I launch GRASS from my home directory, but specify $GISDBASE, LOCATION,
and MAPSET as, for example, /mnt/usr4/projects/nevada/coeur/, when GRASS
starts, it has ~/ as the current directory rather than the mapset directory.
I guess I've not started GRASS from other than the project directory before.
And, without thinking about it yesterday and this morning, I assumed that
GRASS's default directory was in the mapset. I guess now that's only for
GRASS-generated files. Correct?
Thanks, Markus, for allowing me to see what happened. It's not what I
expected (based on the behaviors of other applications), but I can certainly
live with it now I'm aware of the differences.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Rich Shepard wrote:
On Tue, 27 Mar 2001, Helena wrote:
> I am not sure whether I understand this correctly but I think that the
> preferable behavior is that if just a name of this non-GRASS file is
> provided (e.g. in s.in.ascii, r.in.ascii etc.) GRASS looks for it into the
> current directory, full path is needed only if it is located in a
> different directory. I too prefer to keep non-GRASS files outside GRASS
> database, but this issue is irrelevant to where those files are.
Helena,
It is just the opposite. The full path is needed regardless of where the
data files are located. And this is not documented anywhere.
> So if I understand it correctly he just asks that e.g. m.in.e00 behaves
> like r.in.ascii or s.in.ascii. I hope I have it right.
Looks good to me.
Looks also good to me... in fact, this is how m.in.e00 was written :
the default location of the input file is "where you are" (i.e. pwd)
That's the default behaviour of the unix "open" function. You can also
use a relative path (input=foo/bar.e00) or an absolute path
(input=/tmp/bar.e00). I really don't understand what you want to
change in m.in.e00...
It's different for r.in.ascii or r.in.arc that use directories in
$LOCATION path, respectively $LOCATION/ascii and $LOCATION/arc.
BTW, you can use the same name for the binary and the ascii vector
file and both use $LOCATION/dig_att for the line's or area's attribute.
I think this was done because you need an ascii file for the import
or export of DXF files.
--
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Thu, Mar 29, 2001 at 09:24:40AM +0000, Michel Wurtz wrote:
Looks also good to me... in fact, this is how m.in.e00 was written :
the default location of the input file is "where you are" (i.e. pwd)
That's the default behaviour of the unix "open" function. You can also
use a relative path (input=foo/bar.e00) or an absolute path
(input=/tmp/bar.e00). I really don't understand what you want to
change in m.in.e00...
It's different for r.in.ascii or r.in.arc that use directories in
$LOCATION path, respectively $LOCATION/ascii and $LOCATION/arc.
BTW, you can use the same name for the binary and the ascii vector
file and both use $LOCATION/dig_att for the line's or area's attribute.
I think this was done because you need an ascii file for the import
or export of DXF files.
What about taking this chance and modifying the import modules to
all using the unix "open" function? This v.in.dxf/2 etc. behaviour
is quite inconvenient (and many users struggle here).
I don't see much sense in keeping this oldish method and ignoring
the unix "open" function.
Just my 0.02 Euro
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Markus Neteler wrote:
On Thu, Mar 29, 2001 at 09:24:40AM +0000, Michel Wurtz wrote:
> Looks also good to me... in fact, this is how m.in.e00 was written :
> the default location of the input file is "where you are" (i.e. pwd)
> That's the default behaviour of the unix "open" function. You can also
> use a relative path (input=foo/bar.e00) or an absolute path
> (input=/tmp/bar.e00). I really don't understand what you want to
> change in m.in.e00...
>
> It's different for r.in.ascii or r.in.arc that use directories in
> $LOCATION path, respectively $LOCATION/ascii and $LOCATION/arc.
> BTW, you can use the same name for the binary and the ascii vector
> file and both use $LOCATION/dig_att for the line's or area's attribute.
> I think this was done because you need an ascii file for the import
> or export of DXF files.
What about taking this chance and modifying the import modules to
all using the unix "open" function? This v.in.dxf/2 etc. behaviour
is quite inconvenient (and many users struggle here).
I don't see much sense in keeping this oldish method and ignoring
the unix "open" function.
In fact, i used fopen(), because it's more convenient (and probably
more effective) for reading/writing text data, but fopen() calls
open() and do some bufferisation as "extra". The code looks like :
fde00 = fopen (infile, "r");
if (fde00 == NULL)
{
sprintf (msg, "%s - not found\n", infile);
G_fatal_error (msg);
}
Where "infile" is the parameter given as "input=...". I think this
is the right way to do things...
By the way, what function (apart v.in.dxf and v.out.dxf) uses the ascii
vector format ? If they are alone, we can also change v.[in|out].ascii
in order to store the ident attribute of lines and polygons in the same
file...
This could also lead to a complete rewrite of v.[in|out].dxf, because
you must use the vector library for input/output on grass side.
Probably a good idea, but it will take some time I have not yet !
--
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Michel Wurtz wrote:
By the way, what function (apart v.in.dxf and v.out.dxf) uses the ascii
vector format ? If they are alone, we can also change v.[in|out].ascii
in order to store the ident attribute of lines and polygons in the same
file...
v.[in|out].ascii is already rewritten so that it can read/write category(ies)
from/to vector ascii (in grass51 repository)
This could also lead to a complete rewrite of v.[in|out].dxf, because
you must use the vector library for input/output on grass side.
Probably a good idea, but it will take some time I have not yet !
v.[in|out].dxf should be rewritten to work on binary vector and
merge v.in.dxf, v.in.dxf2 and v.in.dxf3d. I think that we should use
some dxf library (to support new dxf versions). Does anybody know about
some GPL dxf library in C? I have found only http://omega.sim.no/coin3d/dime_about.xml
which is C++.
All for grass51.
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Michel Wurtz wrote:
Markus Neteler wrote:
>
> On Thu, Mar 29, 2001 at 09:24:40AM +0000, Michel Wurtz wrote:
> > Looks also good to me... in fact, this is how m.in.e00 was written :
> > the default location of the input file is "where you are" (i.e. pwd)
> > That's the default behaviour of the unix "open" function. You can also
> > use a relative path (input=foo/bar.e00) or an absolute path
> > (input=/tmp/bar.e00). I really don't understand what you want to
> > change in m.in.e00...
> >
> > It's different for r.in.ascii or r.in.arc that use directories in
> > $LOCATION path, respectively $LOCATION/ascii and $LOCATION/arc.
> > BTW, you can use the same name for the binary and the ascii vector
> > file and both use $LOCATION/dig_att for the line's or area's attribute.
> > I think this was done because you need an ascii file for the import
> > or export of DXF files.
>
> What about taking this chance and modifying the import modules to
> all using the unix "open" function? This v.in.dxf/2 etc. behaviour
> is quite inconvenient (and many users struggle here).
> I don't see much sense in keeping this oldish method and ignoring
> the unix "open" function.
In fact, i used fopen(), because it's more convenient (and probably
more effective) for reading/writing text data, but fopen() calls
open() and do some bufferisation as "extra". The code looks like :
fde00 = fopen (infile, "r");
if (fde00 == NULL)
{
sprintf (msg, "%s - not found\n", infile);
G_fatal_error (msg);
}
Where "infile" is the parameter given as "input=...". I think this
is the right way to do things...
By the way, what function (apart v.in.dxf and v.out.dxf) uses the ascii
vector format ? If they are alone, we can also change v.[in|out].ascii
in order to store the ident attribute of lines and polygons in the same
file...
Michel
Work has already begun on changing the v.*.ascii spec. You can see code
and examples in the grass51 tree. The whole setup uses indexing to refer
to attributes (including if required ID), and will also be able to hold
multiple types of vector primitive.
This could also lead to a complete rewrite of v.[in|out].dxf, because
you must use the vector library for input/output on grass side.
Probably a good idea, but it will take some time I have not yet !
As a separate thread recently discussed, hopefully all vector import
will be merged into one module that will share as much functionality as
possible. For text based formats (apart maybe from native ones), it
might be a good idea to import data initially with a scanner utility -
possibly lex/yacc-based. That would make updating import easy without
having to alter core functionality significantly, and also be able to
more easily support multiple versions of the import format.
Of course, DXF is complex, and the problem would be the initial
investment in creating a lex/yacc pair for the initial import, which is
much more than for simple formats like Mapinfo MIF or ungen.
Regards
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Radim Blazek wrote:
Michel Wurtz wrote:
>
> By the way, what function (apart v.in.dxf and v.out.dxf) uses the ascii
> vector format ? If they are alone, we can also change v.[in|out].ascii
> in order to store the ident attribute of lines and polygons in the same
> file...
v.[in|out].ascii is already rewritten so that it can read/write category(ies)
from/to vector ascii (in grass51 repository)
> This could also lead to a complete rewrite of v.[in|out].dxf, because
> you must use the vector library for input/output on grass side.
> Probably a good idea, but it will take some time I have not yet !
v.[in|out].dxf should be rewritten to work on binary vector and
merge v.in.dxf, v.in.dxf2 and v.in.dxf3d. I think that we should use
some dxf library (to support new dxf versions). Does anybody know about
some GPL dxf library in C? I have found only http://omega.sim.no/coin3d/dime_about.xml
which is C++.
I agree that is the overall strategy. But if all the vector imports are
to employ the same calls, the DXF API would have to be compatible with
the intermediate structures created by the other imports. Maybe it is
still better to use lex/yacc - or maybe a regex API.
All for grass51.
Some work could be done earlier to get an import much as the others work
now (well, when they do . . ) for 5.0.1 for example. But not multicat
support or database support.
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Fri, Mar 30, 2001 at 03:21:03PM +0200, Radim Blazek wrote:
[...]
v.[in|out].dxf should be rewritten to work on binary vector and
merge v.in.dxf, v.in.dxf2 and v.in.dxf3d. I think that we should use
some dxf library (to support new dxf versions). Does anybody know about
some GPL dxf library in C? I have found only sim.no
which is C++.
All for grass51.
Hi Radim,
not very promising, but there is also:
o http://dxflib.sourceforge.net/ (however, C++)
o http://www.iserv.net/~strdream/jeff/programs/ (unsupported?)
o Maybe: OGR Simple Features Library (the server is currently unreachable)
Frank Warmerdam might write a C API once for it (not sure)
Sorry, not too much of help,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
David D Gray wrote:
Michel
Work has already begun on changing the v.*.ascii spec. You can see code
and examples in the grass51 tree. The whole setup uses indexing to refer
to attributes (including if required ID), and will also be able to hold
multiple types of vector primitive.
OK, thanks to you and Radim who pointed this to me (I didn't look recently
at the code and probably forget the mails anouncing that). but maybe I
must load the 5.1 tree (is there a different CVS tree than for 5.0 ?)
> This could also lead to a complete rewrite of v.[in|out].dxf, because
> you must use the vector library for input/output on grass side.
> Probably a good idea, but it will take some time I have not yet !
>
As a separate thread recently discussed, hopefully all vector import
will be merged into one module that will share as much functionality as
possible. For text based formats (apart maybe from native ones), it
might be a good idea to import data initially with a scanner utility -
possibly lex/yacc-based. That would make updating import easy without
having to alter core functionality significantly, and also be able to
more easily support multiple versions of the import format.
Well, this is probably tempting, but i prefer small and dedicated
programs (i don't like the M$ Office -- or even Staroffice -- approach).
They should of course use a scanner utility library, if possible as
a shared one.
Of course, DXF is complex, and the problem would be the initial
investment in creating a lex/yacc pair for the initial import, which is
much more than for simple formats like Mapinfo MIF or ungen.
or even e00, at least for the geometric part... I agree with you
--
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Michel,
On Fri, Mar 30, 2001 at 03:39:57PM +0000, Michel Wurtz wrote:
David D Gray wrote:
> Michel
>
> Work has already begun on changing the v.*.ascii spec. You can see code
> and examples in the grass51 tree. The whole setup uses indexing to refer
> to attributes (including if required ID), and will also be able to hold
> multiple types of vector primitive.
OK, thanks to you and Radim who pointed this to me (I didn't look recently
at the code and probably forget the mails anouncing that). but maybe I
must load the 5.1 tree (is there a different CVS tree than for 5.0 ?)
cvs -z3 co grass51
will get it for you.
Cheers
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'