[postgis-users] Index on the Geometry Column and GEOMETRYCOLLECTION EMPTY

Sorin Dudui sd at wigeogis.com
Tue Jul 13 00:29:48 PDT 2010


Hello Mark,

Thank you for your answer. 

I have sent you at <mark.cave-ayland at siriusit.co.uk> some data to reproduce
the issue. I am wondering if you have received it. 

Best regards,
Sorin

-----Ursprüngliche Nachricht-----
Von: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] Im Auftrag von
postgis-users-request at postgis.refractions.net
Gesendet: Donnerstag, 8. Juli 2010 21:00
An: postgis-users at postgis.refractions.net
Betreff: postgis-users Digest, Vol 99, Issue 8

Send postgis-users mailing list submissions to
	postgis-users at postgis.refractions.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://postgis.refractions.net/mailman/listinfo/postgis-users
or, via email, send a message with subject or body 'help' to
	postgis-users-request at postgis.refractions.net

You can reach the person managing the list at
	postgis-users-owner at postgis.refractions.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of postgis-users digest..."


Today's Topics:

   1. Re: Projection(s) for global	point-and-radius	searches
      (David Jantzen)
   2. Re: Projection(s) for global point-and-radius	searches
      (Paul Ramsey)
   3. Re: Projection(s) for global point-and-radius	searches
      (Paul Ramsey)
   4. Re: Projection(s) for global	point-and-radius	searches
      (David Jantzen)
   5. Re: Projection(s) for global point-and-radius	searches
      (Paul Ramsey)
   6. Re: WKT raster installation on mac (Paragon Corporation)
   7. Re: WKT raster installation on mac (William Kyngesburye)
   8. Antwort: Re: Projection(s) for global point-and-radius
      searches (Stefan Priess)
   9. Re: Antwort: Re: Projection(s) for global point-and-radius
      searches (Chen, Li [Contractor])
  10. Re: ESRI union (analysis) in Postgis (Teresa Fazio)
  11. Index on the Geomtery Column and GEOMETRYCOLLECTION	EMPTY
      (Sorin Dudui)
  12. Re: ESRI union (analysis) in Postgis (Ralf Suhr)
  13. Re: ESRI union (analysis) in Postgis (Birgit Laggner)
  14. Re: Index on the Geomtery Column and GEOMETRYCOLLECTION EMPTY
      (Mark Cave-Ayland)
  15. lidar: what is the recommended way of	storing/indexing (Biddy)
  16. Re: Antwort: Re: Projection(s) for global	point-and-radius
      searches (Paul Ramsey)
  17. Re: lidar: what is the recommended way of	storing/indexing
      (Paul Ramsey)
  18. Re: lidar: what is the recommended way of	storing/indexing
      (Paul Ramsey)
  19. Re: lidar: what is the recommended way	of	storing/indexing
      (Peter Baumann)
  20. Re: lidar: what is the recommended	wayof	storing/indexing
      (Paragon Corporation)
  21. Re: lidar: what is the recommended wayof	storing/indexing
      (Paul Ramsey)
  22. Re: lidar: what is the	recommended	wayof	storing/indexing
      (Pierre Racine)


----------------------------------------------------------------------

Message: 1
Date: Wed, 7 Jul 2010 12:19:58 -0700
From: David Jantzen <djantzen at ql2.com>
Subject: Re: [postgis-users] Projection(s) for global	point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <590E91D5-A88E-4B3D-8C04-527E00C23C56 at ql2.com>
Content-Type: text/plain; charset="us-ascii"

Sweet!  It must do on-the-fly projections under the covers, right?  That's a
huge improvement since I used PostGIS last time.

On Jul 7, 2010, at 11:40 AM, Paul Ramsey wrote:

> David,
> 
> Consider using the GEOGRAPHY type if your queries are just going to be
> ST_DWithin style. That will remove all projection issues.
> 
> P.
> 
> On Wed, Jul 7, 2010 at 11:19 AM, David Jantzen <djantzen at ql2.com> wrote:
>> Hey All,
>> 
>> It's been a couple years but happily I have a reason to work with PostGIS
again!  I'm rusty, and this is pretty a basic question, so if you just
specify the chapter in TFM I'll happily go read it.
>> 
>> I need to do simple point-and-radius searches for some properties in
Germany.  Very soon I'll need to do this same thing across Europe and North
America, and some in Asia.  My understanding is that the accuracy of such
measurements will degrade as I use projections covering larger and larger
geographical areas.
>> 
>> So, some questions:
>> 1) Is there a single global projection that I could use for all such
calculations?  How bad would the distortions be and where?
>> 2) Assuming the correct path is to switch projections depending on area
of focus, what are some strategies for this kind of dynamic switching in SQL
queries?
>> 
>> Thanks for your help (and patience),
>> David
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users



------------------------------

Message: 2
Date: Wed, 7 Jul 2010 12:25:13 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] Projection(s) for global point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTinDKdIeGbZW4JoSOJeWdkbOpdA6jdOguqKBBfT7 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

No, it works directly on the sphere, both for the indexes and the
calculations (for a select list of functions):

ST_AsText(geography) returns text
ST_GeographyFromText(text) returns geography
ST_AsBinary(geography) returns bytea
ST_GeogFromWKB(bytea) returns geography
ST_AsSVG(geography) returns text
ST_AsGML(geography) returns text
ST_AsKML(geography) returns text
ST_AsGeoJson(geography) returns text
ST_Distance(geography, geography) returns double
ST_DWithin(geography, geography, float8) returns boolean
ST_Area(geography) returns double
ST_Length(geography) returns double
ST_Covers(geography, geography) returns boolean
ST_CoveredBy(geography, geography) returns boolean
ST_Intersects(geography, geography) returns boolean
ST_Buffer(geography, float8) returns geography
ST_Intersection(geography, geography) returns geography

On Wed, Jul 7, 2010 at 12:19 PM, David Jantzen <djantzen at ql2.com> wrote:
> Sweet! ?It must do on-the-fly projections under the covers, right? ?That's
a huge improvement since I used PostGIS last time.
>
> On Jul 7, 2010, at 11:40 AM, Paul Ramsey wrote:
>
>> David,
>>
>> Consider using the GEOGRAPHY type if your queries are just going to be
>> ST_DWithin style. That will remove all projection issues.
>>
>> P.
>>
>> On Wed, Jul 7, 2010 at 11:19 AM, David Jantzen <djantzen at ql2.com> wrote:
>>> Hey All,
>>>
>>> It's been a couple years but happily I have a reason to work with
PostGIS again! ?I'm rusty, and this is pretty a basic question, so if you
just specify the chapter in TFM I'll happily go read it.
>>>
>>> I need to do simple point-and-radius searches for some properties in
Germany. ?Very soon I'll need to do this same thing across Europe and North
America, and some in Asia. ?My understanding is that the accuracy of such
measurements will degrade as I use projections covering larger and larger
geographical areas.
>>>
>>> So, some questions:
>>> 1) Is there a single global projection that I could use for all such
calculations? ?How bad would the distortions be and where?
>>> 2) Assuming the correct path is to switch projections depending on area
of focus, what are some strategies for this kind of dynamic switching in SQL
queries?
>>>
>>> Thanks for your help (and patience),
>>> David
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


------------------------------

Message: 3
Date: Wed, 7 Jul 2010 12:25:54 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] Projection(s) for global point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTinvO-qmQI8iyPGXG6RS5Sx8eAzW6TdHY02AlgZ3 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> ST_Buffer(geography, float8) returns geography
> ST_Intersection(geography, geography) returns geography

These last two actually *do* carry out projections under the covers,
so watch out.

P


------------------------------

Message: 4
Date: Wed, 7 Jul 2010 14:03:25 -0700
From: David Jantzen <djantzen at ql2.com>
Subject: Re: [postgis-users] Projection(s) for global	point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <AACC0C40-6FAC-4CCE-B1C5-F7B8D1E69D15 at ql2.com>
Content-Type: text/plain; charset="us-ascii"

Ok, interesting.  Is it equivalent then to using a GEOMETRY type with SRID
4326?

On Jul 7, 2010, at 12:25 PM, Paul Ramsey wrote:

> On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>> ST_Buffer(geography, float8) returns geography
>> ST_Intersection(geography, geography) returns geography
> 
> These last two actually *do* carry out projections under the covers,
> so watch out.
> 
> P
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users



------------------------------

Message: 5
Date: Wed, 7 Jul 2010 14:13:06 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] Projection(s) for global point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTims2R7otUtTL_CZ-058xyM54Tv-jsVcQGRamLx2 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

No, because the functions on Geometry(4326) don't return metric answers.

SELECT
  ST_Distance('SRID=4326;POINT(0 0)'::geometry, 'SRID=4326;POINT(1
1)'::geometry) as geom,
  ST_Distance('POINT(0 0)'::geography, 'POINT(1 1)'::geography) as geog;

Geography understands that it's on a sphere and does the Right Thing.
Geometry(4326) still operates on a cartesian plane, it just has
"units" of degrees (which is pretty nonsensical for any kind of
measurement calculation).

P

On Wed, Jul 7, 2010 at 2:03 PM, David Jantzen <djantzen at ql2.com> wrote:
> Ok, interesting. ?Is it equivalent then to using a GEOMETRY type with SRID
4326?
>
> On Jul 7, 2010, at 12:25 PM, Paul Ramsey wrote:
>
>> On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>>> ST_Buffer(geography, float8) returns geography
>>> ST_Intersection(geography, geography) returns geography
>>
>> These last two actually *do* carry out projections under the covers,
>> so watch out.
>>
>> P
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


------------------------------

Message: 6
Date: Wed, 7 Jul 2010 17:38:15 -0400
From: "Paragon Corporation" <lr at pcorp.us>
Subject: Re: [postgis-users] WKT raster installation on mac
To: "'PostGIS Users Discussion'"
	<postgis-users at postgis.refractions.net>
