I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
d.vect.area. Also, there's the matter of v.area. Do people use it?
What does it provide that d.what.vect doesn't do (besides the flood
fill, which doesn't handle islands)?
I'm considering writing a vector line module similar to d.vect.area, only
it'd be for drawing labelled lines in different colors via a similar
legend file (yea? nay? don't care?).
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
d.vect.area.
If d.area is to be removed, it would be useful to either:
a) make d.vect.area more backward-compatible, e.g. by changing the
"color=" option to "fillcolor=" and supporting the "catnum=" option
(the -f flag is a fairly recent addition, so that's less important),
or
b) implement d.area as a script which calls d.vect.area.
Scripts tend to have the disadvantage that errors from G_parser()
don't make much sense unless the user is familiar with the script
(although g.parser may help here).
--
Glynn Clements <glynn.clements@virgin.net>
On Mon, Feb 04, 2002 at 05:59:34PM -0800, Eric G. Miller wrote:
I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
d.vect.area. Also, there's the matter of v.area. Do people use it?
What does it provide that d.what.vect doesn't do (besides the flood
fill, which doesn't handle islands)?
Yes, please go ahead... But: the d.vect.cats is the upcoming
d.vect. Before you delete I will migrate d.vect.cats to d.vect 
Any objections?
I'm considering writing a vector line module similar to d.vect.area, only
it'd be for drawing labelled lines in different colors via a similar
legend file (yea? nay? don't care?).
Probably you want to look at d.vect of GRASS 5.1. It's already done...
(kudos to Radim).
Best
Markus
On Tue, 5 Feb 2002 07:12:47 +0000, Glynn Clements <glynn.clements@virgin.net> wrote:
Eric G. Miller wrote:
> I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
> d.vect.area.If d.area is to be removed, it would be useful to either:
a) make d.vect.area more backward-compatible, e.g. by changing the
"color=" option to "fillcolor=" and supporting the "catnum=" option
(the -f flag is a fairly recent addition, so that's less important),
or
I suppose I could work in the catnum option to go with the constant
color options. I used "color" rather than "fillcolor" to make the
arguments closer to d.vect, but I don't have real strong feelings
one way or the other.
b) implement d.area as a script which calls d.vect.area.
Scripts tend to have the disadvantage that errors from G_parser()
don't make much sense unless the user is familiar with the script
(although g.parser may help here).
I prefer to avoid shell scripts...
--
Eric G. Miller <egm2@jps.net>
On Tue, 5 Feb 2002 11:09:36 +0100, Markus Neteler <neteler@itc.it> wrote:
On Mon, Feb 04, 2002 at 05:59:34PM -0800, Eric G. Miller wrote:
> I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
> d.vect.area. Also, there's the matter of v.area. Do people use it?
> What does it provide that d.what.vect doesn't do (besides the flood
> fill, which doesn't handle islands)?Yes, please go ahead... But: the d.vect.cats is the upcoming
d.vect. Before you delete I will migrate d.vect.cats to d.vect
Any objections?
Oh, okay.
> I'm considering writing a vector line module similar to d.vect.area, only
> it'd be for drawing labelled lines in different colors via a similar
> legend file (yea? nay? don't care?).Probably you want to look at d.vect of GRASS 5.1. It's already done...
(kudos to Radim).
I've already got a version (just modified d.vect.area a little). Would like
to have something like this in 5.0...
--
Eric G. Miller <egm2@jps.net>
On Tue, Feb 05, 2002 at 07:57:28AM -0800, Eric G. Miller wrote:
On Tue, 5 Feb 2002 11:09:36 +0100, Markus Neteler <neteler@itc.it> wrote:
> On Mon, Feb 04, 2002 at 05:59:34PM -0800, Eric G. Miller wrote:
> > I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
> > d.vect.area. Also, there's the matter of v.area. Do people use it?
> > What does it provide that d.what.vect doesn't do (besides the flood
> > fill, which doesn't handle islands)?
>
> Yes, please go ahead... But: the d.vect.cats is the upcoming
> d.vect. Before you delete I will migrate d.vect.cats to d.vect
> Any objections?Oh, okay.
So.. done. d.vect.cats is now d.vect.
Cheers
Markus
On Tue, 5 Feb 2002 17:47:43 +0100, Markus Neteler <neteler@itc.it> wrote:
On Tue, Feb 05, 2002 at 07:57:28AM -0800, Eric G. Miller wrote:
> On Tue, 5 Feb 2002 11:09:36 +0100, Markus Neteler <neteler@itc.it> wrote:
>
> > On Mon, Feb 04, 2002 at 05:59:34PM -0800, Eric G. Miller wrote:
> > > I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
> > > d.vect.area. Also, there's the matter of v.area. Do people use it?
> > > What does it provide that d.what.vect doesn't do (besides the flood
> > > fill, which doesn't handle islands)?
> >
> > Yes, please go ahead... But: the d.vect.cats is the upcoming
> > d.vect. Before you delete I will migrate d.vect.cats to d.vect
> > Any objections?
>
> Oh, okay.So.. done. d.vect.cats is now d.vect.
Markus, do you realize d.vect.cats does not handle islands/holes correctly?
Compare: http://pweb.jps.net/~egm2/d.vect.cats.jpg vs.
http://pweb.jps.net/~egm2/d.vect.area.jpg -- note: I drew the line work
a second time for d.vect (because the interiors got clobbered).
It should be relatively easy to remedy via G_plot_area().
--
Eric G. Miller <egm2@jps.net>
On Tue, Feb 05, 2002 at 09:29:46PM -0800, Eric G. Miller wrote:
On Tue, 5 Feb 2002 17:47:43 +0100, Markus Neteler <neteler@itc.it> wrote:
> On Tue, Feb 05, 2002 at 07:57:28AM -0800, Eric G. Miller wrote:
> > On Tue, 5 Feb 2002 11:09:36 +0100, Markus Neteler <neteler@itc.it> wrote:
> >
> > > On Mon, Feb 04, 2002 at 05:59:34PM -0800, Eric G. Miller wrote:
> > > > I would like to deprecate d.area (and possibly d.vect.cats ?) in favor of
> > > > d.vect.area. Also, there's the matter of v.area. Do people use it?
> > > > What does it provide that d.what.vect doesn't do (besides the flood
> > > > fill, which doesn't handle islands)?
> > >
> > > Yes, please go ahead... But: the d.vect.cats is the upcoming
> > > d.vect. Before you delete I will migrate d.vect.cats to d.vect
> > > Any objections?
> >
> > Oh, okay.
>
> So.. done. d.vect.cats is now d.vect.Markus, do you realize d.vect.cats does not handle islands/holes correctly?
Oh - actually not. However, my only intention was to merge two similar
modules. The island problem is the next step.
Compare: http://pweb.jps.net/~egm2/d.vect.cats.jpg vs.
http://pweb.jps.net/~egm2/d.vect.area.jpg -- note: I drew the line work
a second time for d.vect (because the interiors got clobbered).It should be relatively easy to remedy via G_plot_area().
May I pass this to you? Maybe you want to merge/replace again
with your new d.vect.line?
Ideally there is only one vector drawing tool in future, we already
have too many (similar) modules.
Thanks for pointing out the problem,
Markus
On Wed, 6 Feb 2002 07:40:53 +0100, Markus Neteler <neteler@itc.it> wrote:
[snip]
> Markus, do you realize d.vect.cats does not handle islands/holes correctly?
Oh - actually not. However, my only intention was to merge two similar
modules. The island problem is the next step.> Compare: http://pweb.jps.net/~egm2/d.vect.cats.jpg vs.
> http://pweb.jps.net/~egm2/d.vect.area.jpg -- note: I drew the line work
> a second time for d.vect (because the interiors got clobbered).
>
> It should be relatively easy to remedy via G_plot_area().
May I pass this to you? Maybe you want to merge/replace again
with your new d.vect.line?
I can have a look, but here's my thinking about the different vector drawing
modules. When I was putting together d.vect.area, I was thinking about
fixing/replacing the half functional d.area. At the time, d.vect just
drew all line work. That's fine. Where d.vect.area steps in, is to do
more fine grained filled area drawing. I knew long ago that d.vect.cats
didn't handle islands/holes correctly and that was the motivation for
originally adding the category selectivity to d.area (and now d.vect.area).
The d.vect.line plays an analogous role to d.vect.area, in that it draws
labelled vector lines in various colors (unfortunately, there's not much
to do about line styles at the present). Both d.vect.line and d.vect.area
are limited to labelled things. That is, things that definitely represent
something. With the ability to have both significant line features and
significant areal features, there's a need to distinguish what is being
dealt with. One other significant difference, is both of the new d.vect.*
modules will not even consider drawing a vector unless it can be opened
at level 2, whereas d.vect did/does draw spagetti. Both possibilities
are important.
Now, if we want d.vect to be the one stop vector drawing module, it needs
a way to disambiguate what type of thing it should be interested in (areas,
lines, points?). This is where some infrastructure for drawing styles
needs to be implemented. My thinking was to have a usable middle solution
until we can address these issues in 5.1 (I'm thinking, better display/drawing
capabilities, new vector format, and infrastructure for managing or generating
drawing styles on the fly via attributes).
Ideally there is only one vector drawing tool in future, we already
have too many (similar) modules.
Is there only one raster drawing tool? It's the trade off between simple
interface and design with the all encompassing uber-tool 
I don't
know about other users, but when a command line program gets too many
options it becomes painful to use, IMO. But, I agree with your point
as well (too many similar modules confuse users).
One thing I wanted to get out of both d.vect.area and d.vect.line was the
ability to create a persistent drawing style specification (via the
"legend" file). It's crude, simple, but effective. And I hope others
will find it useful as well.
--
Eric G. Miller <egm2@jps.net>
> I'm considering writing a vector line module similar to d.vect.area, only
> it'd be for drawing labelled lines in different colors via a similar
> legend file (yea? nay? don't care?).
Eric,
Thanks for this excellent work.
I've been thinking, and it seems like a better long-term solution is
to move away from a new "legend file" and make better use of
attributes in GRASS.
I've been looking at the sites format, (I don't know how other formats
compare), and it does allow for named attribute columns, but the names
are rarely used in GRASS. Instead, the attributes are referenced by
index, (oddly, by an index specific to each attribute type).
It seems like it would be quite nice if, instead of doing something
like:
d.site.labels index=2
I could do:
d.site.labels label=name
where "name" is the column name for a string attribute.
Similar features would be quite nice for colors, symbol types, and
line styles, (once they are supported). It could also be quite
convenient if modules would take default values from attributes of the
correct name, (ie. standard attribute names such as "color" and
"symbol" could be established and would be examined by default).
Perhaps it would make sense to invent some syntax for specifying an
attribute name on the command-line that would prevent a clash with
string literals, such that, perhaps:
d.site.labels label=name
would display the string "name" at each site, whereas:
d.site.labels label=<name>
would display the value of the attribute named "name" at each site.
Of course, for completeness, there would also be a means to escape
whatever delimiter was used. An alternate option would be to make
separate arguments for accepting literals vs. attribute names,
(eg. label=literal vs. label_attr=attr_name). But in my opinion that
is more awkward.
With better named attribute support, we would be closer to being able
to integrate GRASS with a database system, (such as PostGIS for
example). Of course, this would require carefully modularizing GRASS
such that all data-access functions were collected into a single
library, (which is an important thing to do for maintenance sake
regardless).
-Carl
On Feb 7, Helena wrote:
> > It seems like it would be quite nice if, instead of doing something
> > like:
> > d.site.labels index=2
> > I could do:
> > d.site.labels label=name
> > where "name" is the column name for a string attribute.
>
> this would be nice, the problem is that many site files do not have headers and
> therefore
> there are no labels. But it would be a nice option in addition to index.
It would not be hard to force all new sites files generated by GRASS
to have the header. It could auto-assign header labels, "cop01",
"cop02", ... if the user did not provide any. Of course, GRASS should
always maintain the ability to read sites files without the headers.
-Carl
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
On Thu, 7 Feb 2002 14:43:08 -0500, Carl Worth <cworth@east.isi.edu> wrote:
> I'm considering writing a vector line module similar to d.vect.area, only
> it'd be for drawing labelled lines in different colors via a similar
> legend file (yea? nay? don't care?).Eric,
Thanks for this excellent work.
I've been thinking, and it seems like a better long-term solution is
to move away from a new "legend file" and make better use of
attributes in GRASS.I've been looking at the sites format, (I don't know how other formats
compare), and it does allow for named attribute columns, but the names
are rarely used in GRASS. Instead, the attributes are referenced by
index, (oddly, by an index specific to each attribute type).
I don't disagree with you about using attributes, but that functionality
isn't available in GRASS 5.0 (only cat numbers and labels). I wouldn't
want to extend the sites format. IMHO, it should be thrown away as soon
as possible and replaced with database tables. Better point data
support in 5.1 vectors will probably makes "sites" a thing of the
past (I can hope can't I?).
--
Eric G. Miller <egm2@jps.net>
"Eric G. Miller" wrote:
On Thu, 7 Feb 2002 14:43:08 -0500, Carl Worth <cworth@east.isi.edu> wrote:
> > I'm considering writing a vector line module similar to d.vect.area, only
> > it'd be for drawing labelled lines in different colors via a similar
> > legend file (yea? nay? don't care?).
>
> Eric,
>
> Thanks for this excellent work.
>
> I've been thinking, and it seems like a better long-term solution is
> to move away from a new "legend file" and make better use of
> attributes in GRASS.
>
> I've been looking at the sites format, (I don't know how other formats
> compare), and it does allow for named attribute columns, but the names
> are rarely used in GRASS. Instead, the attributes are referenced by
> index, (oddly, by an index specific to each attribute type).I don't disagree with you about using attributes, but that functionality
isn't available in GRASS 5.0 (only cat numbers and labels). I wouldn't
want to extend the sites format. IMHO, it should be thrown away as soon
as possible and replaced with database tables. Better point data
support in 5.1 vectors will probably makes "sites" a thing of the
past (I can hope can't I?).
the current sites format was a temporary solution until an adequate capability
would be available in vector format - we had 3D soils data with many attributes,
as well as some 3D pollution data and sites combined with awk provided
lots of functionality that we needed. I don't think that the current sites format
should be
further developed, however we cannot throw it away until its
functionality is fully replaced (my entire work now depends on it as all the
measured
data that I get are ascii point data and it has been very easy to handle them in
GRASS).
But it was really a temporary solution (which has been in place for over six
years),
Helena
--
Eric G. Miller <egm2@jps.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On Thu, 07 Feb 2002 19:53:54 -0600, Helena <hmitaso@unity.ncsu.edu> wrote:
[snip]
the current sites format was a temporary solution until an adequate capability
would be available in vector format - we had 3D soils data with many attributes,
as well as some 3D pollution data and sites combined with awk provided
lots of functionality that we needed. I don't think that the current sites format
should be
further developed, however we cannot throw it away until its
functionality is fully replaced (my entire work now depends on it as all the
measured
data that I get are ascii point data and it has been very easy to handle them in
GRASS).
But it was really a temporary solution (which has been in place for over six
years),
I'm not advocating throwing it away today. Obviously we'd want a migration
path and would want to retarget the interesting sites programs to use a
unified vector map approach.
My short list of problems with the sites format:
1. No data definition in the header is required, therefore a heuristic is
used to parse. Information in the header is mostly window dressing, since
it can't be relied upon.
2. Limited data "types" (coordinates, doubles, a "category" number, and
strings). No integers (other than "cat"), no dates, no booleans.
3. No way to reference most attribute fields other than type/index combination.
4. No NULL data support (missing data breaks the parser).
5. Uses too many metacharacters, making parsing more complex than necessary
and requiring character escaping on input.
--
Eric G. Miller <egm2@jps.net>
On Thu, Feb 07, 2002 at 05:37:26PM -0800, Eric G. Miller wrote:
On Thu, 7 Feb 2002 14:43:08 -0500, Carl Worth <cworth@east.isi.edu> wrote:
> > I'm considering writing a vector line module similar to d.vect.area, only
> > it'd be for drawing labelled lines in different colors via a similar
> > legend file (yea? nay? don't care?).
>
> Eric,
>
> Thanks for this excellent work.
>
> I've been thinking, and it seems like a better long-term solution is
> to move away from a new "legend file" and make better use of
> attributes in GRASS.
>
> I've been looking at the sites format, (I don't know how other formats
> compare), and it does allow for named attribute columns, but the names
> are rarely used in GRASS. Instead, the attributes are referenced by
> index, (oddly, by an index specific to each attribute type).I don't disagree with you about using attributes, but that functionality
isn't available in GRASS 5.0 (only cat numbers and labels). I wouldn't
want to extend the sites format. IMHO, it should be thrown away as soon
as possible and replaced with database tables. Better point data
support in 5.1 vectors will probably makes "sites" a thing of the
past (I can hope can't I?).
Radim and me recently discussed this option as well. The sites
format should be eliminated and functionality moved to vector
points mostly stored in a DBMS table or simple DBF (which is already
supported).
Markus
Radim and me recently discussed this option as well. The sites
format should be eliminated and functionality moved to vector
points mostly stored in a DBMS table or simple DBF (which is already
supported).
there is one more thing that needs to be taken care of before the old sites
are eliminated and that is import of data - importing vector data is often a pain
(although it should not be with vector points)
while import of sites data is fairly easy even if they come in a variety of formats
from GPS, LIDAR or various monitoring devices.
Most programs that support
sites should be easily modified or replaced by vector data support, there aren't
really too many site specific modules that would not have a vector equivalent.
Helena
Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On Fri, Feb 08, 2002 at 11:07:15AM -0500, Helena Mitasova wrote:
> Radim and me recently discussed this option as well. The sites
> format should be eliminated and functionality moved to vector
> points mostly stored in a DBMS table or simple DBF (which is already
> supported).there is one more thing that needs to be taken care of before the old sites
are eliminated and that is import of data - importing vector data is often a pain
(although it should not be with vector points)
while import of sites data is fairly easy even if they come in a variety of formatsfrom GPS, LIDAR or various monitoring devices.
Most programs that support
sites should be easily modified or replaced by vector data support, there aren't
really too many site specific modules that would not have a vector equivalent.
Radim proposed to me to also allow for simple ASCII tables which
only include INT and FP but no strings. All other stuff should become
vector-only. In general it won't be a big task to change s.in.dbf to
v.in.dbf. Also CSV files will be possible.
Markus
On Friday 08 February 2002 17:07, Helena Mitasova wrote:
> Radim and me recently discussed this option as well. The sites
> format should be eliminated and functionality moved to vector
> points mostly stored in a DBMS table or simple DBF (which is already
> supported).there is one more thing that needs to be taken care of before the old sites
are eliminated and that is import of data - importing vector data is often
a pain (although it should not be with vector points)
while import of sites data is fairly easy even if they come in a variety of
formatsfrom GPS, LIDAR or various monitoring devices.
Most programs that support
sites should be easily modified or replaced by vector data support, there
aren't really too many site specific modules that would not have a vector
equivalent.Helena
My wish is do not support sites format in grass51.
I propose for grass51 to save sites as vector points and save values for site
either as
- z coordinate (only one)
or
- attributes in table (more values)
I want to add for v.in.ascii optional input file format similar to sites
(float values separated by optional field separator).
Problem could be with database speed. Postgres is slow for
inserting and dbf for selecting. We have to add indexes to dbf
driver, that should solve the problem.
Radim
Markus Neteler wrote:
Radim and me recently discussed this option as well. The sites
format should be eliminated and functionality moved to vector
points mostly stored in a DBMS table or simple DBF (which is already
supported).
I like this idea : points have only one (x,y) couple, so its
easy to manage even outside a gis. (you just need some GIS functions
for display)
--
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
