[GRASS5] Re: An internal db for GRASS

GRASS GRASS developer
1

Hi Andrea,
Hi developers,

On Mon, Feb 05, 2001 at 09:54:21AM +0100, Andrea Aime wrote:

Hi Markus,
I have surfed for a while yesterday searching for an internal
dbms for GRASS... results are not much exciting:
* dbf creation and reading is built in shapelib library, which
  is already used in GRASS... but I don't see any indexing
  features to speed up queries, it seems there is only sequential
  access;
* gdbm, which can be found at GDBM
  seems to be a library to build small databases with indexing, but
  it has not been developed for a long time (it seems a dead project);
* as you already said, Berkley DB is not open source, but I see that
  it has been used in GNOME and in MYSQL, which are open source
  projects.
  Their license allows to use Berkley DB in an open source project
  without fees, and it's fast and full featured. But I was wondering if
  it can be redistriuited with grassio library, which will be LGPL to
  allow
  commercial products to access GRASS data (I mean, you can look at it
  as an attempt to use Berkley db from a commercial product without
  having to pay for a license...)

I've taken a look at grass51 proposal... sounds good, and I'm waiting
to see more.

Bye
Andrea

Thanks for searching the web! I put this onto grass5 list for the
others.

Concerning Berkley DB: I just have seen that it is used in "openoffice"
as well now (led by SUN:
http://www.openoffice.org/dev_docs/source/build_614/release_notes_614.html
).

Although the license of Berkley DB is non-GPL, it seems to be usable in
several GPL'ed projects. Perhaps our license experts here can give a
recommendation on this? We definitly need something "handy" for 5.1.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Markus Neteler wrote:

Hi Andrea,
Hi developers,

On Mon, Feb 05, 2001 at 09:54:21AM +0100, Andrea Aime wrote:
> Hi Markus,
> I have surfed for a while yesterday searching for an internal
> dbms for GRASS... results are not much exciting:
> * dbf creation and reading is built in shapelib library, which
> is already used in GRASS... but I don't see any indexing
> features to speed up queries, it seems there is only sequential
> access;
> * gdbm, which can be found at http://www.gnu.org/software/gdbm/gdbm.html
> seems to be a library to build small databases with indexing, but
> it has not been developed for a long time (it seems a dead project);
> * as you already said, Berkley DB is not open source, but I see that
> it has been used in GNOME and in MYSQL, which are open source
> projects.
> Their license allows to use Berkley DB in an open source project
> without fees, and it's fast and full featured. But I was wondering if
> it can be redistriuited with grassio library, which will be LGPL to
> allow
> commercial products to access GRASS data (I mean, you can look at it
> as an attempt to use Berkley db from a commercial product without
> having to pay for a license...)
>
> I've taken a look at grass51 proposal... sounds good, and I'm waiting
> to see more.
>
> Bye
> Andrea

Thanks for searching the web! I put this onto grass5 list for the
others.

Concerning Berkley DB: I just have seen that it is used in "openoffice"
as well now (led by SUN:
http://www.openoffice.org/dev_docs/source/build_614/release_notes_614.html
).

Although the license of Berkley DB is non-GPL, it seems to be usable in
several GPL'ed projects. Perhaps our license experts here can give a
recommendation on this? We definitly need something "handy" for 5.1.

Regards

Markus

I would just like to add my voice to support inclusion of Berkeley DB in
GRASS. If you start thinking about bringing in an external database
system for GRASS, you just keep going round in circles because nothing
is quite perfect. But DB is the best. The problems are:

1. DB has considerable version incompatibility (even with minor
versions) - but with most recent versions, this has quietened down a
bit. Most UNIX installations at least have a version (or more than one)
installed, and also there is a version v1.86 built in to glibc.
Incompatible versions 2.x, 3.0 and 3.1+ are also scattered around. If we
use it, I think it will have to be bundled, so that we can standardise
on a (recent) version. It is quite large, but perhaps parts of the
distribution could be left out - I don't know if the licensing terms
would allow this. Otherwise maybe it could be distributed in a separate
GRASS_support package, much as the KDE folk do with kdesupport, and then
allow an autoconf option to use a system installation if it is present,
otherwise require the bundled version.

