Re: geographic coordinate types?

From: "Timothy H(dot) Keitt" <keitt(at)nceas(dot)ucsb(dot)edu>
To: Jeff Hoffmann <jeff(at)propertykey(dot)com>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: geographic coordinate types?
Date: 2000-08-16 18:45:11
Message-ID: 399AE137.F44E2BE8@nceas.ucsb.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

It would be quite easy to add functions for projecting into different
coordinate systems using PROJ.4. The problem is how do you keep track
of the metadata? The projections take parameters (prime meridian, etc.)
and so it would be up to the user to keep track of which projection they
are using. (Otherwise you have to define a new data type for all
projection/parameter combinations which doesn't make much sense.)

AFAICT, most GIS programs simply project into a cartesian projection and
then use standard euclidean geometry for queries, i.e., exactly what is
currently supported in postgres (at least in 2D). For small scale work,
that's probably sufficient. However, linearity of the coordinate system
will not hold at larger scales.

At any rate, it would be very nice to have a geographic coordinate type
in postgres. Once the meaning of certain predicates (greater than,
contains, etc.) are defined, these can be indexed as well. Add in the
aforementioned projection code and you have a reasonable start on a GIS.

Tim

Jeff Hoffmann wrote:
>
> i got the impression that the "real" mapping types includes
> transformation functions -- i.e., we have data in both state plane and
> lat/long (UTM) and they need to play nice together. some more details
> would be nice -- there are free packages out there to do the
> transformation at the application level (search for PROJ and gctpc for a
> couple of pointers), but nobody i know of has needed anything like that
> enough to actually put it in the database itself. i think it would be
> interesting to put out there exactly what you need to see what isn't
> there, what can be worked around, what would be a good target for future
> development, etc. i've had a few "wouldn't it be nice thoughts" about
> similar things, but it's always been easier to workaround because as far
> as i can tell there's not a whole lot of interest in those features.
>

--
Timothy H. Keitt
National Center for Ecological Analysis and Synthesis
735 State Street, Suite 300, Santa Barbara, CA 93101
Phone: 805-892-2519, FAX: 805-892-2510
http://www.nceas.ucsb.edu/~keitt/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Darrin Ladd 2000-08-16 19:04:38 regression test failure on initdb
Previous Message Timothy H. Keitt 2000-08-16 18:23:59 Re: geographic coordinate types?