Re: Makefile syntax problem with 1.2/8.2?

Hi,

On Fri, 2006-12-29 at 00:33 +0100, strk <at> refractions.net wrote:

> Confirmed, committed a fix for that fix (a missing -L, and 
> a missing post-commit test by the original reporter of
> the original bug, so please whoever had this problem test
> it now :) 

Thanks, that made it.

Regards,
--

-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

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

Re: Finding Points with distance to a location.

> SELECT
>     location_id,
>     distance_spheroid (
>         point_geom,
>         SetSRID(MakePoint(-117.12538, 32.6857),4326),
>         'SPHEROID["WGS_1984",6378137,298.257223563]'
>     )
> FROM
>     locations
> ORDER BY
>     distance_spheroid(
>         point_geom,
>         SetSRID( MakePoint( -117.13538, 32.6857 ), 4326 ),
>         'SPHEROID["WGS_1984",6378137,298.257223563]'
>     )
>
>

You can even give an alias name to your distance_spheroid column (with
the "as <col_name>" syntax) in order to make your query more readable:

 SELECT
     location_id,
     distance_spheroid (
         point_geom,
         SetSRID(MakePoint(-117.12538, 32.6857),4326),
         'SPHEROID["WGS_1984",6378137,298.257223563]'
     ) as dist
 FROM
     locations

[BUGS] ERROR: XX000: function 60821C60 returned NULL

I asked the pgsql-bugs - (there comments below) and they think its a
PostGIS issue.  I do have a gist index on the_point field.  I think it
does cause a core dump since if I am connected via PgAdmin immediately
after doing a load, my connection is broken and I have to connect again.
I forgot to mention I update the_point field after the data is loaded,
but during load the_point is null and again I suspect it has something
to do with the frequency of my load since the other tables are fine (and
this is fine for a while and then it starts happening).

Thanks,
Regina

I'm running "POSTGIS="1.1.6" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.5.0,
22 Oct 2006" USE_STATS"
 ---------------------------------COMMENT FROM Ogbugs
-------------------------------
That's a pretty low-level error; you shouldn't be able to trigger it
yourself without writing your own datatype or some such. Given the set
of types in your table, I'm betting that the bug is actually in PostGIS,
either in the geometry input converter or one of the index support
functions for geometry (you didn't show an index on the_point, but is
there one?). Try asking over there if they know of any such problems as
of 8.2.

regards, tom lane

--------------------
________________________________

From: Obe, Regina 

touches() not returning correct values, maybe?

I've been examining postgis for a little while (for production, teaching,
and research) and so far I'm very pleased with the results. I only wish
Arc/Info had SQL like this!

I've been loading shape files, generating adjacency lists, and then
exporting the results to a text file for a project and noticed the
touches() function isn't returning the correct results.

I've got two polygons (out of 53) that contain common points (from R),

> dp.stands$Shapes[[1]]$verts
          [,1]     [,2]
 [1,] 500141.9 505664.9
 [2,] 500237.9 505734.9
 [3,] 500435.0 505821.6
 [4,] 500435.0 504810.6
 [5,] 500167.6 504636.5
 [6,] 500143.3 504616.9
 [7,] 500143.1 504616.5
 [8,] 500142.8 504616.3
 [9,] 499962.4 504434.0
[10,] 499962.2 504433.7
[11,] 499950.9 504420.8
[12,] 499788.2 504212.4
[13,] 499786.5 504209.5
[14,] 499782.8 504205.1
[15,] 499585.7 503918.4
[16,] 499584.0 503915.2
[17,] 499582.0 503912.7
[18,] 499391.4 503606.6

Re: touches() not returning correct values, maybe?

This seems to remedy this situation.

select
  t1.gid as gid,
  t2.gid as adj_gid
 from
  stands t1,
  stands t2
 where
  intersects( t1.boundary, t2.boundary ) AND
   t1.boundary && t2.boundary and
  Equals( t1.boundary, t2.boundary ) is FALSE
order by
	t1.gid,
	t2.gid;

So why is this different than

select
  t1.gid as gid,
  t2.gid as adj_gid
 from
  stands t1,
  stands t2
 where
  touches( t1.boundary, t2.boundary ) AND
   t1.boundary && t2.boundary and
order by
	t1.gid,
	t2.gid;

Re: Re: touches() not returning correct values, maybe?

Touches() is only true if the exteriors interact and the interiors do 
not. If your adjacent polygons overlap slightly, then they do not just 
touch.