2. It does not have spatial data structures. Just now there are flat
record/hash table/BTree options. It would be nice to have a system with
largely consistent features but give a wide variety of choices for the
type of key to use, including spatial types.

The GIST library does have a larger variety of data structure types to
choose from, and is aimed more at traditional uses of digital mapping,
like GIS, but is not primarily for information handling like a
traditional RDBMS. Maybe that could be used also. I think this has been
discussed before, but I don't know if anyone is using it - are there
plans for inclusion?

Traditional data handling and spatial location purposes have never
really converged, so perhaps we really need an example of each for all
the developers' needs. So, DB might do for the former and GIST for the
latter. Both could be included as support extensions.

Regards

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

[snip]

2. It does not have spatial data structures. Just now there are flat
record/hash table/BTree options. It would be nice to have a system with
largely consistent features but give a wide variety of choices for the
type of key to use, including spatial types.

For what concerns spatial data structures in a DB, Postgres supports
that and the forecoming OpenVectorDB will do as well. I think that
GRASS should support a file based approach, suitable to exchange data
and for small environments, and a full DBMS approach, as an option
for more complex works. To make that choice feasible vector API should
be independent of the archiving method chosen (apart from some
initialize
function in which one needs to specify which kind of acces wants to use)

The GIST library does have a larger variety of data structure types to
choose from, and is aimed more at traditional uses of digital mapping,
like GIS, but is not primarily for information handling like a
traditional RDBMS. Maybe that could be used also.

GIST indexing capabilities would be very nice, since GIST can generate
r-tree indexes, that are very important to speed up vector analysis
operations
such as spatial queries (which are the polygons inside that area?) and
overlays. Since GIST is a generic toolkit used to build indexes, maybe
it
could be used to build point-quadtree indexes as well (like Chistian did
at italian GrassDay).

Bye
Andrea Aime

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Thu, 8 Feb 2001, David D Gray wrote:

I would just like to add my voice to support inclusion of Berkeley DB in
GRASS. If you start thinking about bringing in an external database
system for GRASS, you just keep going round in circles because nothing
is quite perfect. But DB is the best. The problems are:

  Having a database built into GRASS is the ideal solution, but we seem to
be going around in circles over this issue. Here's why:

2. It does not have spatial data structures. Just now there are flat
record/hash table/BTree options. It would be nice to have a system with
largely consistent features but give a wide variety of choices for the
type of key to use, including spatial types.

  If we're looking at a dbms for attribute data, I still like postgres. But,
my understanding of the objections to postgres is that it doesn't handle
spatial data structures. Apparently, Berkeley DB doesn't either. So, what do
we gain by using it?

  With postgres for attribute data we have a GPL application that runs on
almost all platforms and is well documented and well supported.

The GIST library does have a larger variety of data structure types to
choose from, and is aimed more at traditional uses of digital mapping,
like GIS, but is not primarily for information handling like a
traditional RDBMS. Maybe that could be used also. I think this has been
discussed before, but I don't know if anyone is using it - are there
plans for inclusion?

  While I don't know anything about this, I was under the impression that