Message-ID: <602F21C7530548DFA2F5B4009BF994E2 at J>
Content-Type: text/plain;	charset="iso-8859-1"

Shaun,

Sorry don't know much about Mac.

Do you have the postgresql develop contrib installed.  I think a lot of
those kind of errors happen if you don't have that installed.
Normally I compile postgis from scratch which does require the develop
contrib to be installed before you can.

Thanks,
Regina
 

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Shaun
Langley
Sent: Wednesday, July 07, 2010 12:09 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] WKT raster installation on mac

I'm still getting stuck with this installation.  I specified the libdir, but
note that libpq is not in this directory.  The path for libpq is
"/Library/PostgreSQL/8.4/include" which is distinct from the other code
libraries in "/Library/PostgreSQL/8.4/lib"  I'm copying the directory
contents so you can clearly see what's included in each.

configure: error: could not find libpq
user-d0c71a:wktraster-0.1.6d langleys$ cd ../include/ user-d0c71a:include
langleys$ ls
ecpg_config.h		pg_config.h		pgtypes_numeric.h
ecpg_informix.h		pg_config_i386.h	pgtypes_timestamp.h
ecpgerrno.h		pg_config_manual.h	postgres_ext.h
ecpglib.h		pg_config_os.h		postgresql
ecpgtype.h		pg_config_ppc.h		sql3types.h
libpq			pgtypes_date.h		sqlca.h
libpq-events.h		pgtypes_error.h
libpq-fe.h		pgtypes_interval.h
user-d0c71a:include langleys$ 

user-d0c71a:include langleys$ cd ../lib
user-d0c71a:lib langleys$ ls
libecpg.6.1.dylib		libpq.dylib
libecpg.6.dylib			libproj.0.5.5.dylib
libecpg.a			libproj.0.dylib
libecpg.dylib			libproj.dylib
libecpg_compat.3.1.dylib	libuuid.16.dylib
libecpg_compat.3.dylib		libuuid.a
libecpg_compat.a		libuuid.dylib
libecpg_compat.dylib		libuuid.la
libgeos-3.2.0.dylib		libxml2.2.7.1.dylib
libgeos.dylib			libxml2.2.dylib
libgeos_c.1.6.0.dylib		libxml2.a
libgeos_c.1.dylib		libxml2.dylib
libgeos_c.dylib			libxml2.la
libpgport.a			libxslt.1.1.23.dylib
libpgtypes.3.1.dylib		libxslt.1.dylib
libpgtypes.3.dylib		libxslt.a
libpgtypes.a			libxslt.dylib
libpgtypes.dylib		libxslt.la
libpq.5.2.dylib			postgis-1.4.so
libpq.5.dylib			postgresql
libpq.a
user-d0c71a:lib langleys$ 

on the first line, you can clearly see that no matter which path I select
for "libdir" the configure script cannot find "libpq".  Any ideas?

Regards,
Shaun


On Jul 6, 2010, at 5:51 AM, Jorge Ar?valo wrote:

> On Mon, Jul 5, 2010 at 6:15 PM, Shaun Langley <shaunlangley at gmail.com>
wrote:
>> it returns /Library/PostgreSQL/8.4/lib
>> 
>> what's the option syntax to add the lib directory during 
>> configuration?  can I specify something like
>> 
>> --with-libdir='/Library/PostgreSQL/8.4/lib'
>> 
> 
> The option should be --libdir='/Library/PostgreSQL/8.4/lib'. Give it a 
> try
> 
> Best regards,
> Jorge
> 
> 
>> Cheers,
>> Shaun
>> On Jul 5, 2010, at 11:51 AM, Jorge Ar?valo wrote:
>> 
>>> On Mon, Jul 5, 2010 at 5:19 PM, Shaun Langley <shaunlangley at gmail.com>
wrote:
>>>> Yes it still complains it can't find libpq.
>>>> 
>>> 
>>> I didn't try it on mac, but in Windows, I had to add the lib directory
to PATH.
>>> 
>>> What happens if you execute pg_config --libdir?
>>> 
>>>> --------------------------
>>>> Shaun Langley
>>>> Graduate Student
>>>> 208 Manly Miles
>>>> Michigan State University
>>>> East Lansing, MI 48824
>>>> (517) 974-9346
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> 
>>>> On Jul 5, 2010, at 10:48 AM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
>>>> 
>>>>> So now that you had it manually does it still complain that it can not
find libpq?
>>>>> 
>>>>> Some systems need us to explicit some installation paths (like
Windows) in the configure command.
>>>>> 
>>>>> Pierre
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: postgis-users-bounces at postgis.refractions.net 
>>>>>> [mailto:postgis-users- bounces at postgis.refractions.net] On Behalf 
>>>>>> Of Shaun Langley
>>>>>> Sent: 2 juillet 2010 19:14
>>>>>> To: postgis-users
>>>>>> Subject: [postgis-users] WKT raster installation on mac
>>>>>> 
>>>>>> I'm trying to install WKT Raster on Mac OS X, using the 
>>>>>> enterprisedb installation of postgres, and postgis through the 
>>>>>> stackbuilder.  I've run into a problem when running the 
>>>>>> ./configure for WKT Raster as it returns an error saying that it 
>>>>>> cannot locate libpq.  The installation of postgres is found at 
>>>>>> /Library/Postgres/8.4/ and libpq is located within lib/.  I had 
>>>>>> to manully specify the location of pg_config which I did
successfully.  Any suggestions on how to proceed?
>>>>>> 
>>>>>> Regards,
>>>>>> Shaun
>>>>>> --------------------------
>>>>>> Shaun Langley
>>>>>> Graduate Student, PhD
>>>>>> Department of Geography
>>>>>> Michigan State University
>>>>>> Home: (517) 974-9346
>>>>>> _______________________________________________
>>>>>> postgis-users mailing list
>>>>>> postgis-users at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>>> _______________________________________________
>>>>> postgis-users mailing list
>>>>> postgis-users at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Jorge Ar?valo
>>> DEIMOS Space
>>> Internet & Mobilty Division
>>> Ronda de Poniente 19. Edificio Fiteni VI, portal 2, 2? 28760 Tres 
>>> Cantos (Madrid)
>>> Tel: +34 91 806 34 50 - ext: 155
>>> jorge.arevalo at deimos-space.com
>>> http://gis4free.wordpress.com
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
>> --------------------------
>> Shaun Langley
>> Graduate Student, PhD
>> Department of Geography
>> Michigan State University
>> Home: (517) 974-9346
>> 
>> 
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
> 
> 
> 
> --
> Jorge Ar?valo
> DEIMOS Space
> Internet & Mobilty Division
> Ronda de Poniente 19. Edificio Fiteni VI, portal 2, 2? 28760 Tres 
> Cantos (Madrid)
> Tel: +34 91 806 34 50 - ext: 155
> jorge.arevalo at deimos-space.com
> http://gis4free.wordpress.com
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

--------------------------
Shaun Langley
Graduate Student, PhD
Department of Geography
Michigan State University
Home: (517) 974-9346


_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users




------------------------------

Message: 7
Date: Wed, 7 Jul 2010 16:49:38 -0500
From: William Kyngesburye <woklist at kyngchaos.com>
Subject: Re: [postgis-users] WKT raster installation on mac
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <55A50A9E-4BF9-48D7-8429-5D8864080014 at kyngchaos.com>
Content-Type: text/plain; charset=iso-8859-1

The 'libpq' that it's not finding is lib/libpq.dylib, not include/libpq
(which is a folder).  So, the libdir option (or lack of) should be OK.

I find that sometimes other unrelated things affect configure detection.  In
the wktraster source folder you should have a config.log, look there for
more details on why it failed to find libpq.

(No problems here configuring wktraster on OS X with my own Postgres and
Postgis binaries.)

On Jul 7, 2010, at 11:08 AM, Shaun Langley wrote:

> I'm still getting stuck with this installation.  I specified the libdir,
but note that libpq is not in this directory.  The path for libpq is
"/Library/PostgreSQL/8.4/include" which is distinct from the other code
libraries in "/Library/PostgreSQL/8.4/lib"  I'm copying the directory
contents so you can clearly see what's included in each.
> 
> configure: error: could not find libpq
> user-d0c71a:wktraster-0.1.6d langleys$ cd ../include/
> user-d0c71a:include langleys$ ls
> ecpg_config.h		pg_config.h		pgtypes_numeric.h
> ecpg_informix.h		pg_config_i386.h	pgtypes_timestamp.h
> ecpgerrno.h		pg_config_manual.h	postgres_ext.h
> ecpglib.h		pg_config_os.h		postgresql
> ecpgtype.h		pg_config_ppc.h		sql3types.h
> libpq			pgtypes_date.h		sqlca.h
> libpq-events.h		pgtypes_error.h
> libpq-fe.h		pgtypes_interval.h
> user-d0c71a:include langleys$ 
> 
> user-d0c71a:include langleys$ cd ../lib
> user-d0c71a:lib langleys$ ls
> libecpg.6.1.dylib		libpq.dylib
> libecpg.6.dylib			libproj.0.5.5.dylib
> libecpg.a			libproj.0.dylib
> libecpg.dylib			libproj.dylib
> libecpg_compat.3.1.dylib	libuuid.16.dylib
> libecpg_compat.3.dylib		libuuid.a
> libecpg_compat.a		libuuid.dylib
> libecpg_compat.dylib		libuuid.la
> libgeos-3.2.0.dylib		libxml2.2.7.1.dylib
> libgeos.dylib			libxml2.2.dylib
> libgeos_c.1.6.0.dylib		libxml2.a
> libgeos_c.1.dylib		libxml2.dylib
> libgeos_c.dylib			libxml2.la
> libpgport.a			libxslt.1.1.23.dylib
> libpgtypes.3.1.dylib		libxslt.1.dylib
> libpgtypes.3.dylib		libxslt.a
> libpgtypes.a			libxslt.dylib
> libpgtypes.dylib		libxslt.la
> libpq.5.2.dylib			postgis-1.4.so
> libpq.5.dylib			postgresql
> libpq.a
> user-d0c71a:lib langleys$ 
> 
> on the first line, you can clearly see that no matter which path I select
for "libdir" the configure script cannot find "libpq".  Any ideas?
> 
> Regards,
> Shaun
> 
> 
> On Jul 6, 2010, at 5:51 AM, Jorge Ar?valo wrote:
> 
>> On Mon, Jul 5, 2010 at 6:15 PM, Shaun Langley <shaunlangley at gmail.com>
wrote:
>>> it returns /Library/PostgreSQL/8.4/lib
>>> 
>>> what's the option syntax to add the lib directory during configuration?
can I specify something like
>>> 
>>> --with-libdir='/Library/PostgreSQL/8.4/lib'
>>> 
>> 
>> The option should be --libdir='/Library/PostgreSQL/8.4/lib'. Give it a
try
>> 
>> Best regards,
>> Jorge


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what
the universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarrely inexplicable.  There is another
theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro




------------------------------

Message: 8
Date: Thu, 8 Jul 2010 08:51:34 +0200
From: Stefan Priess <Stefan.Priess at iav.de>
Subject: [postgis-users] Antwort: Re: Projection(s) for global
	point-and-radius searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	
<OF442EC1D3.57A51012-ONC125775A.00257261-C125775A.0025A9A4 at retarus.de>
Content-Type: text/plain; charset="us-ascii"

Hey Paul,

i need the ST_Expand() function with a radius/expand of 10 Meters, how i 
will do that?
The Point to expand is in SRID 4326 .

Thanks

Stefan
 



Paul Ramsey <pramsey at opengeo.org> 
Gesendet von: postgis-users-bounces at postgis.refractions.net
07.07.2010 23:13
Bitte antworten an
PostGIS Users Discussion <postgis-users at postgis.refractions.net>


An
PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Kopie

Thema
Re: [postgis-users] Projection(s) for global point-and-radius   searches 






No, because the functions on Geometry(4326) don't return metric answers.

SELECT
  ST_Distance('SRID=4326;POINT(0 0)'::geometry, 'SRID=4326;POINT(1
1)'::geometry) as geom,
  ST_Distance('POINT(0 0)'::geography, 'POINT(1 1)'::geography) as geog;

Geography understands that it's on a sphere and does the Right Thing.
Geometry(4326) still operates on a cartesian plane, it just has
"units" of degrees (which is pretty nonsensical for any kind of
measurement calculation).

P

On Wed, Jul 7, 2010 at 2:03 PM, David Jantzen <djantzen at ql2.com> wrote:
> Ok, interesting.  Is it equivalent then to using a GEOMETRY type with 
SRID 4326?
>
> On Jul 7, 2010, at 12:25 PM, Paul Ramsey wrote:
>
>> On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org> 
wrote:
>>> ST_Buffer(geography, float8) returns geography
>>> ST_Intersection(geography, geography) returns geography
>>
>> These last two actually *do* carry out projections under the covers,
>> so watch out.
>>
>> P
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/029dff79/attachment-0001.html>

------------------------------

Message: 9
Date: Thu, 8 Jul 2010 14:53:52 +0800
From: "Chen, Li [Contractor]" <Li.Chen at andrew.com>
Subject: Re: [postgis-users] Antwort: Re: Projection(s) for global
	point-and-radius searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<8FAF8DBABDE6D643926E35A54B67D02033DB4AB9ED at SISPE7MB2.commscope.com>
Content-Type: text/plain; charset="us-ascii"

I think you can try to covert lat/longs to meters, but this is highly
inaccurate, especially in places where the latitude is greater than 75.
This problem troubles us as well

From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Stefan
Priess
Sent: Thursday, 8 July 2010 4:52 PM
To: PostGIS Users Discussion
Subject: [postgis-users] Antwort: Re: Projection(s) for global
point-and-radius searches


Hey Paul,

i need the ST_Expand() function with a radius/expand of 10 Meters, how i
will do that?
The Point to expand is in SRID 4326 .

Thanks

Stefan


Paul Ramsey <pramsey at opengeo.org>
Gesendet von: postgis-users-bounces at postgis.refractions.net

07.07.2010 23:13
Bitte antworten an
PostGIS Users Discussion <postgis-users at postgis.refractions.net>


An

PostGIS Users Discussion <postgis-users at postgis.refractions.net>

Kopie

Thema

Re: [postgis-users] Projection(s) for global point-and-radius
searches







No, because the functions on Geometry(4326) don't return metric answers.

SELECT
 ST_Distance('SRID=4326;POINT(0 0)'::geometry, 'SRID=4326;POINT(1
1)'::geometry) as geom,
 ST_Distance('POINT(0 0)'::geography, 'POINT(1 1)'::geography) as geog;

Geography understands that it's on a sphere and does the Right Thing.
Geometry(4326) still operates on a cartesian plane, it just has
"units" of degrees (which is pretty nonsensical for any kind of
measurement calculation).

P

On Wed, Jul 7, 2010 at 2:03 PM, David Jantzen <djantzen at ql2.com> wrote:
> Ok, interesting.  Is it equivalent then to using a GEOMETRY type with SRID
4326?
>
> On Jul 7, 2010, at 12:25 PM, Paul Ramsey wrote:
>
>> On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>>> ST_Buffer(geography, float8) returns geography
>>> ST_Intersection(geography, geography) returns geography
>>
>> These last two actually *do* carry out projections under the covers,
>> so watch out.
>>
>> P
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/6755f98c/attachment-0001.html>

------------------------------

Message: 10
Date: Thu, 08 Jul 2010 09:27:06 +0200
From: Teresa Fazio <fazio at planetek.it>
Subject: Re: [postgis-users] ESRI union (analysis) in Postgis
To: postgis-users at postgis.refractions.net
Message-ID: <4C357DCA.1060800 at planetek.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

The solution you propose is valid to get polygons describing 
intersections between two polygons, but I cannot figure out how to 
obtain polygons describing intersections between more than two polygons 
like the central polygon drawn in the shape TEST_Union.
I repeat that the TEST_Union shapefile was simply obtained using the 
"union (analysis)" tool in ESRI ArcGIS.

Any other help?
Thank you.



------------------------------

Message: 11
Date: Thu, 8 Jul 2010 09:25:21 +0200
From: "Sorin Dudui" <sd at wigeogis.com>
Subject: [postgis-users] Index on the Geomtery Column and
	GEOMETRYCOLLECTION	EMPTY
To: <postgis-users at postgis.refractions.net>
Message-ID: <35931C28BB4740469732155F61C96515 at wigeo.lan>
Content-Type: text/plain;	charset="iso-8859-1"

 

Hello,

We have tables that contains both multi-polygons and empty geometries
(MULTIPOLYGON EMPTY). The table has an index on the geometry column. After
some updates with empty polygons the index becomes corrupt and we receive
the error 

"Relate Operation called with a LWGEOMCOLLECTION type.  This is unsupported
change argument GEOMETRYCOLLECTION EMPTY" 

when we make a spatial selection (ST_Intersects) with a polygon. ST_IsValid
returns true for all geometries.


If we delete the index the spatial query works without issues. For the
moment our workaround is using permanent a  "not st_isEmpty) in the where
clause. 


Thank you,
Sorin





-----Urspr?ngliche Nachricht-----
Von: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] Im Auftrag von
postgis-users-request at postgis.refractions.net
Gesendet: Mittwoch, 7. Juli 2010 21:00
An: postgis-users at postgis.refractions.net
Betreff: postgis-users Digest, Vol 99, Issue 7

Send postgis-users mailing list submissions to
	postgis-users at postgis.refractions.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://postgis.refractions.net/mailman/listinfo/postgis-users
or, via email, send a message with subject or body 'help' to
	postgis-users-request at postgis.refractions.net

You can reach the person managing the list at
	postgis-users-owner at postgis.refractions.net

When replying, please edit your Subject line so it is more specific than
"Re: Contents of postgis-users digest..."


Today's Topics:

   1. Sol Katz Award 2010 Nomination Call (Paul Ramsey)
   2. ESRI union (analysis) in Postgis (Teresa Fazio)
   3. Re: ESRI union (analysis) in Postgis (Ralf Suhr)
   4. Re: error updating multipoint: violates check constraint
      enforce_geotype (Biddy)
   5. manual binaries install for windows (Paul Hastings)
   6. Re: Invalid geometry when using select AsText (Lu?s de Sousa)
   7. Re: manual binaries install for windows (Paragon Corporation)
   8. Re: error updating multipoint: violates check	constraint
      enforce_geotype (Nicolas Ribot)
   9. Re: error updating multipoint: violates check	constraint
      enforce_geotype (Nicolas Ribot)
  10. Re: error updating multipoint: violates check	constraint
      enforce_geotype (Lu?s de Sousa)
  11. Re: WKT raster installation on mac (Shaun Langley)
  12. Projection(s) for global point-and-radius searches (David Jantzen)
  13. Re: Projection(s) for global point-and-radius	searches
      (Paul Ramsey)


----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Jul 2010 13:00:15 -0700
From: Paul Ramsey <pramsey at cleverelephant.ca>
Subject: [postgis-users] Sol Katz Award 2010 Nomination Call
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTimlx4sLApPFhxXzpeiOBPLboeC3Wuk-0EWoYq64 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

The Open Source Geospatial Foundation would like to open nominations for the
2010 Sol Katz Award for Geospatial Free and Open Source Software.

