let's standardize sites

GRASS GRASS user
1

Mark Line writes:

The non-2D-attribute issue is technical, not conceptual in the above
sense, I think. Having a 3rd (4th, 5th, nth) dimension built into the
GRASS sites format and processing functions allows you to do a lot without
setting up an external database or extra manipulation routines in awk. The
trade-off has to do with how much functionality you want to hard-wire into
GRASS sites handling, and how much you force into external platforms.

For what it's worth, my vote would be for as little hard-wired into GRASS
site processing as possible, plus really clean interworking with the
platforms that were designed to handle application-dependent sets of
(non-spatial) attributes: RIM if necessary, awk if possible, for instance.

Mark is right about the GRASS code, there is no call to make it process
this extra information. However, the need to develop robust data formats is
a separate question.

Ideally, the best site format is a tab delimited set of columns where the
first column is a site number, the next three are x,y,z, and arbitrary
extra columns are either used or ignored by each piece of sofgtware as
appropriate. This data can go directly into most contouring packages,
presentation packages, spreadsheets, and interactive surface display
applications.

What follows is NOT a FLAME directed to Mark, but a general call for comment

If GRASS and OpenGIS are going to prosper they must accomodate the way that
new users use computers! While you and I can use awk, such tools are
becoming anachronistic. My students want to suck the data into Wingz or
Excel and run macros, not learn the ins and outs of awk syntax. More
importantly, managers want to use data this way, and they sure as hell
aren't going to screw around with awk.

If one looks at the trend in commercial GIS, it is towards ease of use that
simulates common desktop (read Windows and Mac) software and better and
better interaction with common desktop productivity software.

If you want to know what people want, look at what they spend money on. The
problem with FREE (as opposed to OPEN) software is that it lacks this form
of directed input.

If we, the GRASS community, don't allow and encourage GRASS to grow in this
direction as well, it will become a backwater and ultimately stagnate. I
don't want to see this happen, the strengths of OpenGIS are too many to
allow this. But that means we have to address ease of use issues. The
attitude "let them use awk" is exactly what GRASS doesn't need.

Glenn C. Kroeger, Ph.D.
Associate Professor of Geology
Director of Environmental Studies
Trinity University, 715 Stadium Dr., San Antonio, TX 78212
(210) 736-7607
gkroeger@geology.trinity.edu

2

On 25 Jan 1994, Glenn C. Kroeger wrote:

Mark Line writes:
>For what it's worth, my vote would be for as little hard-wired into GRASS
>site processing as possible, plus really clean interworking with the
>platforms that were designed to handle application-dependent sets of
>(non-spatial) attributes: RIM if necessary, awk if possible, for instance.

Mark is right about the GRASS code, there is no call to make it process
this extra information. However, the need to develop robust data formats is
a separate question.

I don't see how data formats to be supported strategically by GRASS are a
_separate_ question from that of what to include in GRASS code. It seems
that the former is a part of the latter.

If GRASS and OpenGIS are going to prosper they must accomodate the way that
new users use computers! While you and I can use awk, such tools are
becoming anachronistic. My students want to suck the data into Wingz or
Excel and run macros, not learn the ins and outs of awk syntax. More
importantly, managers want to use data this way, and they sure as hell
aren't going to screw around with awk.

I don't see what is anachronistic about awk & Co. It is a formal language,
which many users have been indoctrinated into abhoring. I also know by
whom (their corporate headquarters is near here). It is a simple fact of
user interface design that not every conceivable processing functionality
is equally amenable to a so-called "intuitive", point-and-click user
interface. Serious researchers, and students who want to become serious
researchers, should not be limited in their tools to those that are
amenable to easy integration with MS-Windows and Excel (for example).

That doesn't mean I'm against spreadsheets, of course. It's just one more
tool, about as old as awk & Co., and no more anachronistic.

If one looks at the trend in commercial GIS, it is towards ease of use that
simulates common desktop (read Windows and Mac) software and better and
better interaction with common desktop productivity software.

That is probably correct. However, there are those of us who value
processing functionality over integration with one particular (relatively
computer-illiterate) user sector's idea of "ease of use". If you can find
a Windows-like user interface paradigm that matches the bandwidth of what
is doable in GRASS + shell + awk & Co., then tell us. I'll develop a GUI
for free using your idea. I'm not holding my breath, though. Until that
time, I see no point in limiting the useful functionality of GRASS &
associated tools to what seems reasonable to the less computer-literate.

Please do not misinterpret my statement as saying "GRASS is for computer
experts", which I don't believe or condone at all. What I'm saying is that
GRASS + shell + awk & co. has an *enormous* functionality bandwidth, and
that the bandwidth of the user interface to this functionality has to
match it, or else functionality is effectively lost.

If you want to know what people want, look at what they spend money on. The
problem with FREE (as opposed to OPEN) software is that it lacks this form
of directed input.

Bad analogy, I think. Judging from market share, people want McDonald's
hamburgers. That doesn't mean that McDonald's hamburgers are the epitome
of haute cuisine, if you get my drift. There are those of us who prefer to
eat better than McDonald's hamburgers, even if it means we have to do our
own cooking sometimes.

If we, the GRASS community, don't allow and encourage GRASS to grow in this
direction as well, it will become a backwater and ultimately stagnate. I
don't want to see this happen, the strengths of OpenGIS are too many to
allow this. But that means we have to address ease of use issues. The
attitude "let them use awk" is exactly what GRASS doesn't need.

GRASS should _grow_ in any direction that is useful to its users. What you
propose, though, seems to be putting a low-bandwidth user interface on top
of a high-bandwidth processing sytem, because certain (potential) users
are only prepared to use a low-bandwidth user interface. This line of
reasoning is incorrect, I think: if a particular user needs to have a
low-bandwidth user interface, then that user has no business using a
high-bandwidth processing system like GRASS, since he can't control it.

-- Mark

--------------------------------------------------------------------
Mark P. Line Phone: +1-206-733-6040
Open Pathways Fax: +1-206-733-6040
P.O. Box F Email: markline@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------

3

Soo..... where does this leave us?

Personally, I don't think that the multi-dimension is too bad.
After all, Helena has tools that work in higher dimensions.

One thing that I was really after in the beginning with was to
solidify the notion that any number directly following a '#' was
to be interpreted as an integer category number (not a floating point
number). This appears to be okay with everyone.

I've also read (and wrote) that multiple attributes should be left to
a database program. If not, then we get potential confusion by the
user on which field is actually being used. If we can agree to leave
this to external software, then modifying Dave's suggestion gives us:

<easting>|<northing>|[z|[d4|]...][#category_int] [attr_text OR %flt]

So, who has a prototype for the new G_get_site()? Should
we use varargs or just a pointer-to-pointer-to-double
(along with an int and pointer-to-char)?

--Darrell

James Darrell McCauley, Purdue Univ, West Lafayette, IN 47907-1146, USA
mccauley@ecn.purdue.edu, mccauley%ecn@purccvm.bitnet, pur-ee!mccauley
** will finish PhD/engr in 9/94 - need job. inquiries welcome (no hh, plz) **