the academic CS types at Baylor were addressing this need of a built-in
GRASS dbms that would accommodate spatial and attribute data of the various
types manipulated by GRASS. Perhaps Bruce could enlighten us on this point.
The folks down there (that's relative to where I am, of course) have the
expertise we need.

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            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'

5

Forgive my ignorance, but...

Rich Shepard wrote:

> 2. It does not have spatial data structures. Just now there are flat
> record/hash table/BTree options. It would be nice to have a system with
> largely consistent features but give a wide variety of choices for the
> type of key to use, including spatial types.

  If we're looking at a dbms for attribute data, I still like postgres. But,
my understanding of the objections to postgres is that it doesn't handle
spatial data structures. Apparently, Berkeley DB doesn't either. So, what do
we gain by using it?

Postgres handles geometric data -- points, circles, polylines, polygons
and so on -- and includes functions to determine if a point is in an
area, two lines intersect and others (but no sort of raster
functionality). How different is that from handling spacial data
structures? Are those structures something that for some reason
couldn't be addressed as a user-defined type?

  With postgres for attribute data we have a GPL application that runs on
almost all platforms and is well documented and well supported.

I was of the impression that Postgres was under a Berkeley license, not
GPL. Is the distinction significant?

Roger Miller
Lee Wilson and Associates

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Sat, Feb 10, 2001 at 12:41:30PM -0700, Roger S. Miller wrote:

Forgive my ignorance, but...

Rich Shepard wrote:

> > 2. It does not have spatial data structures. Just now there are flat
> > record/hash table/BTree options. It would be nice to have a system with
> > largely consistent features but give a wide variety of choices for the
> > type of key to use, including spatial types.
>
> If we're looking at a dbms for attribute data, I still like postgres. But,
> my understanding of the objections to postgres is that it doesn't handle
> spatial data structures. Apparently, Berkeley DB doesn't either. So, what do
> we gain by using it?

Postgres handles geometric data -- points, circles, polylines, polygons
and so on -- and includes functions to determine if a point is in an
area, two lines intersect and others (but no sort of raster
functionality). How different is that from handling spacial data
structures? Are those structures something that for some reason
couldn't be addressed as a user-defined type?

Problem is, it treats everything as Cartesian coordinates, which is
wrong for lat/long calculations. There's also no enforcement of
important things like making sure polylines or polygons don't intersect
themselves (i.e. should be split at a node). Furthermore, there's no
conception of islands/holes for polygons.

> With postgres for attribute data we have a GPL application that runs on
> almost all platforms and is well documented and well supported.

I was of the impression that Postgres was under a Berkeley license, not
GPL. Is the distinction significant?

Berkeley license is compatible with GPL (mostly).

Difference between PostgreSQL and Berkeley DB are huge. Ones a client
server database management system, the other is a library with some
functions for managing DB files that treats all user data except keys
opaquely. I'm a little worried about using Berkeley DB because, I
understand, the files it creates are machine specific (i.e. not
portable).

--
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'

7

On Sat, 10 Feb 2001, Roger S. Miller wrote:

Forgive my ignorance, but...

Roger,

  Welcome to my club! :slight_smile:

Postgres handles geometric data -- points, circles, polylines, polygons
and so on -- and includes functions to determine if a point is in an
area, two lines intersect and others (but no sort of raster
functionality). How different is that from handling spacial data
structures? Are those structures something that for some reason
couldn't be addressed as a user-defined type?

  I know it does. When I brought this up months ago, I was told by those who
I assume know much better than I, that it was not suitable for an arc-node
format such as GRASS.

  Thinking about this just now, it occurs to me that we'd use points and
arcs as graphic types. The problem is that postgres does not handle
topology. What it would take to handle topology within postgres, GRASS or a
separate (but tightly integrated) program is beyond my knowledge.

  Looking at ARC/Info export data, I see that vectors have attributes such
as LPOLY, RPOLY and so on. Is this computationally too difficult to store in
a postgres database along with each spatial arc or point? I don't know.

  Sure, raster data is handled well internally and we don't want/need to
mess with that. But, multi-attribute sites data and vector data are a
different story.

  I have a bunch of questions directly related to this point, but that'll be
the subject of a separate message later today.

I was of the impression that Postgres was under a Berkeley license, not
GPL. Is the distinction significant?

  It was a while since I looked at the postgres license, so I just did. Here
it is:

Portions Copyright (c) 1996-2000, PostgreSQL, Inc

Portions Copyright (c) 1994 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement
is hereby granted, provided that the above copyright notice and this
paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO
PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

  The third paragraph says it all. So, it's not GPL, but it can be used and
distributed without restriction, either as part of the GRASS distribution or
if we tell folks, "get your own copy". It's also not the usual BSD license,
either. I'm not a lawyer, but this looks quite unrestrictive to me.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            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'

8

On Sat, Feb 10, 2001 at 12:23:35PM -0800, Rich Shepard wrote:

On Sat, 10 Feb 2001, Roger S. Miller wrote:

> Forgive my ignorance, but...

Roger,

  Welcome to my club! :slight_smile:

> Postgres handles geometric data -- points, circles, polylines, polygons
> and so on -- and includes functions to determine if a point is in an
> area, two lines intersect and others (but no sort of raster
> functionality). How different is that from handling spacial data
> structures? Are those structures something that for some reason
> couldn't be addressed as a user-defined type?

  I know it does. When I brought this up months ago, I was told by those who
I assume know much better than I, that it was not suitable for an arc-node
format such as GRASS.

  Thinking about this just now, it occurs to me that we'd use points and
arcs as graphic types. The problem is that postgres does not handle
topology. What it would take to handle topology within postgres, GRASS or a
separate (but tightly integrated) program is beyond my knowledge.

  Looking at ARC/Info export data, I see that vectors have attributes such
as LPOLY, RPOLY and so on. Is this computationally too difficult to store in
a postgres database along with each spatial arc or point? I don't know.

  Sure, raster data is handled well internally and we don't want/need to
mess with that. But, multi-attribute sites data and vector data are a
different story.

In theory, you could use postgresql to store *all* data. I think the
only way it could work is to mostly *not* use the built-in geometric types
and have some "middleware" for all I/O. It would take a considerable
amount of effort to come up with a workable base schema (you'd need
extra catalog tables) and the "middleware" would have to have a lot of
smarts built in. I have a conception of how to do this, but it is not
trivial.

--
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'

9

On Sat, 10 Feb 2001, Eric G . Miller wrote:

Problem is, it treats everything as Cartesian coordinates, which is
wrong for lat/long calculations. There's also no enforcement of
important things like making sure polylines or polygons don't intersect
themselves (i.e. should be split at a node). Furthermore, there's no
conception of islands/holes for polygons.

Eric,

  Other than that I work only with projected data, not lat/lon, I'm glad
that you helped shed some light on the darkness of my ignorance.

Difference between PostgreSQL and Berkeley DB are huge. Ones a client
server database management system, the other is a library with some
functions for managing DB files that treats all user data except keys
opaquely. I'm a little worried about using Berkeley DB because, I
understand, the files it creates are machine specific (i.e. not portable).

  I just got rid of a C library for flat-file databases. I don't know if I
still have the code or not, let me go look ...
.. nope, looks like it's gone.

  We still have the spatial object issue, don't we?

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            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'

10

On Sat, 10 Feb 2001, Eric G . Miller wrote:

In theory, you could use postgresql to store *all* data. I think the
only way it could work is to mostly *not* use the built-in geometric types
and have some "middleware" for all I/O. It would take a considerable
amount of effort to come up with a workable base schema (you'd need
extra catalog tables) and the "middleware" would have to have a lot of
smarts built in. I have a conception of how to do this, but it is not
trivial.

Eric,

  Well, I know postgres, and I've been writing database programs for almost
a decade now, so I could help with the effort.

  It seems to me that the effort would be worth-while. I see the need for a
comprehensive spatial/attribute relational database as a priority for GRASS
as it develops and expands its user base.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            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'

11

Rich Shepard wrote:

On Sat, 10 Feb 2001, Roger S. Miller wrote:

> Forgive my ignorance, but...

Roger,

  Welcome to my club! :slight_smile:

> Postgres handles geometric data -- points, circles, polylines, polygons
> and so on -- and includes functions to determine if a point is in an
> area, two lines intersect and others (but no sort of raster
> functionality). How different is that from handling spacial data
> structures? Are those structures something that for some reason
> couldn't be addressed as a user-defined type?

  I know it does. When I brought this up months ago, I was told by those who
I assume know much better than I, that it was not suitable for an arc-node
format such as GRASS.

  Thinking about this just now, it occurs to me that we'd use points and
arcs as graphic types. The problem is that postgres does not handle
topology.
[...]

Hi,

Yes, I would agree that is possible. This recently occurred to me also.

  Looking at ARC/Info export data, I see that vectors have attributes such
as LPOLY, RPOLY and so on. Is this computationally too difficult to store in
a postgres database along with each spatial arc or point? I don't know.

Not at all. The build process would just write this data using
Postgresql's API.

The problem is that this is absurdly inefficient for large volume
spatial data, if you are using SQL. It would probably be necessary to
hack some kind of API out of Postgresql itself, to provide lower level
access to the underlying database structures.

[I am assuming there _is_ no low-level API in PostgreSQL, as I see
nothing in the various language API's documentation to suggest it. But
does anyone know better...?]

  Sure, raster data is handled well internally and we don't want/need to
mess with that. But, multi-attribute sites data and vector data are a
different story.

  I have a bunch of questions directly related to this point, but that'll be
the subject of a separate message later today.

Perhaps anticipating.. there are distinctions between the
spatial/geometric/positional characteristics of a vector map, and those
that are to do with topological structure.

We have been discussing recently the changes needed for GRASS5.1, and an
idea that has been floated is to incorporate a second persistent binary
file which will be a spatial tree representation of the map, providing
easily accessed information allowing spatial queries on the map, much as
the dig_plus provides persistent information about the topological
links. Only a topologically aware vector map (Level 2) could be mapped
this way, so it might be an optional new `level 3' build.

Also, every entity in a map would have a unique object ID, providing a
link between the spatial data and records in a database.

Regards

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

On Sun, Feb 11, 2001 at 01:22:26AM +0000, David D Gray wrote:

Rich Shepard wrote:
>
> On Sat, 10 Feb 2001, Roger S. Miller wrote:
>
> > Forgive my ignorance, but...
>
> Roger,
>
> Welcome to my club! :slight_smile:
>
> > Postgres handles geometric data -- points, circles, polylines, polygons
> > and so on -- and includes functions to determine if a point is in an
> > area, two lines intersect and others (but no sort of raster
> > functionality). How different is that from handling spacial data
> > structures? Are those structures something that for some reason
> > couldn't be addressed as a user-defined type?
>
> I know it does. When I brought this up months ago, I was told by those who
> I assume know much better than I, that it was not suitable for an arc-node
> format such as GRASS.
>
> Thinking about this just now, it occurs to me that we'd use points and
> arcs as graphic types. The problem is that postgres does not handle
> topology.
> [...]

Hi,

Yes, I would agree that is possible. This recently occurred to me also.

> Looking at ARC/Info export data, I see that vectors have attributes such
> as LPOLY, RPOLY and so on. Is this computationally too difficult to store in
> a postgres database along with each spatial arc or point? I don't know.
>

Not at all. The build process would just write this data using
Postgresql's API.

The problem is that this is absurdly inefficient for large volume
spatial data, if you are using SQL. It would probably be necessary to
hack some kind of API out of Postgresql itself, to provide lower level
access to the underlying database structures.

[I am assuming there _is_ no low-level API in PostgreSQL, as I see
nothing in the various language API's documentation to suggest it. But
does anyone know better...?]

Server Programming Interface (SPI), and/or custom modules (I have some
experience writing these for PostgreSQL). I haven't played with SPI,
but I'd think it'd be necessary for setting up handlers. In the end,
with PostgreSQL, you still have to pass data as text (unless using large
objects). There is some mechanism for doing RPC calls and passing in
binary data (but it's not well documented, nor is it promoted). You can
use binary cursors for selects (but the data better reside on a machine
with identical architecture, or translations will be required).

> Sure, raster data is handled well internally and we don't want/need to
> mess with that. But, multi-attribute sites data and vector data are a
> different story.
>
> I have a bunch of questions directly related to this point, but that'll be
> the subject of a separate message later today.
>

Perhaps anticipating.. there are distinctions between the
spatial/geometric/positional characteristics of a vector map, and those
that are to do with topological structure.

We have been discussing recently the changes needed for GRASS5.1, and an
idea that has been floated is to incorporate a second persistent binary
file which will be a spatial tree representation of the map, providing
easily accessed information allowing spatial queries on the map, much as
the dig_plus provides persistent information about the topological
links. Only a topologically aware vector map (Level 2) could be mapped
this way, so it might be an optional new `level 3' build.

Also, every entity in a map would have a unique object ID, providing a
link between the spatial data and records in a database.

Sounds about right to me.

--
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'

13

Hello,
  i installed a CVS Snapshot on solaris.
Heres the problems i encountered, hoping someone can fix them.

1) i had the usual problem in libes/gis/flate.c and the
HAVE_ZLIB_H flag which should be set and its not so that
break compile breaks is. (someone already pointed it out).