The Sol Katz Award for Geospatial Free and Open Source Software
(GFOSS) will be given to individuals who have demonstrated leadership in the
GFOSS community. Recipients of the award will have contributed significantly
through their activities to advance open source ideals in the geospatial
realm.

Sol Katz was an early pioneer of GFOSS and left behind a large body of work
in the form of applications, format specifications, and utilities while at
the U.S. Bureau of Land Management. This early GFOSS archive provided both
source code and applications freely available to the community. Sol was also
a frequent contributor to many geospatial list servers, providing much
guidance to the geospatial community at large.

Sol unfortunately passed away in 1999 from Non-Hodgkin's Lymphoma, but his
legacy lives on in the open source world. Those interested in making a
donation to the American Cancer Society, as per Sol's family's request, can
do so at https://www.cancer.org/involved/donate/donateonlinenow/index.

Nominations for the Sol Katz Award should be sent to SolKatzAward at osgeo.org
with a description of the reasons for this nomination. Nominations will be
accepted until 23:59 UTC on August 20th
(http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=20&year=20
10&hour=23&min=59&sec=59).
A recipient will be decided from the nomination list by an OSGeo designated
selection committee.

The winner of the Sol Katz Award for Geospatial Free and Open Source
Software will be announced on September 9th at the FOSS4G 2010 conference
(http://2010.foss4g.org/) closing plenary in Barcelona, Spain. The hope is
that the award will both acknowledge the work of community members, and pay
tribute to one of its founders, for years to come.

It should be noted that past awardees and selection committee members are
not eligible.

Past Awardees:

 2009: Daniel Morissette
 2008: Paul Ramsey
 2007: Steve Lime
 2006: Markus Neteler
 2005: Frank Warmerdam

Selection Committee:

 Jeff McKenna (chair)
 Daniel Morissette
 Frank Warmerdam
 Markus Neteler
 Steve Lime
 Paul Ramsey
 Sophia Parafina


------------------------------

Message: 2
Date: Wed, 07 Jul 2010 09:31:07 +0200
From: Teresa Fazio <fazio at planetek.it>
Subject: [postgis-users] ESRI union (analysis) in Postgis
To: postgis-users at postgis.refractions.net
Message-ID: <4C342D3B.6050301 at planetek.it>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"

I would like to perform in PostGIS a processing like that performed by the
union(analysis) tool of ArcGIS.
See here reference
http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Union_(Analysi
s)
<http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Union_%28Anal
ysis%29> 


It is very difficult to add some words to what it does, so I've attached two
layers before and after the union.

This tool repeats the new created geometries as many times as the number of
the geometries which partecipate to the intersection, populating the
attribute table with the relative generating geometry values.
So, after its execution, it allows you to perform a sum on a column
attribute grouping by geometry.

Maybe such an operation could be generated using aotmic PostGIS operators.

Thank you very much
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/x-zip-compressed
Size: 1985 bytes
Desc: not available
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100707
/d2872c8c/attachment-0001.bin>

------------------------------

Message: 3
Date: Wed, 7 Jul 2010 09:57:08 +0200
From: Ralf Suhr <Ralf.Suhr at itc-halle.de>
Subject: Re: [postgis-users] ESRI union (analysis) in Postgis
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <201007070957.08845.Ralf.Suhr at itc-halle.de>
Content-Type: Text/Plain;  charset="iso-8859-15"

Hi Teresa,

you can enhance the following construct to fit your needs.

CREATE VIEW fakeunion AS
  -- poly1 only
  SELECT a, b, NULL AS c, NULL AS d, geom
  FROM poly1
  WHERE gid NOT IN
    (
      SELECT p1.gid
      FROM poly1 p1
        INNER JOIN
        poly2 p2 ON (ST_Intersects(p1.geom,p2.geom))
    )
  -- poly2 only
  UNION
  SELECT NULL AS a, NULL AS b, c, d, geom
  FROM poly2
  WHERE gid NOT IN
    (
      SELECT p2.gid
      FROM poly2 p2
        INNER JOIN
        poly1 p1 ON (ST_Intersects(p1.geom,p2.geom))
    )
  -- poly1 & poly2
  UNION
  SELECT a, b, c, d, ST_Intersection(p1.geom, p2.geom) AS geom
  FROM poly2 p2
    INNER JOIN
    poly1 p1 ON (ST_Intersects(p1.geom,p2.geom))
  -- poly1 - poly2
  UNION
  SELECT a, b, NULL AS c, NULL AS d, ST_Difference(p1.geom, p2.geom) AS geom
  FROM poly2 p2
    INNER JOIN
    poly1 p1 ON (ST_Intersects(p1.geom,p2.geom))
  --  poly2 - poly1
  UNION
  SELECT NULL AS a, NULL AS b, c, d, ST_Difference(p2.geom, p1.geom) AS geom
  FROM poly2 p2
    INNER JOIN
    poly1 p1 ON (ST_Intersects(p1.geom,p2.geom)) ;

SELECT *
FROM fakeunion
WHERE ST_GeometryType(geom) = 'ST_LineString'

Gr
Ralf

Am Mittwoch 07 Juli 2010, 09:31:07 schrieb Teresa Fazio:
> I would like to perform in PostGIS a processing like that performed by 
> the union(analysis) tool of ArcGIS.
> See here reference
> http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Union_(A
> nalys
> is)
> <http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Union_%
> 28An
> alysis%29>
> 
> 
> It is very difficult to add some words to what it does, so I've 
> attached two layers before and after the union.
> 
> This tool repeats the new created geometries as many times as the 
> number of the geometries which partecipate to the intersection, 
> populating the attribute table with the relative generating geometry
values.
> So, after its execution, it allows you to perform a sum on a column 
> attribute grouping by geometry.
> 
> Maybe such an operation could be generated using aotmic PostGIS operators.
> 
> Thank you very much



------------------------------

Message: 4
Date: Wed, 07 Jul 2010 11:37:04 +0200
From: Biddy <newskatze at riomhphost.net>
Subject: Re: [postgis-users] error updating multipoint: violates check
	constraint enforce_geotype
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <20100707113704.17313x82l2el9k2s at webmail.df.eu>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
	format="flowed"

Hi,

Nicolas, thanks for your response.
I would hope that my query returns multipoints. At least it always has in
the test runs. For some reason when I let it run on our large dataset, it
doesn't work.

As a test I decided to skip that one troublesome column and load the other
points. But I get the same error for a different column now. On a dataset of
roughly 960k rows, I got the error 8 times.
I load data into several multipoint columns. For example, I have one column
that stores long, lat and alt as groups of multipoints with 1k points per
multipoint and then another column that stores x,y and z as groups of
multipoints with 1k points per multipoint. I have 6 of those multipoint
columns.

I am not sure if an ST_Multi around the ST_Union would do anything.

Does anybody have any ideas????

Any help is greatly appreciated, as I don't understand why this is happening
at all!!

B.

Quoting Nicolas Ribot <nicolas.ribot at gmail.com>:

>> Hi everyone,
>>
>> I have a program that updates a table containing multipoints.
>> Now, I have several columns with multipoints, but only one breaks 
>> with the following error:
>>
>> org.postgresql.util.PSQLException: ERROR: new row for relation
"lidarpoints"
>> violates check constraint "enforce_geotype_numtarclassidreflect"
>>
>> The code and setup for the other multipoint geometries is exactly the 
>> same, which is why I am surprised that it's not working for this one 
>> case. I feel I am overlooking something simple.
>>
>> My update sql is:
>> "update lidarpoints set numtarclassidreflect = 
>> ST_UNION(numtarclassidreflect,
>> ST_GeomFromEWKT('SRID=4326;MULTIPOINT(2 0
>> -1436)')) where lidarpts_id = currentRowID;"
>>
>> Does anybody know anything about this?
>>
>
> Hi,
>
> What is the geographic type of the ST_UNION returned by your query ?
> Can it be null, and no constraint allowing null geometries exists in 
> the table ?
>
> Nicolas
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>






------------------------------

Message: 5
Date: Wed, 07 Jul 2010 16:59:54 +0700
From: Paul Hastings <paul at sustainableGIS.com>
Subject: [postgis-users] manual binaries install for windows
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <4C34501A.60106 at sustainableGIS.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

i'm stuck at a univ where the network won't allow d/l of EXE files. i can't
see any ZIP, etc files for the windows install bits so....is there a
step-by-step walk thru for installing postGIS manually?

thanks.


------------------------------

Message: 6
Date: Wed, 7 Jul 2010 12:16:45 +0100
From: Lu?s de Sousa <luis.a.de.sousa at gmail.com>
Subject: Re: [postgis-users] Invalid geometry when using select AsText
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTilDBOA-_FkoftGvh8kUUnPzz3JcAwGOz1fMegtv at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

On Tue, Jul 6, 2010 at 2:45 PM, rdelisabeth <ramses.elisabeth at dans.knaw.nl>
wrote:
> "MULTIPOLYGON(((-203203.329774775 921205.762417328,-201414.754122524
> 920564.899066353,?.etc etc etc ??..,-263950.345631436
> 1215368.70793936,-263772.821121782 1216068.78335908,-263784.403196605
> 1216749.98205891,-263958.177279213 1216452.48684392)))"

Hi,

These are cartographic coordinates, you have to request the correct SRID
from whomever supplied you with the data.

Good luck,

Lu?s


------------------------------

Message: 7
Date: Wed, 7 Jul 2010 08:00:57 -0400
From: "Paragon Corporation" <lr at pcorp.us>
Subject: Re: [postgis-users] manual binaries install for windows
To: "'PostGIS Users Discussion'"
	<postgis-users at postgis.refractions.net>
Message-ID: <10BDC415B2574E9A8E53E8EFC6A6EB21 at J>
Content-Type: text/plain;	charset="us-ascii"

Paul,
There are zip binaries available

