[postgis-users] PostGIS wrapper for proximity queries

[Willy-Bas Loos]

wow, that sounds pretty funky!
doesn't the unioning etc kill your performance advantage?
have you done any benchmarking to quantify the performance of this solution?

do you have lots of user behavior rules?
the system that we are building on will be managed pretty de-centralized, so
if everyone has his own policy on how to fill & maintain the database that
would be a problem.

thank you!
WBL

On Thu, Apr 17, 2008 at 7:50 PM, Brent Wood <pcreso at pcreso.com> wrote:

>
> --- Willy-Bas Loos <willybas at gmail.com> wrote:
>
> > We are currently looking for a solution to store (and use, combine)
> > information from different original coordinate systems in one table. It
> > seems like the best solution to store the geoms in WGS84 and convert it
> to
> > whatever srid the client needs.
>
> Hi,
>
> I use a variety of projections for my data, for several reasons, & have
> found
> PostGIS eminently capable.
>
> For optimum retrieval performance, I have physical tables with a separate
> geometry column for each projection. One example is a table of some
> 1,000,000
> polygons, natively in WGS84 lat/long, but also in a separate custom equal
> area
> projection for areal analyses of the polygons. Each column with it's own
> spatial index.
>
> Generally, I use a view which generates the additional projected versions
> on
> the fly from the base WGS84 polygons, so that queries on this table do not
> need
> to include the transforms for output data. This approach may well suit
> your
> use.
>
> Occasionally I have used views with transforms from data stored natively
> in
> different projections using union to concatenate the different
> tables/datasets
> without physically merging them into a single table.
>
> Multiple geometries for features is something I think PostGIS does well,
> much
> better than most GIS packages. In addition to different projections for a
> feature, I also store startpoints, endpoints, lines, buffered
> lines/polygons as
> physical geometry columns in some tables, having 5 geometries in a table
> is not
> that unusual. Data issues mean I don't always have tracklines, or both
> start &
> finish positions, so need to handle a variety of incomplete spatial data
> values
> pertaining to individual features/rows.
>
>
> HTH,
>
>  Brent Wood
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20080418/b79463fa/attachment.html>