P.

Jeff D. Hamann wrote:
> This seems to remedy this situation.
> 
> select
>   t1.gid as gid,
>   t2.gid as adj_gid
>  from
>   stands t1,
>   stands t2
>  where
>   intersects( t1.boundary, t2.boundary ) AND
>    t1.boundary && t2.boundary and
>   Equals( t1.boundary, t2.boundary ) is FALSE
> order by
> 	t1.gid,
> 	t2.gid;
> 
> So why is this different than
> 
> select
>   t1.gid as gid,
>   t2.gid as adj_gid
>  from
>   stands t1,

Re: Re: touches() not returning correct values, maybe?

Your working query can probably be speeded up a little by avoiding  
the geometric Equals and replacing it with an equality test on your  
gid (since you are self-joining the table).

Basically, intersects() pulls all the features with an interaction  
(edge or overlap) and that includes the feature interacting with  
itself. so:

select
   t1.gid as gid,
   t2.gid as adj_gid
from
   stands t1,
   stands t2
where
   t1.boundary && t2.boundary and
   t1.gid <> t2.gid and
   intersects( t1.boundary, t2.boundary )
order by
   t1.gid,
   t2.gid;

On 2-Jan-07, at 2:17 PM, Paul Ramsey wrote:

> Touches() is only true if the exteriors interact and the interiors  
> do not. If your adjacent polygons overlap slightly, then they do  
> not just touch.
>
> P.
>

Re: [BUGS] ERROR: XX000: function 60821C60 returned NULL

On Tue, 2007-01-02 at 15:52 -0500, Obe, Regina wrote:
> I asked the pgsql-bugs - (there comments below) and they think its a
> PostGIS issue.  I do have a gist index on the_point field.  I think it
> does cause a core dump since if I am connected via PgAdmin immediately
> after doing a load, my connection is broken and I have to connect again.
> I forgot to mention I update the_point field after the data is loaded,
> but during load the_point is null and again I suspect it has something
> to do with the frequency of my load since the other tables are fine (and
> this is fine for a while and then it starts happening).
> 
> Thanks,
> Regina

Hi Regina,

Do you have any NULL geometries in your point field? It could be that
you are finding this bug:
http://postgis.refractions.net/pipermail/postgis-devel/2006-December/002421.html. Could you
try applying the patch mentioned in the thread and see whether this helps you?

Kind regards,

Mark.

RE: [BUGS] ERROR: XX000: function 60821C60returned NULL

Looks like it could be related, but not quite what I'm experiencing.  I
am inserting all records and all coming in have NULL values. The only
thing that's different though is that the gist index already exists and
this table only has 50 records going into it - not the 459.  

It works for a while - like about 6 or 7 times of deleting all the
records and readding them and then it bombs after that.

I'll try to upgrade to the latest version and see if that fixes my
problem.

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces <at> postgis.refractions.net
[mailto:postgis-users-bounces <at> postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Wednesday, January 03, 2007 4:08 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] [BUGS] ERROR: XX000: function
60821C60returned NULL

On Tue, 2007-01-02 at 15:52 -0500, Obe, Regina wrote:
> I asked the pgsql-bugs - (there comments below) and they think its a 
> PostGIS issue.  I do have a gist index on the_point field.  I think it

> does cause a core dump since if I am connected via PgAdmin immediately

> after doing a load, my connection is broken and I have to connect

RE: [BUGS] ERROR: XX000: function 60821C60returned NULL

On Wed, 2007-01-03 at 08:58 -0500, Obe, Regina wrote:
> Looks like it could be related, but not quite what I'm experiencing.  I
> am inserting all records and all coming in have NULL values. The only
> thing that's different though is that the gist index already exists and
> this table only has 50 records going into it - not the 459.  
> 
> It works for a while - like about 6 or 7 times of deleting all the
> records and readding them and then it bombs after that.
> 
> I'll try to upgrade to the latest version and see if that fixes my
> problem.
> 
> Thanks,
> Regina

Hi Regina,

Bear in mind that indexes also carry information about rows present in
previous transactions which may have been deleted since the last vacuum
which may explain the symptoms you are seeing.

I'd first try to replicate Kevin's generate_series SQL statement to see
if that crashes your PostgreSQL installation - it may help show whether
this is the same bug or a different bug. Also, I'm afraid you'll have to
compile that latest SVN snapshot from the PostGIS website since there
hasn't been a release since strk committed a fix for the bug :(

Kind regards,

Mark.