http://www.postgis.org/download/windows/

Scroll all the way to the bottom of the page where you see

PostGIS Binaries  - instructions are there

-- Also if you want to try the experimental ones -- which are at this point
just bug fixes to the stable branch, use these -- these are always packaged
as zip files and there is a readme on how to manually install

http://www.postgis.org/download/windows/experimental.php

 
Though can't help you too much with the PostgreSQL part.  

There is a Windows Portable GIS  flash project with PostGIS/PostgreSQL for
windows, that would do if you need PostgreSQL without installation also

http://www.archaeogeek.com/blog/portable-gis/  

It's a bit of a hefty download I think, but doesn't require any installation
at all -- just unzip and use (has a bunch of other goodies besides PostGIS
too :) 

Leo and Regina
http://www.postgis.us



-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
Hastings
Sent: Wednesday, July 07, 2010 6:00 AM
To: PostGIS Users Discussion
Subject: [postgis-users] manual binaries install for windows

i'm stuck at a univ where the network won't allow d/l of EXE files. i can't
see any ZIP, etc files for the windows install bits so....is there a
step-by-step walk thru for installing postGIS manually?

thanks.
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users




------------------------------

Message: 8
Date: Wed, 7 Jul 2010 14:13:32 +0200
From: Nicolas Ribot <nicolas.ribot at gmail.com>
Subject: Re: [postgis-users] error updating multipoint: violates check
	constraint enforce_geotype
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTinvqhhlUaM5bh9le0QcuYetluy1cLfZqVXkIta_ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> Hi,
>
> Nicolas, thanks for your response.
> I would hope that my query returns multipoints. At least it always has 
> in the test runs. For some reason when I let it run on our large 
> dataset, it doesn't work.
>
> As a test I decided to skip that one troublesome column and load the 
> other points. But I get the same error for a different column now. On 
> a dataset of roughly 960k rows, I got the error 8 times.
> I load data into several multipoint columns. For example, I have one 
> column that stores long, lat and alt as groups of multipoints with 1k 
> points per multipoint and then another column that stores x,y and z as 
> groups of multipoints with 1k points per multipoint. I have 6 of those 
> multipoint columns.
>
> I am not sure if an ST_Multi around the ST_Union would do anything.
>
> Does anybody have any ideas????
>
> Any help is greatly appreciated, as I don't understand why this is 
> happening at all!!
>

Hi,
What are the constraints defined for the table ? (\d lidarpoints in psql).
One row may return null or a geometryCollection, which is rejected by the
constraint.

You could test the update query by changing it to a select, to see what are
the returned type of the st_union:

select distinct st_geometryType(ST_UNION(numtarclassidreflect,
ST_GeomFromEWKT('SRID=4326;MULTIPOINT(2 0 -1436)'))) from lidarpoints where
lidarpts_id = currentRowID;

or maybe add a not null where clause, if it appears some rows are returning
null values.

Nicolas


------------------------------

Message: 9
Date: Wed, 7 Jul 2010 14:17:03 +0200
From: Nicolas Ribot <nicolas.ribot at gmail.com>
Subject: Re: [postgis-users] error updating multipoint: violates check
	constraint enforce_geotype
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTilnBKg8i5RbmZQh5iBaZ_pYGhtoQeKCfsPD4dau at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> Nicolas, thanks for your response.
> I would hope that my query returns multipoints. At least it always has 
> in the test runs. For some reason when I let it run on our large 
> dataset, it doesn't work.
>
> As a test I decided to skip that one troublesome column and load the 
> other points. But I get the same error for a different column now. On 
> a dataset of roughly 960k rows, I got the error 8 times.
> I load data into several multipoint columns. For example, I have one 
> column that stores long, lat and alt as groups of multipoints with 1k 
> points per multipoint and then another column that stores x,y and z as 
> groups of multipoints with 1k points per multipoint. I have 6 of those 
> multipoint columns.
>
> I am not sure if an ST_Multi around the ST_Union would do anything.

And yes, it may help to force a ST_MULTI, as st_union will try to return the
simplest possible type (if I recall correctly).

>
> Does anybody have any ideas????
>
> Any help is greatly appreciated, as I don't understand why this is 
> happening at all!!
>
> B.
>


------------------------------

Message: 10
Date: Wed, 7 Jul 2010 14:54:31 +0100
From: Lu?s de Sousa <luis.a.de.sousa at gmail.com>
Subject: Re: [postgis-users] error updating multipoint: violates check
	constraint enforce_geotype
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTiljIp_8rNje23JawE1TeLoL59gm_rJ6S9sVosuk at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 6, 2010 at 11:00 AM, Biddy <newskatze at riomhphost.net> wrote:
> org.postgresql.util.PSQLException: ERROR: new row for relation
"lidarpoints"
> violates check constraint "enforce_geotype_numtarclassidreflect"

Hi Biddy,

If you haven't changed the constraints created on the table by PostGis this
error means exactly that you are inserting a geometry that is not of the
type declared for the numtarclassidreflect column.

To sort this out you have to guarantee that all data feed into that column
is either a multipoint or null. I believe that ST_Multi solves your problem.

Lu?s


------------------------------

Message: 11
Date: Wed, 7 Jul 2010 12:08:30 -0400
From: Shaun Langley <shaunlangley at gmail.com>
Subject: Re: [postgis-users] WKT raster installation on mac
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <9CEA2D8E-8D5F-43E5-8357-8B84E1D21A50 at gmail.com>
Content-Type: text/plain; charset=iso-8859-1

I'm still getting stuck with this installation.  I specified the libdir, but
note that libpq is not in this directory.  The path for libpq is
"/Library/PostgreSQL/8.4/include" which is distinct from the other code
libraries in "/Library/PostgreSQL/8.4/lib"  I'm copying the directory
contents so you can clearly see what's included in each.

configure: error: could not find libpq
user-d0c71a:wktraster-0.1.6d langleys$ cd ../include/ user-d0c71a:include
langleys$ ls
ecpg_config.h		pg_config.h		pgtypes_numeric.h
ecpg_informix.h		pg_config_i386.h	pgtypes_timestamp.h
ecpgerrno.h		pg_config_manual.h	postgres_ext.h
ecpglib.h		pg_config_os.h		postgresql
ecpgtype.h		pg_config_ppc.h		sql3types.h
libpq			pgtypes_date.h		sqlca.h
libpq-events.h		pgtypes_error.h
libpq-fe.h		pgtypes_interval.h
user-d0c71a:include langleys$ 

user-d0c71a:include langleys$ cd ../lib
user-d0c71a:lib langleys$ ls
libecpg.6.1.dylib		libpq.dylib
libecpg.6.dylib			libproj.0.5.5.dylib
libecpg.a			libproj.0.dylib
libecpg.dylib			libproj.dylib
libecpg_compat.3.1.dylib	libuuid.16.dylib
libecpg_compat.3.dylib		libuuid.a
libecpg_compat.a		libuuid.dylib
libecpg_compat.dylib		libuuid.la
libgeos-3.2.0.dylib		libxml2.2.7.1.dylib
libgeos.dylib			libxml2.2.dylib
libgeos_c.1.6.0.dylib		libxml2.a
libgeos_c.1.dylib		libxml2.dylib
libgeos_c.dylib			libxml2.la
libpgport.a			libxslt.1.1.23.dylib
libpgtypes.3.1.dylib		libxslt.1.dylib
libpgtypes.3.dylib		libxslt.a
libpgtypes.a			libxslt.dylib
libpgtypes.dylib		libxslt.la
libpq.5.2.dylib			postgis-1.4.so
libpq.5.dylib			postgresql
libpq.a
user-d0c71a:lib langleys$ 

on the first line, you can clearly see that no matter which path I select
for "libdir" the configure script cannot find "libpq".  Any ideas?

Regards,
Shaun


On Jul 6, 2010, at 5:51 AM, Jorge Ar?valo wrote:

> On Mon, Jul 5, 2010 at 6:15 PM, Shaun Langley <shaunlangley at gmail.com>
wrote:
>> it returns /Library/PostgreSQL/8.4/lib
>> 
>> what's the option syntax to add the lib directory during 
>> configuration?  can I specify something like
>> 
>> --with-libdir='/Library/PostgreSQL/8.4/lib'
>> 
> 
> The option should be --libdir='/Library/PostgreSQL/8.4/lib'. Give it a 
> try
> 
> Best regards,
> Jorge
> 
> 
>> Cheers,
>> Shaun
>> On Jul 5, 2010, at 11:51 AM, Jorge Ar?valo wrote:
>> 
>>> On Mon, Jul 5, 2010 at 5:19 PM, Shaun Langley <shaunlangley at gmail.com>
wrote:
>>>> Yes it still complains it can't find libpq.
>>>> 
>>> 
>>> I didn't try it on mac, but in Windows, I had to add the lib directory
to PATH.
>>> 
>>> What happens if you execute pg_config --libdir?
>>> 
>>>> --------------------------
>>>> Shaun Langley
>>>> Graduate Student
>>>> 208 Manly Miles
>>>> Michigan State University
>>>> East Lansing, MI 48824
>>>> (517) 974-9346
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> 
>>>> On Jul 5, 2010, at 10:48 AM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
>>>> 
>>>>> So now that you had it manually does it still complain that it can not
find libpq?
>>>>> 
>>>>> Some systems need us to explicit some installation paths (like
Windows) in the configure command.
>>>>> 
>>>>> Pierre
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: postgis-users-bounces at postgis.refractions.net
>>>>>> [mailto:postgis-users- bounces at postgis.refractions.net] On Behalf 
>>>>>> Of Shaun Langley
>>>>>> Sent: 2 juillet 2010 19:14
>>>>>> To: postgis-users
>>>>>> Subject: [postgis-users] WKT raster installation on mac
>>>>>> 
>>>>>> I'm trying to install WKT Raster on Mac OS X, using the 
>>>>>> enterprisedb installation of postgres, and postgis through the 
>>>>>> stackbuilder.  I've run into a problem when running the 
>>>>>> ./configure for WKT Raster as it returns an error saying that it 
>>>>>> cannot locate libpq.  The installation of postgres is found at 
>>>>>> /Library/Postgres/8.4/ and libpq is located within lib/.  I had 
>>>>>> to manully specify the location of pg_config which I did
successfully.  Any suggestions on how to proceed?
>>>>>> 
>>>>>> Regards,
>>>>>> Shaun
>>>>>> --------------------------
>>>>>> Shaun Langley
>>>>>> Graduate Student, PhD
>>>>>> Department of Geography
>>>>>> Michigan State University
>>>>>> Home: (517) 974-9346
>>>>>> _______________________________________________
>>>>>> postgis-users mailing list
>>>>>> postgis-users at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>>> _______________________________________________
>>>>> postgis-users mailing list
>>>>> postgis-users at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Jorge Ar?valo
>>> DEIMOS Space
>>> Internet & Mobilty Division
>>> Ronda de Poniente 19. Edificio Fiteni VI, portal 2, 2?
>>> 28760 Tres Cantos (Madrid)
>>> Tel: +34 91 806 34 50 - ext: 155
>>> jorge.arevalo at deimos-space.com
>>> http://gis4free.wordpress.com
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
>> --------------------------
>> Shaun Langley
>> Graduate Student, PhD
>> Department of Geography
>> Michigan State University
>> Home: (517) 974-9346
>> 
>> 
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
> 
> 
> 
> --
> Jorge Ar?valo
> DEIMOS Space
> Internet & Mobilty Division
> Ronda de Poniente 19. Edificio Fiteni VI, portal 2, 2?
> 28760 Tres Cantos (Madrid)
> Tel: +34 91 806 34 50 - ext: 155
> jorge.arevalo at deimos-space.com
> http://gis4free.wordpress.com
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

