RE: [GRASS-user] PostgreSQL support (was: Grass62 on X86_64)

GRASS GRASS user
1

If the issue is information format, as I surmise, cut losses and consider
the file translation protocols. Like shp2svg to svg2swf for certain output -
a similar input process could be considered - or referenced for users.

That said, GRASS would generally benefit from some dependency independence,
perhaps by setting up some of the application procedures simply as objects,
in the function performance scheme(with suitable indexes perhaps).
[applause foe excellent volunteers with applicable skills, bravo]

-----Original Message-----
From: grassuser-bounces@grass.itc.it
[mailto:grassuser-bounces@grass.itc.it]On Behalf Of Craig Aumann
Sent: Wednesday, February 14, 2007 12:00 PM
To: rez@touchofmadness.com
Cc: grassuser@grass.itc.it
Subject: Re: [GRASS-user] PostgreSQL support (was: Grass62 on X86_64)

Your points are good ones, given that GRASS (unlike most other
applications) depends on SO many other apps. Unfortunately, I have no sage
suggestions.

Craig

Craig,

The issue is dependencies. We already have a large number of
dependencies (as you have noticed). Requiring another very large
dependency is an issue, nor do I have the resources to create 5
different versions to accommodate each and every user (someone may want
Jasper, or Kakadu, or ECW...Sadly, we can't be all things to all people
with the current architecture). Also, keep in mind that most of us are
not compensated for our work. We are all volunteers here.

1 for and 1 against. Others?

Let's open this up to i386, too, since I also build RPMs for that
architecture as well.

On Wed, 2007-02-14 at 12:09 -0700, Craig Aumann wrote:

Well, I certainly use POSTGRESQL... I don't understand the issues
involved in modularizing it, or why it can't be compiled in by default
without effecting endusers... I guess the bigger issue is that GRASS
is
supposed to support a variety of databases, and it would be nice if it
simply did this without the end user having to muck about with
recompilling.

> On Tue, 2007-02-1

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

2

Daniel Farnan wrote:

If the issue is information format, as I surmise, cut losses and
consider the file translation protocols. Like shp2svg to svg2swf for
certain output - a similar input process could be considered - or
referenced for users.

but the best format translation software to use is gdal_translate +
ogr2ogr, which means GDAL/OGR must be built with the formats anyway...

That said, GRASS would generally benefit from some dependency
independence,

The only way our small devel community can maintain such a huge package
(we all ready have approx 1 million lines of code to maintain) is by
outsourcing bits of the code to other projects, who do each of
their jobs better than we could hope to. It's better we focus our
efforts on what we do well -- bringing it all together.

Making sure all the dependencies are met and supplied in a seamless
manner is a job for the packagers. (e.g. on the Mac you just install
William's frameworks package & it's all there; very simple [for the
user, William may disagree :wink: ])

Hamish