2) solaris tar is quite stupid:

  tar cBf - bin/ gives error while
  tar cBf - bin is ok (yes its the slash at the en the problem

so it wont install unless i do not modify the Makefile accordingly.

3) in Init.sh there are some lines added regarding LD_LIBRARY_PATH
i had to remove them (script failing otherwise).

4) (minor one) configure didn't notice that "ar" was not in my path
and libgis.a could not be created... (ar: command not found) unexperienced
users (not that i feel that experienced) may easily get confused.

5) Im afraid some modules will segment and fault or will take the wrong
bus cause i had no idea if icompiled for 64 or 32 bit.
v.in.shape faulted for example (while on my linux box, on the same file
works correctly (apart from requiring tons of ram.)
Will someone help me?

Hope this was useful.
See you people.
      Federico.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

Hi Federico,
hi all,

On Sun, Mar 04, 2001 at 11:21:13PM +0100, Federico Ponchio wrote:

Hello,
  i installed a CVS Snapshot on solaris.
Heres the problems i encountered, hoping someone can fix them.

1) i had the usual problem in libes/gis/flate.c and the
HAVE_ZLIB_H flag which should be set and its not so that
break compile breaks is. (someone already pointed it out).

Mhhh. Currently it is set on all platforms as far as I know
(I have tested on Solaris). The problem will be that
zlib.h
is not found. Try:
configure --with-zlib-includes=DIR