--------------------------
Shaun Langley
Graduate Student, PhD
Department of Geography
Michigan State University
Home: (517) 974-9346




------------------------------

Message: 12
Date: Wed, 7 Jul 2010 11:19:51 -0700
From: David Jantzen <djantzen at ql2.com>
Subject: [postgis-users] Projection(s) for global point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <A697CFB8-5580-4BC9-9549-9ABEB1BE1509 at ql2.com>
Content-Type: text/plain; charset="us-ascii"

Hey All,

It's been a couple years but happily I have a reason to work with PostGIS
again!  I'm rusty, and this is pretty a basic question, so if you just
specify the chapter in TFM I'll happily go read it.

I need to do simple point-and-radius searches for some properties in
Germany.  Very soon I'll need to do this same thing across Europe and North
America, and some in Asia.  My understanding is that the accuracy of such
measurements will degrade as I use projections covering larger and larger
geographical areas. 

So, some questions:
1) Is there a single global projection that I could use for all such
calculations?  How bad would the distortions be and where?  
2) Assuming the correct path is to switch projections depending on area of
focus, what are some strategies for this kind of dynamic switching in SQL
queries?

Thanks for your help (and patience),
David

------------------------------

Message: 13
Date: Wed, 7 Jul 2010 11:40:43 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] Projection(s) for global point-and-radius
	searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTilME44WG6G6FGD6VH3F79Q_NFKtvAeQoZ5jyhV7 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

David,

Consider using the GEOGRAPHY type if your queries are just going to be
ST_DWithin style. That will remove all projection issues.

P.

On Wed, Jul 7, 2010 at 11:19 AM, David Jantzen <djantzen at ql2.com> wrote:
> Hey All,
>
> It's been a couple years but happily I have a reason to work with PostGIS
again! ?I'm rusty, and this is pretty a basic question, so if you just
specify the chapter in TFM I'll happily go read it.
>
> I need to do simple point-and-radius searches for some properties in
Germany. ?Very soon I'll need to do this same thing across Europe and North
America, and some in Asia. ?My understanding is that the accuracy of such
measurements will degrade as I use projections covering larger and larger
geographical areas.
>
> So, some questions:
> 1) Is there a single global projection that I could use for all such
calculations? ?How bad would the distortions be and where?
> 2) Assuming the correct path is to switch projections depending on area of
focus, what are some strategies for this kind of dynamic switching in SQL
queries?
>
> Thanks for your help (and patience),
> David
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


------------------------------

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


End of postgis-users Digest, Vol 99, Issue 7
********************************************



------------------------------

Message: 12
Date: Thu, 8 Jul 2010 09:44:15 +0200
From: Ralf Suhr <Ralf.Suhr at itc-halle.de>
Subject: Re: [postgis-users] ESRI union (analysis) in Postgis
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <201007080944.16078.Ralf.Suhr at itc-halle.de>
Content-Type: Text/Plain;  charset="iso-8859-1"

Hi Teresa,

you can't get a intersection from more then two polygons at a time. Think 
about the attributes you get. The attributes are from poly1 and or poly2.
The 
solution is to use only datasources with non overlaping polygons.

Gr
Ralf

Am Donnerstag 08 Juli 2010, 09:27:06 schrieb Teresa Fazio:
> The solution you propose is valid to get polygons describing
> intersections between two polygons, but I cannot figure out how to
> obtain polygons describing intersections between more than two polygons
> like the central polygon drawn in the shape TEST_Union.
> I repeat that the TEST_Union shapefile was simply obtained using the
> "union (analysis)" tool in ESRI ArcGIS.
> 
> Any other help?
> Thank you.
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users



------------------------------

Message: 13
Date: Thu, 08 Jul 2010 11:06:05 +0200
From: Birgit Laggner <birgit.laggner at vti.bund.de>
Subject: Re: [postgis-users] ESRI union (analysis) in Postgis
To: postgis-users at postgis.refractions.net
Message-ID: <4C3594FD.1030706 at vti.bund.de>
Content-Type: text/plain; charset="iso-8859-1"

Hi Teresa,

I'm struggeling with the translation of the union (analysis) tool of
ArcGIS into PostGIS myself since a while. The problem is, that in
PostGIS, you always compare one row of the first data set with one row
of the second data set. That means, that interaction of more than 2
polygons is always a problem... I try to solve it by using loops written
with pl/pgsql. They loop through all polygons of one data set and
compare every single polygon with all polygons of the other data set.
All polygons of the second data set that intersect with the reviewed
polygon of the first data set are written into a new table. As for the
difference part they are bundled with st_union and then st_difference is
performed with the polygon of the first data set. Regarding the
intersection part, st_intersection is performed for all combinations of
polygon (data set 1) and the intersecting polygons of data set 2. Then
the resulting polygons have to be intersected again in a loop until no
new intersections occur.

If you are interested, I could share the current state of my
experimentation with you... But don't expect too much - as Ralf already
said, allocation of attributes (and not only that) is very difficult.
But, unfortunately, most datasources, I have to use, contain overlapping
polygons. Therefore, I have to deal with that situation somehow as you
may have to do, too.

Regards,

Birgit.
> Hi Teresa,
>
> you can't get a intersection from more then two polygons at a time. Think 
> about the attributes you get. The attributes are from poly1 and or poly2.
The 
> solution is to use only datasources with non overlaping polygons.
>
> Gr
> Ralf
>
> Am Donnerstag 08 Juli 2010, 09:27:06 schrieb Teresa Fazio:
>   
>> > The solution you propose is valid to get polygons describing
>> > intersections between two polygons, but I cannot figure out how to
>> > obtain polygons describing intersections between more than two polygons
>> > like the central polygon drawn in the shape TEST_Union.
>> > I repeat that the TEST_Union shapefile was simply obtained using the
>> > "union (analysis)" tool in ESRI ArcGIS.
>> > 
>> > Any other help?
>> > Thank you.
>> > 
>> > _______________________________________________
>> > postgis-users mailing list
>> > postgis-users at postgis.refractions.net
>> > http://postgis.refractions.net/mailman/listinfo/postgis-users
>>     
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/be30ca79/attachment-0001.html>

------------------------------

Message: 14
Date: Thu, 08 Jul 2010 10:37:52 +0100
From: Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
Subject: Re: [postgis-users] Index on the Geomtery Column and
	GEOMETRYCOLLECTION EMPTY
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <4C359C70.1090100 at siriusit.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Sorin Dudui wrote:

> Hello,
> 
> We have tables that contains both multi-polygons and empty geometries
> (MULTIPOLYGON EMPTY). The table has an index on the geometry column. After
> some updates with empty polygons the index becomes corrupt and we receive
> the error 
> 
> "Relate Operation called with a LWGEOMCOLLECTION type.  This is
unsupported
> change argument GEOMETRYCOLLECTION EMPTY" 
> 
> when we make a spatial selection (ST_Intersects) with a polygon.
ST_IsValid
> returns true for all geometries.
> 
> 
> If we delete the index the spatial query works without issues. For the
> moment our workaround is using permanent a  "not st_isEmpty) in the where
> clause. 
> 
> 
> Thank you,
> Sorin

Hi Sorin,

In order to debug this, we need much more information such as the 
versions of PostgreSQL/PostGIS you are using and a simple, reproducable 
test case.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs


------------------------------

Message: 15
Date: Thu, 08 Jul 2010 11:53:35 +0200
From: Biddy <newskatze at riomhphost.net>
Subject: [postgis-users] lidar: what is the recommended way of
	storing/indexing
To: postgis-users at postgis.refractions.net
Message-ID: <20100708115335.99871n73g7k8yddw at webmail.df.eu>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
	format="flowed"

Hi everyone,

is there a recommended way of storing lidar data in postgis?

In particular, I am interested in not just storing long, lat, alt but  
also keeping all the raw data (for example range, target number,  
reflectance, etc.)

Regards,
B.




------------------------------

Message: 16
Date: Thu, 8 Jul 2010 06:25:13 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] Antwort: Re: Projection(s) for global
	point-and-radius searches
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTikcCRgyvsWzgKo2hl4wazAaIbEGlmb0y_g9xz2N at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

There is no spoon.

Why do you need ST_Expand()? If you're doing a distance query,
ST_DWIthin(thisgeog, thatgeog, radiusdouble) will create a fully
indexed query for you and return the right answers. You can look at
its definition under the covers to see what it's up to.

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L612

If you're working with geometry in 4326, well then, you're in a tough
spot, yes? That's why geography was invented. There's some hacks
available for you here:

http://trac.osgeo.org/postgis/wiki/UsersWikiExamplesFindNearbyLatLon

P.

On Wed, Jul 7, 2010 at 11:51 PM, Stefan Priess <Stefan.Priess at iav.de> wrote:
>
> Hey Paul,
>
> i need the ST_Expand() function with a radius/expand of 10 Meters, how i
will do that?
> The Point to expand is in SRID 4326 .
>
> Thanks
>
> Stefan
>
>
>
> Paul Ramsey <pramsey at opengeo.org>
> Gesendet von: postgis-users-bounces at postgis.refractions.net
>
> 07.07.2010 23:13
>
> Bitte antworten an
> PostGIS Users Discussion <postgis-users at postgis.refractions.net>
> An
> PostGIS Users Discussion <postgis-users at postgis.refractions.net>
> Kopie
> Thema
> Re: [postgis-users] Projection(s) for global point-and-radius ? ? ?
?searches
>
>
>
>
> No, because the functions on Geometry(4326) don't return metric answers.
>
> SELECT
> ?ST_Distance('SRID=4326;POINT(0 0)'::geometry, 'SRID=4326;POINT(1
> 1)'::geometry) as geom,
> ?ST_Distance('POINT(0 0)'::geography, 'POINT(1 1)'::geography) as geog;
>
> Geography understands that it's on a sphere and does the Right Thing.
> Geometry(4326) still operates on a cartesian plane, it just has
> "units" of degrees (which is pretty nonsensical for any kind of
> measurement calculation).
>
> P
>
> On Wed, Jul 7, 2010 at 2:03 PM, David Jantzen <djantzen at ql2.com> wrote:
> > Ok, interesting. ?Is it equivalent then to using a GEOMETRY type with
SRID 4326?
> >
> > On Jul 7, 2010, at 12:25 PM, Paul Ramsey wrote:
> >
> >> On Wed, Jul 7, 2010 at 12:25 PM, Paul Ramsey <pramsey at opengeo.org>
wrote:
> >>> ST_Buffer(geography, float8) returns geography
> >>> ST_Intersection(geography, geography) returns geography
> >>
> >> These last two actually *do* carry out projections under the covers,
> >> so watch out.
> >>
> >> P
> >> _______________________________________________
> >> postgis-users mailing list
> >> postgis-users at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


------------------------------

Message: 17
Date: Thu, 8 Jul 2010 06:27:53 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] lidar: what is the recommended way of
	storing/indexing
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTilj8cOFl7wNEeW5YyfX5SFKupXeGn-kBYAYV6ju at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

There is no recommended way right now. It's a core development
activity I'd love to have funded... :)

http://opengeo.org/products/coredevelopment/postgis/pointclouds/

In the meanwhile a approach might be to put the x/y/z into a postgis
geometry and stuff the rest of the data into an array of doubles in
another column. Your app would need to know which array element was
which kind of data, but you'd still have it all available.

P.

On Thu, Jul 8, 2010 at 2:53 AM, Biddy <newskatze at riomhphost.net> wrote:
> Hi everyone,
>
> is there a recommended way of storing lidar data in postgis?
>
> In particular, I am interested in not just storing long, lat, alt but also
> keeping all the raw data (for example range, target number, reflectance,
> etc.)
>
> Regards,
> B.
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>


------------------------------

Message: 18
Date: Thu, 8 Jul 2010 06:29:34 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] lidar: what is the recommended way of
	storing/indexing
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTilgFs1vR5ZCkKy3ECu9pDE9tokfqX7Aks9YQadV at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Oh, actually one-row-per-point is a bad idea, because the size of
lidar sets mitigates against that. Putting them into multipoint
collections of 50 or 100 points is better. But that implies
preprocessing things a bit to find good patches. In generally, there's
a lot of tooling needed to do this well, I fear.

P

On Thu, Jul 8, 2010 at 6:27 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> There is no recommended way right now. It's a core development
> activity I'd love to have funded... :)
>
> http://opengeo.org/products/coredevelopment/postgis/pointclouds/
>
> In the meanwhile a approach might be to put the x/y/z into a postgis
> geometry and stuff the rest of the data into an array of doubles in
> another column. Your app would need to know which array element was
> which kind of data, but you'd still have it all available.
>
> P.
>
> On Thu, Jul 8, 2010 at 2:53 AM, Biddy <newskatze at riomhphost.net> wrote:
>> Hi everyone,
>>
>> is there a recommended way of storing lidar data in postgis?
>>
>> In particular, I am interested in not just storing long, lat, alt but
also
>> keeping all the raw data (for example range, target number, reflectance,
>> etc.)
>>
>> Regards,
>> B.
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>


------------------------------

Message: 19
Date: Thu, 8 Jul 2010 15:31:48 +0200
From: Peter Baumann <p.baumann at jacobs-university.de>
Subject: Re: [postgis-users] lidar: what is the recommended way	of
	storing/indexing
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID: <4C35D344.60803 at jacobs-university.de>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Indeed, a column store for arrays is usually quite ;-) inefficient.
Let me point you to the rasdaman array DBMS which plugs into PostgreSQL 
and offers an optimized array query language on top. See www.rasdaman.org.

-Peter




Paul Ramsey wrote:
> Oh, actually one-row-per-point is a bad idea, because the size of
> lidar sets mitigates against that. Putting them into multipoint
> collections of 50 or 100 points is better. But that implies
> preprocessing things a bit to find good patches. In generally, there's
> a lot of tooling needed to do this well, I fear.
>
> P
>
> On Thu, Jul 8, 2010 at 6:27 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
>   
>> There is no recommended way right now. It's a core development
>> activity I'd love to have funded... :)
>>
>> http://opengeo.org/products/coredevelopment/postgis/pointclouds/
>>
>> In the meanwhile a approach might be to put the x/y/z into a postgis
>> geometry and stuff the rest of the data into an array of doubles in
>> another column. Your app would need to know which array element was
>> which kind of data, but you'd still have it all available.
>>
>> P.
>>
>> On Thu, Jul 8, 2010 at 2:53 AM, Biddy <newskatze at riomhphost.net> wrote:
>>     
>>> Hi everyone,
>>>
>>> is there a recommended way of storing lidar data in postgis?
>>>
>>> In particular, I am interested in not just storing long, lat, alt but
also
>>> keeping all the raw data (for example range, target number, reflectance,
>>> etc.)
>>>
>>> Regards,
>>> B.
>>>
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>       
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>   

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 147737)
   www.rasdaman.com, mail: baumann at rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis
ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
10xx)



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/cba62068/attachment-0001.html>

------------------------------

Message: 20
Date: Thu, 8 Jul 2010 12:22:52 -0400
From: "Paragon Corporation" <lr at pcorp.us>
Subject: Re: [postgis-users] lidar: what is the recommended	wayof
	storing/indexing
To: "'PostGIS Users Discussion'"
	<postgis-users at postgis.refractions.net>
Message-ID: <E0A44CB8960F429D815B99508F0F86EB at J>
Content-Type: text/plain; charset="us-ascii"

Okay since everyone is providing their suggestions, let me provide my less
than educated suggestion based on my fuzzy assumption of how Lidar is
structured.
 
Why don't you just use the new WKT Raster (PostGIS raster storage)?  It
allows you to store multiple bands per pixel.  I think you might even be
able to use GDAL to load the Lidar data right in ot the PostGIS raster
storage format given this bug fix.
 
http://trac.osgeo.org/gdal/ticket/3523
 
So I'm  imaging your z, range, target number, reflectance you would store as
separate raster bands.
 
Pierre and Jorge can correct me, but I don't think there is a limit on the
number of raster bands you can store per raster tile
 
http://www.postgis.org/documentation/manual-svn/RT_reference.html
 
With that you can do spatial intersects queries to pull out the different
band values with 
 
http://www.postgis.org/documentation/manual-svn/RT_ST_Intersection.html
 
or 
 
http://www.postgis.org/documentation/manual-svn/RT_ST_Value.html
 
The meta data function would be useful for letting you know how many bands
you have etc.
 
http://www.postgis.org/documentation/manual-svn/RT_ST_MetaData.html
 
Hope that helps,
Regina

  _____  

From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Peter
Baumann
Sent: Thursday, July 08, 2010 9:32 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] lidar: what is the recommended wayof
storing/indexing


Indeed, a column store for arrays is usually quite ;-) inefficient.
Let me point you to the rasdaman array DBMS which plugs into PostgreSQL and
offers an optimized array query language on top. See www.rasdaman.org.

-Peter




Paul Ramsey wrote: 

Oh, actually one-row-per-point is a bad idea, because the size of

lidar sets mitigates against that. Putting them into multipoint

collections of 50 or 100 points is better. But that implies

preprocessing things a bit to find good patches. In generally, there's

a lot of tooling needed to do this well, I fear.



P



On Thu, Jul 8, 2010 at 6:27 AM, Paul Ramsey  <mailto:pramsey at opengeo.org>
<pramsey at opengeo.org> wrote:

  

There is no recommended way right now. It's a core development

activity I'd love to have funded... :)



http://opengeo.org/products/coredevelopment/postgis/pointclouds/