2) solaris tar is quite stupid:

  tar cBf - bin/ gives error while
  tar cBf - bin is ok (yes its the slash at the en the problem

so it wont install unless i do not modify the Makefile accordingly.

Does
tar cBf - bin/*
work?
Justin, what do you think?

3) in Init.sh there are some lines added regarding LD_LIBRARY_PATH
i had to remove them (script failing otherwise).

Could you send the error message? This is required for r.in.gdal.

4) (minor one) configure didn't notice that "ar" was not in my path
and libgis.a could not be created... (ar: command not found) unexperienced
users (not that i feel that experienced) may easily get confused.

Mhh, isn't "ar" usually in the path? Sorry, no idea how to change that.
Perhaps you just set a link :slight_smile:

5) Im afraid some modules will segment and fault or will take the wrong
bus cause i had no idea if icompiled for 64 or 32 bit.
v.in.shape faulted for example (while on my linux box, on the same file
works correctly (apart from requiring tons of ram.)
Will someone help me?

64 or 32 bit compilanbce is checked here:
src/CMD/generic/is64bit.sh
and used in Makefile. Can this be utilized?

Hope this was useful.

Yes!

See you people.
      Federico.

Cheers

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

On Mon, 5 Mar 2001, Markus Neteler wrote:

Hi Federico,
hi all,

> 2) solaris tar is quite stupid:
>
> tar cBf - bin/ gives error while
> tar cBf - bin is ok (yes its the slash at the en the problem
>
> so it wont install unless i do not modify the Makefile accordingly.
Does
tar cBf - bin/*
work?
Justin, what do you think?

Maybe i was not clear enough: tar cBf - bin worked correctly.
I think tar cBF -bin/* would copy the files but not the directory.

> 3) in Init.sh there are some lines added regarding LD_LIBRARY_PATH
> i had to remove them (script failing otherwise).
Could you send the error message? This is required for r.in.gdal.

I do not have easy access to the machine, ill send the error asap.

> 4) (minor one) configure didn't notice that "ar" was not in my path
> and libgis.a could not be created... (ar: command not found)

unexperienced

> users (not that i feel that experienced) may easily get confused.
Mhh, isn't "ar" usually in the path? Sorry, no idea how to change that.
Perhaps you just set a link :slight_smile:

Just what i did :stuck_out_tongue:

Ciao,
  Federico

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

16

Hi Markus and Frederico

Markus Neteler wrote:

> 2) solaris tar is quite stupid:
>
> tar cBf - bin/ gives error while
> tar cBf - bin is ok (yes its the slash at the en the
> problem
>
> so it wont install unless i do not modify the Makefile accordingly.
Does
tar cBf - bin/*
work?
Justin, what do you think?

Isn't Solaris 7 the OS that has a whole slew of problems compiling
Grass? I would suggest that we contact the other Solaris 7 users to see
if they have the same problem first, and if they had a different
solution. Then we can see what works best for everyone.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'