In the meanwhile a approach might be to put the x/y/z into a postgis

geometry and stuff the rest of the data into an array of doubles in

another column. Your app would need to know which array element was

which kind of data, but you'd still have it all available.



P.



On Thu, Jul 8, 2010 at 2:53 AM, Biddy  <mailto:newskatze at riomhphost.net>
<newskatze at riomhphost.net> wrote:

    

Hi everyone,



is there a recommended way of storing lidar data in postgis?



In particular, I am interested in not just storing long, lat, alt but also

keeping all the raw data (for example range, target number, reflectance,

etc.)



Regards,

B.





_______________________________________________

postgis-users mailing list

postgis-users at postgis.refractions.net

http://postgis.refractions.net/mailman/listinfo/postgis-users



      

_______________________________________________

postgis-users mailing list

postgis-users at postgis.refractions.net

http://postgis.refractions.net/mailman/listinfo/postgis-users

  


-- 

Dr. Peter Baumann

 - Professor of Computer Science, Jacobs University Bremen

   www.faculty.jacobs-university.de/pbaumann

   mail: p.baumann at jacobs-university.de

   tel: +49-421-200-3178, fax: +49-421-200-493178

 - Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com, mail: baumann at rasdaman.com

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis
ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
10xx)




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/345210a0/attachment-0001.html>

------------------------------

Message: 21
Date: Thu, 8 Jul 2010 09:26:52 -0700
From: Paul Ramsey <pramsey at opengeo.org>
Subject: Re: [postgis-users] lidar: what is the recommended wayof
	storing/indexing
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<AANLkTik-VAk6jc1Ca2_uqhd5t2UdVWw75jEP9cpqc-XN at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Generally (raw) LIDAR data is not on a regular grid, it's irregular.
So it's not a raster problem it's a billions-of-points problem, and
not just a billions-of-points problem, but a
billions-of-hyper-dimensional-points problem (though the indexing can
be in just 2- or 3-d, really). So grid-based solutions aren't really
going to do it.

P.

On Thu, Jul 8, 2010 at 9:22 AM, Paragon Corporation <lr at pcorp.us> wrote:
> Okay since everyone is providing their suggestions, let me provide my less
> than educated suggestion based on my fuzzy assumption of how Lidar is
> structured.
>
> Why don't you just use the new WKT Raster (PostGIS raster storage)?? It
> allows you to store multiple bands per pixel.? I think you might even be
> able to use GDAL to load the Lidar data right in ot the PostGIS raster
> storage format?given this bug fix.
>
> http://trac.osgeo.org/gdal/ticket/3523
>
> So I'm ?imaging your z, range, target number, reflectance you would store
as
> separate raster bands.
>
> Pierre and Jorge can correct me, but I don't think there is a limit on the
> number of raster bands you can store per raster tile
>
> http://www.postgis.org/documentation/manual-svn/RT_reference.html
>
> With that you can do spatial intersects queries to pull out the different
> band values with
>
> http://www.postgis.org/documentation/manual-svn/RT_ST_Intersection.html
>
> or
>
> http://www.postgis.org/documentation/manual-svn/RT_ST_Value.html
>
> The meta data function would be useful for letting you know how many bands
> you have etc.
>
> http://www.postgis.org/documentation/manual-svn/RT_ST_MetaData.html
>
> Hope that helps,
> Regina
> ________________________________
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Peter
> Baumann
> Sent: Thursday, July 08, 2010 9:32 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] lidar: what is the recommended wayof
> storing/indexing
>
> Indeed, a column store for arrays is usually quite ;-) inefficient.
> Let me point you to the rasdaman array DBMS which plugs into PostgreSQL
and
> offers an optimized array query language on top. See www.rasdaman.org.
>
> -Peter
>
>
>
>
> Paul Ramsey wrote:
>
> Oh, actually one-row-per-point is a bad idea, because the size of
> lidar sets mitigates against that. Putting them into multipoint
> collections of 50 or 100 points is better. But that implies
> preprocessing things a bit to find good patches. In generally, there's
> a lot of tooling needed to do this well, I fear.
>
> P
>
> On Thu, Jul 8, 2010 at 6:27 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
>
>
> There is no recommended way right now. It's a core development
> activity I'd love to have funded... :)
>
> http://opengeo.org/products/coredevelopment/postgis/pointclouds/
>
> In the meanwhile a approach might be to put the x/y/z into a postgis
> geometry and stuff the rest of the data into an array of doubles in
> another column. Your app would need to know which array element was
> which kind of data, but you'd still have it all available.
>
> P.
>
> On Thu, Jul 8, 2010 at 2:53 AM, Biddy <newskatze at riomhphost.net> wrote:
>
>
> Hi everyone,
>
> is there a recommended way of storing lidar data in postgis?
>
> In particular, I am interested in not just storing long, lat, alt but also
> keeping all the raw data (for example range, target number, reflectance,
> etc.)
>
> Regards,
> B.
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> --
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann at jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 147737)
>    www.rasdaman.com, mail: baumann at rasdaman.com
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis
> ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
> destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
> 10xx)
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>


------------------------------

Message: 22
Date: Thu, 8 Jul 2010 12:37:41 -0400
From: Pierre Racine <Pierre.Racine at sbf.ulaval.ca>
Subject: Re: [postgis-users] lidar: what is the	recommended	wayof
	storing/indexing
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Message-ID:
	<87A96661E65C5541AB4D20721C2DD7F880A31689A6 at EXCH-MBX-A.ulaval.ca>
Content-Type: text/plain; charset="us-ascii"

Regina,

there is no real limits on the number of bands but I tend to agree with
Paul: you can convert a lidar coverage to a grid but this is a lossy
operation like converting a vector coverage to raster. The amount of
information you lose is dependent on the resolution of the target raster and
there is no perfect resolution (only 0 which is impossible).

Pierre

From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paragon
Corporation
Sent: 8 juillet 2010 12:23
To: 'PostGIS Users Discussion'
Subject: Re: [postgis-users] lidar: what is the recommended wayof
storing/indexing

Okay since everyone is providing their suggestions, let me provide my less
than educated suggestion based on my fuzzy assumption of how Lidar is
structured.

Why don't you just use the new WKT Raster (PostGIS raster storage)?  It
allows you to store multiple bands per pixel.  I think you might even be
able to use GDAL to load the Lidar data right in ot the PostGIS raster
storage format given this bug fix.

http://trac.osgeo.org/gdal/ticket/3523

So I'm  imaging your z, range, target number, reflectance you would store as
separate raster bands.

Pierre and Jorge can correct me, but I don't think there is a limit on the
number of raster bands you can store per raster tile

http://www.postgis.org/documentation/manual-svn/RT_reference.html

With that you can do spatial intersects queries to pull out the different
band values with

http://www.postgis.org/documentation/manual-svn/RT_ST_Intersection.html

or

http://www.postgis.org/documentation/manual-svn/RT_ST_Value.html

The meta data function would be useful for letting you know how many bands
you have etc.

http://www.postgis.org/documentation/manual-svn/RT_ST_MetaData.html

Hope that helps,
Regina

________________________________
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Peter
Baumann
Sent: Thursday, July 08, 2010 9:32 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] lidar: what is the recommended wayof
storing/indexing
Indeed, a column store for arrays is usually quite ;-) inefficient.
Let me point you to the rasdaman array DBMS which plugs into PostgreSQL and
offers an optimized array query language on top. See
www.rasdaman.org<http://www.rasdaman.org>.

-Peter




Paul Ramsey wrote:

Oh, actually one-row-per-point is a bad idea, because the size of

lidar sets mitigates against that. Putting them into multipoint

collections of 50 or 100 points is better. But that implies

preprocessing things a bit to find good patches. In generally, there's

a lot of tooling needed to do this well, I fear.



P



On Thu, Jul 8, 2010 at 6:27 AM, Paul Ramsey
<pramsey at opengeo.org><mailto:pramsey at opengeo.org> wrote:



There is no recommended way right now. It's a core development

activity I'd love to have funded... :)



http://opengeo.org/products/coredevelopment/postgis/pointclouds/



In the meanwhile a approach might be to put the x/y/z into a postgis

geometry and stuff the rest of the data into an array of doubles in

another column. Your app would need to know which array element was

which kind of data, but you'd still have it all available.



P.



On Thu, Jul 8, 2010 at 2:53 AM, Biddy
<newskatze at riomhphost.net><mailto:newskatze at riomhphost.net> wrote:



Hi everyone,



is there a recommended way of storing lidar data in postgis?



In particular, I am interested in not just storing long, lat, alt but also

keeping all the raw data (for example range, target number, reflectance,

etc.)



Regards,

B.





_______________________________________________

postgis-users mailing list

postgis-users at postgis.refractions.net<mailto:postgis-users at postgis.refractio
ns.net>

http://postgis.refractions.net/mailman/listinfo/postgis-users





_______________________________________________

postgis-users mailing list

postgis-users at postgis.refractions.net<mailto:postgis-users at postgis.refractio
ns.net>

http://postgis.refractions.net/mailman/listinfo/postgis-users





--

Dr. Peter Baumann

 - Professor of Computer Science, Jacobs University Bremen

 
www.faculty.jacobs-university.de/pbaumann<http://www.faculty.jacobs-universi
ty.de/pbaumann>

   mail:
p.baumann at jacobs-university.de<mailto:p.baumann at jacobs-university.de>

   tel: +49-421-200-3178, fax: +49-421-200-493178

 - Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com<http://www.rasdaman.com>, mail:
baumann at rasdaman.com<mailto:baumann at rasdaman.com>

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis
ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
10xx)




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://postgis.refractions.net/pipermail/postgis-users/attachments/20100708
/9759ee8d/attachment-0001.html>

------------------------------

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


End of postgis-users Digest, Vol 99, Issue 8
********************************************




More information about the postgis-users mailing list