From dwaine.santana at endlessalgae.com  Fri Jan  2 03:32:03 2009
From: dwaine.santana at endlessalgae.com (Dwaine Santana)
Date: 2 Jan 2009 06:32:03 -0500
Subject: [postgis-devel] Re: Happy New Year!
Message-ID: <E1LIiGO-0000TK-ML@li17-239.members.linode.com>

Happy New Year! 



<a href="http://www.roflposters.com">Motivational Posters</a>








From codesite-noreply at google.com  Sun Jan  4 04:25:50 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 12:25:50 +0000
Subject: [postgis-devel] Issue 61 in postgis: lack of support for South
	African projections
Message-ID: <0016369895bd4a481d045fa74602@google.com>

Updates:
	Status: Invalid

Comment #2 on issue 61 by mark.cav... at siriusit.co.uk: lack of support for  
South African projections
http://code.google.com/p/postgis/issues/detail?id=61

Closed due to lack of response.


Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 04:29:50 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 12:29:50 +0000
Subject: [postgis-devel] Issue 37 in postgis: ST_Intersection throws error
	on postgis Linux installation
Message-ID: <00151750e6929d80f6045fa7543b@google.com>

Updates:
	Status: Invalid

Comment #5 on issue 37 by mark.cav... at siriusit.co.uk: ST_Intersection  
throws error on postgis Linux installation
http://code.google.com/p/postgis/issues/detail?id=37

Closing due to lack of response.


Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 04:33:50 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 12:33:50 +0000
Subject: [postgis-devel] Issue 12 in postgis: precision problem in
	ST_Intersection 
Message-ID: <001517574664ec6237045fa762a2@google.com>


Comment #1 on issue 12 by mark.cav... at siriusit.co.uk: precision problem in  
ST_Intersection
http://code.google.com/p/postgis/issues/detail?id=12

Hi,

Have you tried this again with the latest PostGIS 1.3.5 and GEOS 3.0.3?  
There are a
number of precision fixes which may help you.


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 04:37:51 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 12:37:51 +0000
Subject: [postgis-devel] Issue 85 in postgis: ST_Distance crashes on
	Circular String
Message-ID: <0016362834ee3fc166045fa771f9@google.com>


Comment #3 on issue 85 by mark.cav... at siriusit.co.uk: ST_Distance crashes  
on Circular String
http://code.google.com/p/postgis/issues/detail?id=85

Right, looking closer at the source code it's fairly obvious why this is  
falling over
- the complete set of distance2d_curve_*() and distance2d_*_curve()  
functions are
missing from measures.c!

Anyone know how to measure distance from a curve? Looking at
lwgeom_curvepolygon_area() in the same file, it appears as if we should  
segmentize
the curve into 32 linear sections and use that...


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 05:33:58 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 13:33:58 +0000
Subject: [postgis-devel] Issue 91 in postgis: "makefile check" Shows check
	failed of sql-mm-circularstring in PostGIS
Message-ID: <000e0cd59fb0f016ef045fa839b3@google.com>

Status: New
Owner: ----

New issue 91 by vibhor.aim: "makefile check" Shows check failed of  
sql-mm-circularstring in PostGIS
http://code.google.com/p/postgis/issues/detail?id=91

What steps will reproduce the problem?
1. Download the product source
2. execute ./configure then make and make install
3. then execute make check

What is the expected output? What do you see instead?
Expected Output should succeeded. Following error came:

  sql-mm-circularstring. failed (diff expected
obtained: /tmp/pgis_reg_9121/test_28_diff)
  sql-mm-compoundcurve. failed (diff expected
obtained: /tmp/pgis_reg_9121/test_29_diff)
  sql-mm-curvepoly. failed (diff expected
obtained: /tmp/pgis_reg_9121/test_30_diff)

  sql-mm-multicurve. failed (diff expected
obtained: /tmp/pgis_reg_9121/test_32_diff)
  sql-mm-multisurface. failed (diff expected
obtained: /tmp/pgis_reg_9121/test_33_diff)

What version of the product are you using? On what operating system?
OS: Red Hat Enterprise Linux Server release 5 (Tikanga), 32 bit
PostGIS: 1.3.5
Postgresql: 8.3.5



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 10:34:53 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 18:34:53 +0000
Subject: [postgis-devel] Issue 85 in postgis: ST_Distance crashes on
	Circular String
Message-ID: <000e0cd6a8ac27fe84045fac6e65@google.com>

Updates:
	Status: Testing

Comment #4 on issue 85 by mark.cav... at siriusit.co.uk: ST_Distance crashes  
on Circular String
http://code.google.com/p/postgis/issues/detail?id=85

Quick fix applied to SVN trunk and 1.3 branch - i.e. we detect the  
CIRCULARSTRING and
throw an "Unsupported geometry type" error rather than crashing. The code  
for
calculating distance from a CIRCULARSTRING would require quite a bit of  
work, and
should only be added in 1.4 (trunk).

Regina, feel free to enable the CIRCULARSTRING tests once again in your  
garden XSL
generator once you are happy that this works.


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan  4 10:38:54 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 Jan 2009 18:38:54 +0000
Subject: [postgis-devel] Issue 91 in postgis: "makefile check" Shows check
	failed of sql-mm-circularstring in PostGIS
Message-ID: <0016361e88c67d4d5c045fac7c81@google.com>


Comment #1 on issue 91 by mark.cav... at siriusit.co.uk: "makefile check"  
Shows check failed of sql-mm-circularstring in PostGIS
http://code.google.com/p/postgis/issues/detail?id=91

Hi,

It all seems to work fine here so we need some more information - supplying  
the test
diffs in a .tar.gz file would be helpful here.


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at opengeo.org  Sun Jan  4 21:35:13 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Sun, 4 Jan 2009 21:35:13 -0800
Subject: [postgis-devel] GUI Time
Message-ID: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>

Hi folks,

My Christmas present to myself was trying to do a GUI for shape  
importing (and eventually exporting). It turned out the GUI wasn't too  
hard... unfortunately when it came time to bolt in the actual guts,  
the crufty legacy code got in the way... the assumption of emitting to  
stdout is pretty backed in. So getting this working is going to take a  
pretty radical re-work. I'll work off to the side of the existing  
code, and create three new bits:

shp2pgsql-core.c  - where the work gets done
shp2pgsql-gui.c  - the gui frontend
shp2pgsql-cli.c  - the commandline frontend

Best,

P.

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot_01.png
Type: image/png
Size: 48988 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090104/b31e4a45/attachment.png>

From mark.cave-ayland at siriusit.co.uk  Mon Jan  5 02:18:19 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 05 Jan 2009 10:18:19 +0000
Subject: [postgis-devel] GUI Time
In-Reply-To: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>
Message-ID: <4961DE6B.9090203@siriusit.co.uk>

Paul Ramsey wrote:

> Hi folks,
> 
> My Christmas present to myself was trying to do a GUI for shape 
> importing (and eventually exporting). It turned out the GUI wasn't too 
> hard... unfortunately when it came time to bolt in the actual guts, the 
> crufty legacy code got in the way... the assumption of emitting to 
> stdout is pretty backed in. So getting this working is going to take a 
> pretty radical re-work. I'll work off to the side of the existing code, 
> and create three new bits:
> 
> shp2pgsql-core.c  - where the work gets done
> shp2pgsql-gui.c  - the gui frontend
> shp2pgsql-cli.c  - the commandline frontend
> 
> Best,
> 
> P.

Yup indeed. I did some testing on liblwgeom over Christmas (see email to 
follow over the next few days) and realised that the existing dual 
memory model is just plain bad.

My feeling is that we need to get liblwgeom to the point where we can 
rip out the lwgeom_init_allocators() callback and handle the memory 
management/errors ourselves, so this would be one less thing for you to 
worry about.

But yeah, the loaders aren't the best example of C coding around and so 
I wouldn't be averse to them being reworked. Perhaps similar to 
liblwgeom you could make shp2pgsql-core.c a static library which gets 
linked into both the CLI and GUI versions? I'd suggest if this is major 
work then it should go into a separate branch so that trunk will work as 
is, and then import the code into trunk when you have something tested 
that works.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Mon Jan  5 02:39:17 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 05 Jan 2009 10:39:17 +0000
Subject: [postgis-devel] RFC: PostGIS 1.4 timeframe
Message-ID: <4961E355.5000505@siriusit.co.uk>

Hi folks,

I'm getting to point where I'd like to think about setting a release 
roadmap for 1.4 in order to get this code out in the open.

Reasons for pushing out a 1.4 sooner:


- 1.3.5 seems to be a relatively stable release; there are only a couple 
of fixes in 1.3 branch and so we can push out a 1.3.6 with reasonable 
amount of confidence. I know I'd much rather see Paul's recent new work 
in a 1.4 rather than having to backport it and support in 1.3 aswell - 
especially as we've promised not to break APIs on point releases :D

- No more endless backporting to 1.3 branch. Nuff said. The 1.4 code has 
been a lot longer in development than expected.

- As a developer, the tools for debugging and tracing bugs are a league 
above anything in 1.3 branch. I really would prefer never to have to 
track obscure bugs in the 1.3 branch ever again.

- Even with the new code/APIs in 1.4 (particularly in relation to the 
parser), we can still emulate the old behaviour and then move forward 
with something better in 1.5. At the very least, the new build system 
will get a really good workout.


I'm currently thinking something like a 1.3.6 release with the current 
fixes released around February, with a 1.4 release appearing a week or 
so after the Toronto Code Sprint mid-March.


Thoughts?

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Mon Jan  5 07:34:30 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 5 Jan 2009 07:34:30 -0800
Subject: [postgis-devel] GUI Time
In-Reply-To: <4961DE6B.9090203@siriusit.co.uk>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>
	<4961DE6B.9090203@siriusit.co.uk>
Message-ID: <2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>

shp2pgsql.c will remain, untouched. Once the new stuff is ready to  
test, I'll just commit it along-side. We can remove the old version  
once we're certain we like the new ones.

I'm planning on using the shp2pgsq-core.o object in both the  
executables, so that's kind of like a library :)

P.

On Jan 5, 2009, at 2:18 AM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>> Hi folks,
>> My Christmas present to myself was trying to do a GUI for shape  
>> importing (and eventually exporting). It turned out the GUI wasn't  
>> too hard... unfortunately when it came time to bolt in the actual  
>> guts, the crufty legacy code got in the way... the assumption of  
>> emitting to stdout is pretty backed in. So getting this working is  
>> going to take a pretty radical re-work. I'll work off to the side  
>> of the existing code, and create three new bits:
>> shp2pgsql-core.c  - where the work gets done
>> shp2pgsql-gui.c  - the gui frontend
>> shp2pgsql-cli.c  - the commandline frontend
>> Best,
>> P.
>
> Yup indeed. I did some testing on liblwgeom over Christmas (see  
> email to follow over the next few days) and realised that the  
> existing dual memory model is just plain bad.
>
> My feeling is that we need to get liblwgeom to the point where we  
> can rip out the lwgeom_init_allocators() callback and handle the  
> memory management/errors ourselves, so this would be one less thing  
> for you to worry about.
>
> But yeah, the loaders aren't the best example of C coding around and  
> so I wouldn't be averse to them being reworked. Perhaps similar to  
> liblwgeom you could make shp2pgsql-core.c a static library which  
> gets linked into both the CLI and GUI versions? I'd suggest if this  
> is major work then it should go into a separate branch so that trunk  
> will work as is, and then import the code into trunk when you have  
> something tested that works.
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS is Love.



From pramsey at opengeo.org  Mon Jan  5 07:36:14 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 5 Jan 2009 07:36:14 -0800
Subject: [postgis-devel] RFC: PostGIS 1.4 timeframe
In-Reply-To: <4961E355.5000505@siriusit.co.uk>
References: <4961E355.5000505@siriusit.co.uk>
Message-ID: <E8716963-F757-402F-B195-25FF94CB91EB@opengeo.org>


On Jan 5, 2009, at 2:39 AM, Mark Cave-Ayland wrote:

> I'm currently thinking something like a 1.3.6 release with the  
> current fixes released around February, with a 1.4 release appearing  
> a week or so after the Toronto Code Sprint mid-March.

Sounds good to me. One of the work items for code sprint, IMO, is a  
road-map document... any chance you'll be around, virtually at least,  
to work on that? I know what 1.3 is and what 1.4 is, but what's 1.5?

P.


--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From mark.cave-ayland at siriusit.co.uk  Mon Jan  5 14:11:45 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 05 Jan 2009 22:11:45 +0000
Subject: [postgis-devel] RFC: PostGIS 1.4 timeframe
In-Reply-To: <E8716963-F757-402F-B195-25FF94CB91EB@opengeo.org>
References: <4961E355.5000505@siriusit.co.uk>
	<E8716963-F757-402F-B195-25FF94CB91EB@opengeo.org>
Message-ID: <496285A1.3070901@siriusit.co.uk>

Paul Ramsey wrote:
> 
> On Jan 5, 2009, at 2:39 AM, Mark Cave-Ayland wrote:
> 
>> I'm currently thinking something like a 1.3.6 release with the current 
>> fixes released around February, with a 1.4 release appearing a week or 
>> so after the Toronto Code Sprint mid-March.
> 
> Sounds good to me. One of the work items for code sprint, IMO, is a 
> road-map document... any chance you'll be around, virtually at least, to 
> work on that? I know what 1.3 is and what 1.4 is, but what's 1.5?
> 
> P.

Possibly - I've only just got back after illness over Christmas/New Year 
so I've yet to find out about whether a trip to Toronto is possible or 
not. I guess if the meeting is on IRC I could always participate there...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Mon Jan  5 14:22:30 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 05 Jan 2009 22:22:30 +0000
Subject: [postgis-devel] Ramblings on CUnit and more...
Message-ID: <49628826.2010805@siriusit.co.uk>

Hi folks,

Over the weekend I spent some time looking at the CUnit tests and as a 
result have committed some fixes various bits of code to support this. 
In particular, I had to rework a lot of the Makefile to pass down the 
correct combination of compiler flags into the relevant places. The net 
result is that I can now run the CUnit tests under Win32 :)

Paul: I'm quite impressed with CUnit so far - it seems reasonably 
intuitive and simple to use. I'd like to suggest that we try and move as 
many regression tests as possible from the existing PostgreSQL 
regression set into CUnit, mainly because it's easier to keep updated (I 
don't have to worry about CR/LFs and obscure psql command lines) but 
also because the CUnit tests complete in a blink of an eye compared to 
the 10-15mins to run the existing test harness on Win32.

It looks like there are some warnings to do with unused 
variables/functions which should be fairly quick to fix but other than 
that, it looks good. I do have a minor niggle in that you've included 
some LWDEBUG(F) statements at level 1 which is marked as reserved in the 
DEBUG document - any chance we could bump them up to 3? The reason that 
level 1 is reserved is so that I can quickly use level 1 to debug a 
specific area of code without any other output which has been quite 
useful in the past.

Regina: Thinking about moving tests to CUnit, I just had a thought: does 
you garden-test SQL generator test the spatial operators such as &&?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Mon Jan  5 14:28:41 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 05 Jan 2009 22:28:41 +0000
Subject: [postgis-devel] GUI Time
In-Reply-To: <2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>	<4961DE6B.9090203@siriusit.co.uk>
	<2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>
Message-ID: <49628999.4030605@siriusit.co.uk>

Paul Ramsey wrote:

> shp2pgsql.c will remain, untouched. Once the new stuff is ready to test, 
> I'll just commit it along-side. We can remove the old version once we're 
> certain we like the new ones.
> 
> I'm planning on using the shp2pgsq-core.o object in both the 
> executables, so that's kind of like a library :)
> 
> P.

Cool. Will this work cross-platform, e.g. wxWidgets or similar?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Mon Jan  5 15:30:11 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 5 Jan 2009 15:30:11 -0800
Subject: [postgis-devel] Ramblings on CUnit and more...
In-Reply-To: <49628826.2010805@siriusit.co.uk>
References: <49628826.2010805@siriusit.co.uk>
Message-ID: <CDC41A38-FFB2-487F-B552-0AD98FD35F96@opengeo.org>


On Jan 5, 2009, at 2:22 PM, Mark Cave-Ayland wrote:

> It looks like there are some warnings to do with unused variables/ 
> functions which should be fairly quick to fix but other than that,  
> it looks good. I do have a minor niggle in that you've included some  
> LWDEBUG(F) statements at level 1 which is marked as reserved in the  
> DEBUG document - any chance we could bump them up to 3? The reason  
> that level 1 is reserved is so that I can quickly use level 1 to  
> debug a specific area of code without any other output which has  
> been quite useful in the past.

Please fee free to bump anything you don't like down to a level you  
want. That's me leaving my own debug blocks unchanged after a commit,  
which is silly, since the commit comes ones the debugging is through.

P.
>


--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From pramsey at cleverelephant.ca  Mon Jan  5 15:30:56 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 5 Jan 2009 15:30:56 -0800
Subject: [postgis-devel] GUI Time
In-Reply-To: <49628999.4030605@siriusit.co.uk>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>	<4961DE6B.9090203@siriusit.co.uk>
	<2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>
	<49628999.4030605@siriusit.co.uk>
Message-ID: <6264C3B2-B541-4235-A84A-79DC29A464EF@cleverelephant.ca>

Yes, it's GTK+, so we should be 100% cross platform. I'm sure  
compiling will be an adventure, but... :)

On Jan 5, 2009, at 2:28 PM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>> shp2pgsql.c will remain, untouched. Once the new stuff is ready to  
>> test, I'll just commit it along-side. We can remove the old version  
>> once we're certain we like the new ones.
>> I'm planning on using the shp2pgsq-core.o object in both the  
>> executables, so that's kind of like a library :)
>> P.
>
> Cool. Will this work cross-platform, e.g. wxWidgets or similar?
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From codesite-noreply at google.com  Tue Jan  6 03:01:13 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 Jan 2009 11:01:13 +0000
Subject: [postgis-devel] Issue 92 in postgis: Error in Estimated_Extent()
	when used with point geometry
Message-ID: <0016364ed2cc5c5850045fce53d2@google.com>

Status: New
Owner: ----

New issue 92 by aroranidh: Error in Estimated_Extent() when used with point  
geometry
http://code.google.com/p/postgis/issues/detail?id=92

What steps will reproduce the problem?
1. Create a Point Table in PostGIS 1.3.5 with PostGRE 8.3
2. SELECT estimated_extent('schema', 'table', 'geometry') AS env
3. Returns ERROR:  LWGEOM_estimated_extent: couldn't locate table within
current schema when used on a Point table. But it works fine for line table

What is the expected output? What do you see instead?
Extent of the Point table.
ERROR:  LWGEOM_estimated_extent: couldn't locate table within current
schema

What version of the product are you using? On what operating system?
PostGIS 1.3.5 with PostGRE 8.3 on Windows XP Professional SP2

Please provide any additional information below.
Below attached is the log file generated by MapGUIDE enterprise efition
2009
The Schema name and the table name are perfect.

Attachments:
	mgserver2009_fdopostgis.log  31.3 KB

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Tue Jan  6 03:32:22 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 Jan 2009 11:32:22 +0000
Subject: [postgis-devel] Issue 92 in postgis: Error in Estimated_Extent()
	when used with point geometry
Message-ID: <0016361e8868c441bb045fcec24e@google.com>


Comment #1 on issue 92 by mark.cav... at siriusit.co.uk: Error in  
Estimated_Extent() when used with point geometry
http://code.google.com/p/postgis/issues/detail?id=92

Hi,

estimated_extent() can only work after an ANALYZE on the database. What  
happens if
you issue an "ANALYZE mytable" after "CREATE mytable ( .. )" and then try  
using
estimated_extent()?


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From aengus.mccullough at newcastle.ac.uk  Tue Jan  6 06:27:22 2009
From: aengus.mccullough at newcastle.ac.uk (Aengus McCullough)
Date: Tue, 6 Jan 2009 14:27:22 +0000
Subject: [postgis-devel] transforming coordinates in postgis
Message-ID: <EMEW-l05ERN3fbd150f64a3d54c02aae3650e27c772-C16E6005552AAB4EAC67CB3190E9145025E7AA00A8@EXSAN03.campus.ncl.ac.uk>

Hi,
I am having difficulty transforming coordinates from EPSG:4326 to EPSG:27700 in POSTGIS.  The transformation executes successfully but is out by 100m in the Easting and 60m in the Northing.  Is this likely to be an error in the transformation parameters defined in the spatial_ref_sys relation?

Given the original coordinate in SRID 4326:   55.001428, -1.614208, when I run 'transform(geom,27700)' I get the result: 424687.13, 567430.91
This is substantially different from the converter on the Ordnance Survey website and the transformation functions in geotools.  Help! What am I doing wrong?


From mark.cave-ayland at siriusit.co.uk  Tue Jan  6 06:36:30 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 06 Jan 2009 14:36:30 +0000
Subject: [postgis-devel] transforming coordinates in postgis
In-Reply-To: <EMEW-l05ERN3fbd150f64a3d54c02aae3650e27c772-C16E6005552AAB4EAC67CB3190E9145025E7AA00A8@EXSAN03.campus.ncl.ac.uk>
References: <EMEW-l05ERN3fbd150f64a3d54c02aae3650e27c772-C16E6005552AAB4EAC67CB3190E9145025E7AA00A8@EXSAN03.campus.ncl.ac.uk>
Message-ID: <49636C6E.8080304@siriusit.co.uk>

Aengus McCullough wrote:

> Hi,
> I am having difficulty transforming coordinates from EPSG:4326 to EPSG:27700 in POSTGIS.  The transformation executes successfully but is out by 100m in the Easting and 60m in the Northing.  Is this likely to be an error in the transformation parameters defined in the spatial_ref_sys relation?
> 
> Given the original coordinate in SRID 4326:   55.001428, -1.614208, when I run 'transform(geom,27700)' I get the result: 424687.13, 567430.91
> This is substantially different from the converter on the Ordnance Survey website and the transformation functions in geotools.  Help! What am I doing wrong?

Hi Aengus,

Yeah this is a known issue - see 
http://postgis.refractions.net/pipermail/postgis-users/2008-October/021639.html 
for a solution.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Tue Jan  6 09:36:17 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 Jan 2009 17:36:17 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <0016361e883440dbc8045fd3d8e0@google.com>


Comment #1 on issue 90 by ke... at refractions.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

This is because this function is a wrapper for AddGeometryColumn(table_name,
column_name, srid, type, dimension), where the schemaname is obtained from  
the search
path.  You'd prefer that this is not the case?  The alternative would be  
duplicate
the code to the schema-qualified variant and simply error on an incorrect  
schemaname.
  If others are with you on this behaviour, it's certainly possible to  
change this.

As for the CONTEXT messages: whenever you raise a notice or error in  
plpgsql, a
context message is also displayed.  Unless someone knows how to separate  
this verbose
debugging information from a regular notice or error message, this is the  
best we can
do at the moment with plpgsql.  I suppose we could move these functions to  
C and
write error messages exactly as we see fit, but most people haven't seen  
the need for
that yet.

Hope this helps,
Kevin

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at opengeo.org  Tue Jan  6 09:59:15 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 6 Jan 2009 09:59:15 -0800
Subject: [postgis-devel] iconv + loader
Message-ID: <E8E31C7E-3562-4FCE-B9B6-84033631777C@opengeo.org>

I just noticed that we do our character transcoding inside the loader  
itself and "SET CLIENT_ENCODING = UTF8". Wouldn't it be a lot simpler  
to just "SET CLIENT_ENCODING = <encoding>" and dump the strings to the  
server to handle?

Anyone know the rationale for the current approach?

P

--
Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS is Love.



From codesite-noreply at google.com  Tue Jan  6 12:53:29 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 Jan 2009 20:53:29 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <001485f9143a78bab0045fd69969@google.com>


Comment #2 on issue 90 by reid at reidster.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

> This is because this function is a wrapper for  
AddGeometryColumn(table_name,
> column_name, srid, type, dimension), where the schemaname is obtained  
from the
> search path.  You'd prefer that this is not the case?  The alternative  
would be
> duplicate the code to the schema-qualified variant and simply error on an
> incorrect schemaname. If others are with you on this behaviour, it's  
certainly
> possible to change this.

Actually (in 1.3.3 at least), it seems that both  
AddGeometryColumn(table_name, ...)
and AddGeometryColumn(schema_name, ...) are wrappers for a third variant,
AddGeometryColumn(catalog_name, schema_name, table_name, ...).

As for a fix: can the RAISE NOTICE on line 2840 of lwpostgis.sql be  
replaced with
RAISE EXCEPTION and line 2841 deleted?

> As for the CONTEXT messages: whenever you raise a notice or error in  
plpgsql, a
> context message is also displayed.  Unless someone knows how to separate  
this
> verbose debugging information from a regular notice or error message,  
this is the
> best we can do at the moment with plpgsql.

That's a minor problem. I wouldn't be too sad if the CONTEXT remained.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Tue Jan  6 14:46:27 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 Jan 2009 22:46:27 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <0016e645b9b47e6629045fd82db4@google.com>


Comment #3 on issue 90 by ke... at refractions.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

> Actually (in 1.3.3 at least), it seems that both  
AddGeometryColumn(table_name, ...)

Yup, you're right, I was just simplifying my response.

> As for a fix: can the RAISE NOTICE on line 2840 of lwpostgis.sql be  
replaced with
RAISE EXCEPTION and line 2841 deleted?

Ah, I see what you're saying... yup, that works.  You should note that this  
has
already been fixed in SVN trunk.  This function was redone to remove all  
references
to current_schema() in favour of pg_table_is_visible() a while back.
http://code.google.com/p/postgis/issues/detail?id=74&can=1

If you want this fixed in your 1.3 branch, apply the attached patch.  I  
don't think
we can actually apply this patch to SVN since this is a behavioural change  
(albeit
small) to the function.  I would apply this to 1.4, but this has already  
been addressed.

If it ok with you, I'll close this ticket.

Cheers,
Kevin



Attachments:
	lwpostgis.sql.in.patch  449 bytes

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at cleverelephant.ca  Tue Jan  6 22:35:21 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 6 Jan 2009 22:35:21 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
Message-ID: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>

We seem to be suffering from a couple of massive memory leaks in liblwgeom.

The first one. While debugging the GUI, I noticed that it leaks gobs,
nay torrents, of memory. One leak was in the old loader code, or
perhaps was added during the lwgeom renovation. The other one was
harder to see. Valgrind insisted that memory allocated when building
pointarrays was not being freed. But the code block in the loader was
air-tight. Mark cleaned everything up. So, I went into liblwgeom, and
there, past the lwfree_polygon that Mark called, was the
lwfree_pointarray, and Lo: it didn't both to free the actual array of
POINT underlying the whole thing. I fix that, the leak disappears.

The second memory leak. The lwfree_pointarray function is defined in
lwgeom_api, and it is directly below a comment block that says *this*:

/****************************************************************
 * memory management
 *
 *  these only delete the memory associated
 *  directly with the structure - NOT the stuff pointing into
 *  the original de-serialized info
 *
 ****************************************************************/

Oh! That seems pretty clear. So by changing the function to fully
clean up after itself, I'm contravening the documented intent.
However, grep tells me the function is but lightly used in the code
base, hardly at all, really.  Our second memory leak is historical, we
have no idea why the intent was once this way.

Before I commit the changes to the lwfree_* set to make them finally,
actually, do deep freeing, can anyone provide the historical context
around the rules I seem to want to break?

Paul


From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 02:50:57 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 10:50:57 +0000
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
Message-ID: <49648911.5000303@siriusit.co.uk>

Paul Ramsey wrote:

> The second memory leak. The lwfree_pointarray function is defined in
> lwgeom_api, and it is directly below a comment block that says *this*:
> 
> /****************************************************************
>  * memory management
>  *
>  *  these only delete the memory associated
>  *  directly with the structure - NOT the stuff pointing into
>  *  the original de-serialized info
>  *
>  ****************************************************************/
> 
> Oh! That seems pretty clear. So by changing the function to fully
> clean up after itself, I'm contravening the documented intent.
> However, grep tells me the function is but lightly used in the code
> base, hardly at all, really.  Our second memory leak is historical, we
> have no idea why the intent was once this way.
> 
> Before I commit the changes to the lwfree_* set to make them finally,
> actually, do deep freeing, can anyone provide the historical context
> around the rules I seem to want to break?

Yes - if you do this it will break liblwgeom use within PostgreSQL :( 
Before I was ill over Christmas, I started looking at your complaint 
about manipulating MULTI-geoms in liblwgeom, and realised that the 
reason the LWGEOMs are deep-copied is because the POINTARRAYs within 
LWGEOM *obtained from PostgreSQL* MUST be immutable. Hence if we wish to 
alter a LWGEOM, we *MUST* copy it and return the copy.

And why is this? It's because when PostgreSQL passes us a geometry, we 
are passed a copy of the geometry allocated by PostgreSQL. But the 
LWGEOM deserialization code sets the POINTARRAY pointer directly to the 
doubles array within the PostgreSQL geometry - hence the memory within 
the POINTARRAY *is not ours to free*. This is why there are lots of 
separate lwfree(line->pa)-type calls scattered around liblwgeom to free 
the parts we know can be discarded, but otherwise the memory has to be 
freed by PostgreSQL.

Since I've been spending a lot of time re-working liblwgeom over the 
past few months, I (and I think you also) have separately come to the 
conclusion that having this type of memory model is not good. The 
principle of least surprise dictates that lwfree()-ing a geometry should 
free all of it, and not assume any behaviour on the part of the 
environment using the geometry.

Part of the testing I was doing over Christmas involved experimenting 
with memcpy() to see what the impact would be of copying the POINTARRAY 
out of the PostgreSQL allocated geometry so that the geometries are 
separate - and I came up with some very surprising results. I know strk 
was keen to optimise the performance of the LWGEOMs, but from my results 
I think there has been a case of premature optimisation here.

The attached file testmem.c is used to compare the performance of LWGEOM 
  construction on an array of 80,000 2D points. The first test is 
designed to compare the difference between scanning through the point 
array using the existing getPoint2d_p() function (unaligned memcpy 
access) and scanning through an aligned array of doubles:


Testing unaligned point access...
x: -2.6378e+08
y: -3.66648e+08
x: 2.13081e+09
y: 8.59704e+08
x: 1.01699e+09
y: -1.04434e+09
x: 4.88672e+08
y: 6.35536e+08
x: -5.43084e+08
y: -6.452e+08

Execution time: 0.26586 s
(Speed: 300910 points per second)

Testing aligned point access...
x: -2.6378e+08
y: -3.66648e+08
x: 2.13081e+09
y: 8.59704e+08
x: 1.01699e+09
y: -1.04434e+09
x: 4.88672e+08
y: 6.35536e+08
x: -5.43084e+08
y: -6.452e+08

Execution time: 0.0176489 s
(Speed: 4.53285e+06 points per second)


Wow. This goes back to your original idea with respect to the speed of 
aligned/versus unaligned access and we can see that the aligned version 
blows away the unaligned version in terms of access speed. So then the 
question to ask is that if we were to memcpy() the unaligned point array 
into an aligned double array when constructing the LWGEOM, would this 
still be faster than access the unaligned array? And the answer is a 
resounding yes:


Testing non-memcpy lwline constructor with point iteration...

Execution time: 1.01137 s
(Speed: 79100.2 points per second)

Testing memcpy lwline constructor with point iteration...

Execution time: 0.368717 s
(Speed: 216969 points per second)


This test shows the time taken to memcpy() the POINTARRAY and also 
iterate through all of the points within it. The results clearly show 
that if we visit every point in the geometry (which we have to do if we 
call serialize to send the LWGEOM back to PostgreSQL anyway), then even 
with the initial memcpy() from unaligned to aligned memory, the aligned 
version is still nearly 3 times faster than the unaligned version! :O

Now there is a slight degenerate case here: what if we simply want to 
access a single point within the geometry? This is demonstrated by this 
case here:


Testing non-memcpy lwline constructor with single point access (middle 
point)...

Execution time: 0.0055759 s
(Speed: 1.43475e+07 points per second)

Testing memcpy lwline constructor with single point access (middle point)...

Execution time: 29.0237 s
(Speed: 2756.37 points per second)


Ouch. So if we don't visit all points within the memcpy() point array 
then the overhead of the memcpy() becomes quite substantial. This then 
led me to think about LWGEOM_INSPECTED which is supposed to be for 
high-speed access - perhaps we can make use of this? Unfortunately this 
makes use of the serialized form which is only something that would be 
useful to PostGIS and not other users of liblwgeom. But it still makes 
sense to offer a non-memcpy() alternative read-only LWGEOM derivative 
for these cases.

So in summary, based upon this work I would suggest the following 
recommendations:


- Alter the deserialize routines to memcpy() the unaligned pointarray 
into aligned liblwgeom allocated memory

- Swap liblwgeom code over access the arrays directly instead of using 
getPoint2d_p()

- Alter the collection manipulation routines so that they no-longer deep 
copy LWGEOMs

- Alter the lwfree_* functions so that they free the pointarray copy


Once liblwgeom manages its own memory in this way are then very close to 
getting rid of the bad hack that is lwgeom_init_allocators() and 
lwgeom_install_default_allocators().


Then just to complete the icing on the cake:


- Remove the LWGEOM_INSPECTED routines (I think given the non-alignment 
of these they will also prove to be slower in real life)

- Create a new LWGEOM_INLINE read-only type which works in a similar 
manner to existing LWGEOM without memcpy(). We can then use this for 
pulling out single unaligned points out of large arrays if required.


I realise that this is quite a long email, but I think that the attached 
test show there is a strong case for changing the way in which liblwgeom 
which will not only speed up performance for routines which process 
geometries, but will also untangle the liblwgeom memory-management from 
PostgreSQL (which as Paul notes will make it much easier to detect 
memory leaks) :)


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testmem.c
Type: text/x-csrc
Size: 3962 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090107/395343a7/attachment.c>

From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 03:02:48 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 11:02:48 +0000
Subject: [postgis-devel] iconv + loader
In-Reply-To: <E8E31C7E-3562-4FCE-B9B6-84033631777C@opengeo.org>
References: <E8E31C7E-3562-4FCE-B9B6-84033631777C@opengeo.org>
Message-ID: <49648BD8.6090903@siriusit.co.uk>

Paul Ramsey wrote:

> I just noticed that we do our character transcoding inside the loader 
> itself and "SET CLIENT_ENCODING = UTF8". Wouldn't it be a lot simpler to 
> just "SET CLIENT_ENCODING = <encoding>" and dump the strings to the 
> server to handle?
> 
> Anyone know the rationale for the current approach?
> 
> P

I'm not sure, but I'm wondering if it could be related to escaping 
characters? By converting to UTF8, we know that if we encounter an 
apostrophe in the input string, we can simply escape it by replacing it 
with \' since ASCII is a subset of UTF8. However in non-UTF8 encodings, 
we have no way of knowing what the codepoints for the backslash and 
apostrophe for a given encoding actually are :(


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 03:11:29 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 11:11:29 +0000
Subject: [postgis-devel] Ramblings on CUnit and more...
In-Reply-To: <CDC41A38-FFB2-487F-B552-0AD98FD35F96@opengeo.org>
References: <49628826.2010805@siriusit.co.uk>
	<CDC41A38-FFB2-487F-B552-0AD98FD35F96@opengeo.org>
Message-ID: <49648DE1.1040000@siriusit.co.uk>

Paul Ramsey wrote:

> Please fee free to bump anything you don't like down to a level you 
> want. That's me leaving my own debug blocks unchanged after a commit, 
> which is silly, since the commit comes ones the debugging is through.
> 
> P.

Yup, done.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Wed Jan  7 04:38:13 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 Jan 2009 12:38:13 +0000
Subject: [postgis-devel] Issue 92 in postgis: Error in Estimated_Extent()
	when used with point geometry
Message-ID: <001485f9143a20f71f045fe3ccc7@google.com>


Comment #2 on issue 92 by aroranidh: Error in Estimated_Extent() when used  
with point geometry
http://code.google.com/p/postgis/issues/detail?id=92

Thnx Mark,

It works after analyze command

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From robe.dnd at cityofboston.gov  Wed Jan  7 06:34:06 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 7 Jan 2009 09:34:06 -0500
Subject: [postgis-devel] Compile trouble of Trunk on MingW
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20541A9C5@ZDND.DND.boston.cob>

I'm still having trouble compiling 1.4 SVN under MingW.  It keeps
complaining that it can't find my Proj install.  My install looks fine
as far as I can tell.  The proj.exe etc gets installed.  I verified my
Proj 4.6.1 proj_api.h is in C:\msys\1.0\local\include\proj_api.h

I tried this

./configure --libdir=/usr/local/lib --includedir=/usr/local/include
--with-pgconfig=/usr/local/pgsql/bin/pg_config
--with-projdir=/usr/local/include

and keep getting the error

configure: error: could not find proj_api.h - you may need to specify
the directory of a PROJ.4 installation using --with-projdir

I tried using both SVN and nightly snapshot with same error.  Have no
clue what I am missing here.

GEOS seems to be automatically detected and pgconfig seem to work fine
with the --with-pgconfig.

Any thoughts would be appreciated.

Thanks,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 06:39:12 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 14:39:12 +0000
Subject: [postgis-devel] Compile trouble of Trunk on MingW
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20541A9C5@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20541A9C5@ZDND.DND.boston.cob>
Message-ID: <4964BE90.5040400@siriusit.co.uk>

Obe, Regina wrote:
> I'm still having trouble compiling 1.4 SVN under MingW.  It keeps
> complaining that it can't find my Proj install.  My install looks fine
> as far as I can tell.  The proj.exe etc gets installed.  I verified my
> Proj 4.6.1 proj_api.h is in C:\msys\1.0\local\include\proj_api.h
> 
> I tried this
> 
> ./configure --libdir=/usr/local/lib --includedir=/usr/local/include
> --with-pgconfig=/usr/local/pgsql/bin/pg_config
> --with-projdir=/usr/local/include
> 
> and keep getting the error
> 
> configure: error: could not find proj_api.h - you may need to specify
> the directory of a PROJ.4 installation using --with-projdir
> 
> I tried using both SVN and nightly snapshot with same error.  Have no
> clue what I am missing here.
> 
> GEOS seems to be automatically detected and pgconfig seem to work fine
> with the --with-pgconfig.
> 
> Any thoughts would be appreciated.
> 
> Thanks,
> Regina

Hi Regina,

The clue is in the name ;)  projdir needs to point to base directory of 
the PROJ.4 install, since it needs the information from various 
subdirectories. In your case above, it should work with 
--with-projdir=/usr/local.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Wed Jan  7 06:42:24 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 7 Jan 2009 09:42:24 -0500
Subject: [postgis-devel] Compile trouble of Trunk on MingW
In-Reply-To: <4964BE90.5040400@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20541A9C5@ZDND.DND.boston.cob>
	<4964BE90.5040400@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20541A9F0@ZDND.DND.boston.cob>

Thanks that worked :).

Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Wednesday, January 07, 2009 9:39 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Compile trouble of Trunk on MingW

Obe, Regina wrote:
> I'm still having trouble compiling 1.4 SVN under MingW.  It keeps
> complaining that it can't find my Proj install.  My install looks fine
> as far as I can tell.  The proj.exe etc gets installed.  I verified my
> Proj 4.6.1 proj_api.h is in C:\msys\1.0\local\include\proj_api.h
> 
> I tried this
> 
> ./configure --libdir=/usr/local/lib --includedir=/usr/local/include
> --with-pgconfig=/usr/local/pgsql/bin/pg_config
> --with-projdir=/usr/local/include
> 
> and keep getting the error
> 
> configure: error: could not find proj_api.h - you may need to specify
> the directory of a PROJ.4 installation using --with-projdir
> 
> I tried using both SVN and nightly snapshot with same error.  Have no
> clue what I am missing here.
> 
> GEOS seems to be automatically detected and pgconfig seem to work fine
> with the --with-pgconfig.
> 
> Any thoughts would be appreciated.
> 
> Thanks,
> Regina

Hi Regina,

The clue is in the name ;)  projdir needs to point to base directory of 
the PROJ.4 install, since it needs the information from various 
subdirectories. In your case above, it should work with 
--with-projdir=/usr/local.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From pramsey at cleverelephant.ca  Wed Jan  7 08:13:52 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 7 Jan 2009 08:13:52 -0800
Subject: [postgis-devel] iconv + loader
In-Reply-To: <49648BD8.6090903@siriusit.co.uk>
References: <E8E31C7E-3562-4FCE-B9B6-84033631777C@opengeo.org>
	<49648BD8.6090903@siriusit.co.uk>
Message-ID: <30fe546d0901070813y3feb25ceo301dc277cf0b3d57@mail.gmail.com>

I guess for servers running as SQL_ASCII, it could also be useful to
transcode in the client, though if you're running a SQL_ASCII server,
you probably don't care about encodings :)

P

On Wed, Jan 7, 2009 at 3:02 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>
>> I just noticed that we do our character transcoding inside the loader
>> itself and "SET CLIENT_ENCODING = UTF8". Wouldn't it be a lot simpler to
>> just "SET CLIENT_ENCODING = <encoding>" and dump the strings to the server
>> to handle?
>>
>> Anyone know the rationale for the current approach?
>>
>> P
>
> I'm not sure, but I'm wondering if it could be related to escaping
> characters? By converting to UTF8, we know that if we encounter an
> apostrophe in the input string, we can simply escape it by replacing it with
> \' since ASCII is a subset of UTF8. However in non-UTF8 encodings, we have
> no way of knowing what the codepoints for the backslash and apostrophe for a
> given encoding actually are :(
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From codesite-noreply at google.com  Wed Jan  7 08:25:33 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 Jan 2009 16:25:33 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <0016e644d02c1b1c3e045fe6f93f@google.com>

Updates:
	Status: WontFix
	Labels: Type-Enhancement Milestone-1.4 Priority-Low

Comment #4 on issue 90 by ke... at refractions.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

This issue is already addressed in trunk (the next minor release).   
Applying the
patch to 1.3 would change the behaviour of the method, which is not  
appropriate for a
micro release.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at opengeo.org  Wed Jan  7 08:46:51 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 7 Jan 2009 08:46:51 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <49648911.5000303@siriusit.co.uk>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
	<49648911.5000303@siriusit.co.uk>
Message-ID: <30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>

Thanks for all the detailed info, Mark!

I agree that our LWGEOM data structure should be aligned and directly
accessible, but I would go one further and say we should align our
serialized structure. Basically retain the aspect of Dave's design
that uses the serialized version directly, but alter the serialized
version enough to align it internally.

Why so? As you note, that data is const, we can't muck with it.
HOWEVER, most operations people are running in the database are
read-only with respect to the spatial data. They are using it as a
query parameter, or a filter, or they are just flipping it out to a
different format (maps, or GML, JSON or whatnot).  AND, in those cases
where geometry IS being altered, it is usually being done in a
constructive manner: that is, whole new geometries are being created
(buffer, union, difference, etc).

I think where we both end up is in a place where we need some way of
noting what kind of geometry we have on hand, a const one or a
variable one, so we can "do the right thing" in a number of situations
(freeing, trying to alter, etc).

And think, if you're getting that good throughput memcpy'ing the whole
block, how fast will it be when you're directly accessing an aligned
tuple? :) W00t!

P.

On Wed, Jan 7, 2009 at 2:50 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>
>> The second memory leak. The lwfree_pointarray function is defined in
>> lwgeom_api, and it is directly below a comment block that says *this*:
>>
>> /****************************************************************
>>  * memory management
>>  *
>>  *  these only delete the memory associated
>>  *  directly with the structure - NOT the stuff pointing into
>>  *  the original de-serialized info
>>  *
>>  ****************************************************************/
>>
>> Oh! That seems pretty clear. So by changing the function to fully
>> clean up after itself, I'm contravening the documented intent.
>> However, grep tells me the function is but lightly used in the code
>> base, hardly at all, really.  Our second memory leak is historical, we
>> have no idea why the intent was once this way.
>>
>> Before I commit the changes to the lwfree_* set to make them finally,
>> actually, do deep freeing, can anyone provide the historical context
>> around the rules I seem to want to break?
>
> Yes - if you do this it will break liblwgeom use within PostgreSQL :( Before
> I was ill over Christmas, I started looking at your complaint about
> manipulating MULTI-geoms in liblwgeom, and realised that the reason the
> LWGEOMs are deep-copied is because the POINTARRAYs within LWGEOM *obtained
> from PostgreSQL* MUST be immutable. Hence if we wish to alter a LWGEOM, we
> *MUST* copy it and return the copy.
>
> And why is this? It's because when PostgreSQL passes us a geometry, we are
> passed a copy of the geometry allocated by PostgreSQL. But the LWGEOM
> deserialization code sets the POINTARRAY pointer directly to the doubles
> array within the PostgreSQL geometry - hence the memory within the
> POINTARRAY *is not ours to free*. This is why there are lots of separate
> lwfree(line->pa)-type calls scattered around liblwgeom to free the parts we
> know can be discarded, but otherwise the memory has to be freed by
> PostgreSQL.
>
> Since I've been spending a lot of time re-working liblwgeom over the past
> few months, I (and I think you also) have separately come to the conclusion
> that having this type of memory model is not good. The principle of least
> surprise dictates that lwfree()-ing a geometry should free all of it, and
> not assume any behaviour on the part of the environment using the geometry.
>
> Part of the testing I was doing over Christmas involved experimenting with
> memcpy() to see what the impact would be of copying the POINTARRAY out of
> the PostgreSQL allocated geometry so that the geometries are separate - and
> I came up with some very surprising results. I know strk was keen to
> optimise the performance of the LWGEOMs, but from my results I think there
> has been a case of premature optimisation here.
>
> The attached file testmem.c is used to compare the performance of LWGEOM
>  construction on an array of 80,000 2D points. The first test is designed to
> compare the difference between scanning through the point array using the
> existing getPoint2d_p() function (unaligned memcpy access) and scanning
> through an aligned array of doubles:
>
>
> Testing unaligned point access...
> x: -2.6378e+08
> y: -3.66648e+08
> x: 2.13081e+09
> y: 8.59704e+08
> x: 1.01699e+09
> y: -1.04434e+09
> x: 4.88672e+08
> y: 6.35536e+08
> x: -5.43084e+08
> y: -6.452e+08
>
> Execution time: 0.26586 s
> (Speed: 300910 points per second)
>
> Testing aligned point access...
> x: -2.6378e+08
> y: -3.66648e+08
> x: 2.13081e+09
> y: 8.59704e+08
> x: 1.01699e+09
> y: -1.04434e+09
> x: 4.88672e+08
> y: 6.35536e+08
> x: -5.43084e+08
> y: -6.452e+08
>
> Execution time: 0.0176489 s
> (Speed: 4.53285e+06 points per second)
>
>
> Wow. This goes back to your original idea with respect to the speed of
> aligned/versus unaligned access and we can see that the aligned version
> blows away the unaligned version in terms of access speed. So then the
> question to ask is that if we were to memcpy() the unaligned point array
> into an aligned double array when constructing the LWGEOM, would this still
> be faster than access the unaligned array? And the answer is a resounding
> yes:
>
>
> Testing non-memcpy lwline constructor with point iteration...
>
> Execution time: 1.01137 s
> (Speed: 79100.2 points per second)
>
> Testing memcpy lwline constructor with point iteration...
>
> Execution time: 0.368717 s
> (Speed: 216969 points per second)
>
>
> This test shows the time taken to memcpy() the POINTARRAY and also iterate
> through all of the points within it. The results clearly show that if we
> visit every point in the geometry (which we have to do if we call serialize
> to send the LWGEOM back to PostgreSQL anyway), then even with the initial
> memcpy() from unaligned to aligned memory, the aligned version is still
> nearly 3 times faster than the unaligned version! :O
>
> Now there is a slight degenerate case here: what if we simply want to access
> a single point within the geometry? This is demonstrated by this case here:
>
>
> Testing non-memcpy lwline constructor with single point access (middle
> point)...
>
> Execution time: 0.0055759 s
> (Speed: 1.43475e+07 points per second)
>
> Testing memcpy lwline constructor with single point access (middle point)...
>
> Execution time: 29.0237 s
> (Speed: 2756.37 points per second)
>
>
> Ouch. So if we don't visit all points within the memcpy() point array then
> the overhead of the memcpy() becomes quite substantial. This then led me to
> think about LWGEOM_INSPECTED which is supposed to be for high-speed access -
> perhaps we can make use of this? Unfortunately this makes use of the
> serialized form which is only something that would be useful to PostGIS and
> not other users of liblwgeom. But it still makes sense to offer a
> non-memcpy() alternative read-only LWGEOM derivative for these cases.
>
> So in summary, based upon this work I would suggest the following
> recommendations:
>
>
> - Alter the deserialize routines to memcpy() the unaligned pointarray into
> aligned liblwgeom allocated memory
>
> - Swap liblwgeom code over access the arrays directly instead of using
> getPoint2d_p()
>
> - Alter the collection manipulation routines so that they no-longer deep
> copy LWGEOMs
>
> - Alter the lwfree_* functions so that they free the pointarray copy
>
>
> Once liblwgeom manages its own memory in this way are then very close to
> getting rid of the bad hack that is lwgeom_init_allocators() and
> lwgeom_install_default_allocators().
>
>
> Then just to complete the icing on the cake:
>
>
> - Remove the LWGEOM_INSPECTED routines (I think given the non-alignment of
> these they will also prove to be slower in real life)
>
> - Create a new LWGEOM_INLINE read-only type which works in a similar manner
> to existing LWGEOM without memcpy(). We can then use this for pulling out
> single unaligned points out of large arrays if required.
>
>
> I realise that this is quite a long email, but I think that the attached
> test show there is a strong case for changing the way in which liblwgeom
> which will not only speed up performance for routines which process
> geometries, but will also untangle the liblwgeom memory-management from
> PostgreSQL (which as Paul notes will make it much easier to detect memory
> leaks) :)
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From pramsey at opengeo.org  Wed Jan  7 08:50:42 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 7 Jan 2009 08:50:42 -0800
Subject: [postgis-devel] Memory in the Meantime
Message-ID: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>

Sounds like we are developing our 1.5/2.0 roadmap on the sly here, but
in the meantime, we have a gaping memory leak in the loader in 1.4.

I see that I can't just change lwfree_pointarray to deep-free, since
the lwfree_poly and lwfree_line calls in lwgeom will then try to free
const structures passed to us by PgSQL.

However, there is a half-thought-out concept of lwrelease_* in
liblwgeom, which seems to somewhat get there. I would propose that our
"in the meantime" strategy for this is:

lwfree_* is a deep free.
lwrelease_* will free everything down to just above the serialized piece

I'll fill out *all* the functions for lwrelease_ and then go retrofit
the existing lwfree_* calls in lwgeom to use lwrelease instead
(there's actually not that many, because... we are terrible memory
managers :).

Comments?

Paul


From codesite-noreply at google.com  Wed Jan  7 08:55:49 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 Jan 2009 16:55:49 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <00151750da5a5cb84e045fe7653c@google.com>


Comment #5 on issue 90 by reid at reidster.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

Kevin,

Very glad to hear it'll be fixed in 1.4.

> Applying the patch to 1.3 would change the behaviour of the method, which  
is not
> appropriate for a micro release.

Without knowing the PostGIS policy on this (it's certainly not that  
changing the
behavior of methods is out, since that excludes all bugfixes), I'd like to  
push back
a bit: the current behavior is not documented, so I don't see how it  
changes the
advertised interface, and I do believe it violates the principle of least  
surprise
rather severely.

It could also lead to incorrect behavior: suppose that I have two tables,
pg_temp1.foo_tmp and public.foo. If I call  
AddGeometryColumn('temp', 'foo', ...) --
i.e., I got the name of the temp tablespace wrong and I forgot the _tmp  
suffix --
then it would change the wrong table (foo instead of foo_tmp). This  
scenario could
arise if (say) I created a temp copy of foo to do some analysis.

I agree that there are bigger fish to fry, but it's a trivial patch.

> If it ok with you, I'll close this ticket.

Not sure if you were actually waiting for me on this, but if you were, 17  
hours
doesn't seem a long enough wait for someone to reply.

Thanks,

Reid

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Wed Jan  7 09:32:04 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 Jan 2009 17:32:04 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <0016e6407ed0fa5a31045fe7e62b@google.com>

Updates:
	Status: Fixed
	Labels: -Type-Enhancement -Milestone-1.4 Type-Defect Milestone-1.3.X

Comment #6 on issue 90 by ke... at refractions.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

Hi Reid,

I appreciate your feedback.  You're right that this subtle case is not well
documented (something I just fixed in the trunk docs).  Fair enough, it's a  
subtle
change and could be classified as a bug since an error is being thrown  
anyway.  I
just committed the patch to 1.3

Cheers,
Kevin

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Wed Jan  7 10:14:20 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 Jan 2009 18:14:20 +0000
Subject: [postgis-devel] Issue 90 in postgis: AddGeometryColumn
	inappropriately defaults to 
	current_schema() if given nonexistent schema
Message-ID: <0016361e88682c8ddd045fe87e88@google.com>


Comment #7 on issue 90 by reid at reidster.net: AddGeometryColumn  
inappropriately defaults to current_schema() if given nonexistent schema
http://code.google.com/p/postgis/issues/detail?id=90

Thanks, Kevin.

Not sure if this is the right venue, but I would like to express my thanks  
for your
(and everyone else's) work on PostGIS. It's absolutely indispensable for  
us; there's
simply no way our project would exist without it.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 14:43:29 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 22:43:29 +0000
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>	<49648911.5000303@siriusit.co.uk>
	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>
Message-ID: <49653011.50307@siriusit.co.uk>

Paul Ramsey wrote:

> Thanks for all the detailed info, Mark!
> 
> I agree that our LWGEOM data structure should be aligned and directly
> accessible, but I would go one further and say we should align our
> serialized structure. Basically retain the aspect of Dave's design
> that uses the serialized version directly, but alter the serialized
> version enough to align it internally.
> 
> Why so? As you note, that data is const, we can't muck with it.
> HOWEVER, most operations people are running in the database are
> read-only with respect to the spatial data. They are using it as a
> query parameter, or a filter, or they are just flipping it out to a
> different format (maps, or GML, JSON or whatnot).  AND, in those cases
> where geometry IS being altered, it is usually being done in a
> constructive manner: that is, whole new geometries are being created
> (buffer, union, difference, etc).

Yeah I can see the advantages in this, but of course there are lots of 
implications. Users would have to dump/restore their databases for one, 
and there would also be an increase in the size of data on disk (imagine 
the padding required for a 64-bit system...).

> I think where we both end up is in a place where we need some way of
> noting what kind of geometry we have on hand, a const one or a
> variable one, so we can "do the right thing" in a number of situations
> (freeing, trying to alter, etc).

You got it :)

> And think, if you're getting that good throughput memcpy'ing the whole
> block, how fast will it be when you're directly accessing an aligned
> tuple? :) W00t!

I suspect it would be fairly fast; but I'd like to see some concrete 
numbers from a suitable test to ensure that the alignment/disk size 
tradeoff does actually have a measurable improvement over just a plain 
aligned memcpy().


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Wed Jan  7 14:54:03 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 07 Jan 2009 22:54:03 +0000
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>
Message-ID: <4965328B.3020901@siriusit.co.uk>

Paul Ramsey wrote:

> Sounds like we are developing our 1.5/2.0 roadmap on the sly here, but
> in the meantime, we have a gaping memory leak in the loader in 1.4.
> 
> I see that I can't just change lwfree_pointarray to deep-free, since
> the lwfree_poly and lwfree_line calls in lwgeom will then try to free
> const structures passed to us by PgSQL.
> 
> However, there is a half-thought-out concept of lwrelease_* in
> liblwgeom, which seems to somewhat get there. I would propose that our
> "in the meantime" strategy for this is:
> 
> lwfree_* is a deep free.
> lwrelease_* will free everything down to just above the serialized piece
> 
> I'll fill out *all* the functions for lwrelease_ and then go retrofit
> the existing lwfree_* calls in lwgeom to use lwrelease instead
> (there's actually not that many, because... we are terrible memory
> managers :).
> 
> Comments?

My first thought was that it's a lot of work to go through the code and 
locate all the correct places, but then I realised that you only need to 
look at the code in lwgeom/ which reduces the work by quite a lot.

It's not something I feel strongly enough to run away and fix right now 
(there are only a few places in the loader where pointarrays are 
created, and so it's just a case of adding lwfree(pa->points) in the 
dozen or so locations affected), but if you wish to go ahead and make 
the changes with appropriate comments then that's fine with me.

If you decide not to go ahead with it, let me know and I'll go through 
shp2pgsql and add the extra lwfree()s - I feel it's kinda my 
responsibility since it was me that recently ripped out most of the guts 
of the loader...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at cleverelephant.ca  Wed Jan  7 15:21:27 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 7 Jan 2009 15:21:27 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <49653011.50307@siriusit.co.uk>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
	<49648911.5000303@siriusit.co.uk>
	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>
	<49653011.50307@siriusit.co.uk>
Message-ID: <30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>

On Wed, Jan 7, 2009 at 2:43 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Yeah I can see the advantages in this, but of course there are lots of
> implications. Users would have to dump/restore their databases for one, and
> there would also be an increase in the size of data on disk (imagine the
> padding required for a 64-bit system...).

We want 64-bit (double) alignment, so I don't think there's any
difference, no?  And as far as I can see the cost is 3 bytes (which we
can use anyways, for more space for typing)

> I suspect it would be fairly fast; but I'd like to see some concrete numbers
> from a suitable test to ensure that the alignment/disk size tradeoff does
> actually have a measurable improvement over just a plain aligned memcpy().

Oh fooey :)  I can see doing what you want as an interim step, then
sliding the new approach beneath. Any change to something major like
this will require careful code review, which will make subsequent
changes easier, I hope.

My concern about your approach is that, while it will (should) make
the "whole geometry" ops like area calculations and predicate tests
faster, the penalty on partial-geometry ops (PointN, RingN) is so
large it could cause noticeable degradation for some users, a
"downgrade" as it were.

P.


From pramsey at cleverelephant.ca  Wed Jan  7 15:25:55 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 7 Jan 2009 15:25:55 -0800
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <4965328B.3020901@siriusit.co.uk>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>
	<4965328B.3020901@siriusit.co.uk>
Message-ID: <30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>

On Wed, Jan 7, 2009 at 2:54 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
>> liblwgeom, which seems to somewhat get there. I would propose that our
>> "in the meantime" strategy for this is:
>>
>> lwfree_* is a deep free.
>> lwrelease_* will free everything down to just above the serialized piece

> My first thought was that it's a lot of work to go through the code and
> locate all the correct places, but then I realised that you only need to
> look at the code in lwgeom/ which reduces the work by quite a lot.

I've looked, it's really not a big deal, I'm happy to do it, and I
want to, since the memory implications for the loader are *massive*
(fixing the loader requires more than just adding one line, it
requires a replacement for lwfree_poly which actually does the deep
free... so, 8 lines :) But still feels wrong to be building what
should be library infrastructure into the loader.

I'm going ahead with it, it will allow me to finish up the GUI. Which,
BTW, feels like a step backwards in code attractiveness, since I
didn't re-write the core code in the end, just retrofitted the output
handling.

P.


From mark.cave-ayland at siriusit.co.uk  Thu Jan  8 02:31:38 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 08 Jan 2009 10:31:38 +0000
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>	<49648911.5000303@siriusit.co.uk>	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>	<49653011.50307@siriusit.co.uk>
	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>
Message-ID: <4965D60A.1010405@siriusit.co.uk>

Paul Ramsey wrote:

> On Wed, Jan 7, 2009 at 2:43 PM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> Yeah I can see the advantages in this, but of course there are lots of
>> implications. Users would have to dump/restore their databases for one, and
>> there would also be an increase in the size of data on disk (imagine the
>> padding required for a 64-bit system...).
> 
> We want 64-bit (double) alignment, so I don't think there's any
> difference, no?  And as far as I can see the cost is 3 bytes (which we
> can use anyways, for more space for typing)

Yes, but 64-bit == 8 bytes so there is a maximum padding cost of 7 bytes 
per geometry/subgeometry.

>> I suspect it would be fairly fast; but I'd like to see some concrete numbers
>> from a suitable test to ensure that the alignment/disk size tradeoff does
>> actually have a measurable improvement over just a plain aligned memcpy().
> 
> Oh fooey :)  I can see doing what you want as an interim step, then
> sliding the new approach beneath. Any change to something major like
> this will require careful code review, which will make subsequent
> changes easier, I hope.

Indeed. I'm inclined to try and keep the LWGEOM disk format unchanged 
from 1.3 to 1.4 just so that people can just upgrade and hence migrate 
away from 1.3 to the newer codebase as quickly as possible :)

> My concern about your approach is that, while it will (should) make
> the "whole geometry" ops like area calculations and predicate tests
> faster, the penalty on partial-geometry ops (PointN, RingN) is so
> large it could cause noticeable degradation for some users, a
> "downgrade" as it were.

Oh sure, which is why I suggested having both forms of geometry - an 
memcpy/aligned and a non-memcpy/unaligned type to handle both cases. I'm 
not quite sure yet whether it would be better to have a separate 
LWGEOM_ALIGNED type or add extra flags to LWGEOM though...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Thu Jan  8 02:35:08 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 08 Jan 2009 10:35:08 +0000
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>
	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
Message-ID: <4965D6DC.3010807@siriusit.co.uk>

Paul Ramsey wrote:

> I've looked, it's really not a big deal, I'm happy to do it, and I
> want to, since the memory implications for the loader are *massive*
> (fixing the loader requires more than just adding one line, it
> requires a replacement for lwfree_poly which actually does the deep
> free... so, 8 lines :) But still feels wrong to be building what
> should be library infrastructure into the loader.

*shrug* sure. Well, saves me doing the work anyway ;)

> I'm going ahead with it, it will allow me to finish up the GUI. Which,
> BTW, feels like a step backwards in code attractiveness, since I
> didn't re-write the core code in the end, just retrofitted the output
> handling.

Okay. My only request is that initially can the GUI have a separate 
target in the Makefile? Otherwise I can see this causing issues on 
commit with the automated build, Win32 etc...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Thu Jan  8 08:26:28 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Thu, 8 Jan 2009 08:26:28 -0800
Subject: [postgis-devel] Naming Nit
Message-ID: <87545C5B-57B3-46D7-A522-774A1AEB4DC2@opengeo.org>

As I did the memory change this morning, I noticed I was changing  
lwfree_<type> to <type>_release.  Given the layout of code in the  
<type>.c files, probably lwfree_<type> should be <type>_free.

This is the kind of tidying which is useful but feels pointless, and  
potentially annoys people, hence the e-mail.

A second nit, we've got

extern POINTARRAY *pointArray_construct(uchar *points, char hasz, char  
hasm, uint32 npoints);
which lives in lwgeom_api.c

and

extern POINTARRAY *ptarray_construct(char hasz, char hasm, unsigned  
int npoints);
which lives in ptarray.c

w00t!

P


--
Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS. Because you're just that good looking.



From pramsey at cleverelephant.ca  Thu Jan  8 08:45:11 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 8 Jan 2009 08:45:11 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <4965D60A.1010405@siriusit.co.uk>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
	<49648911.5000303@siriusit.co.uk>
	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>
	<49653011.50307@siriusit.co.uk>
	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>
	<4965D60A.1010405@siriusit.co.uk>
Message-ID: <30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>

On Thu, Jan 8, 2009 at 2:31 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:

> Indeed. I'm inclined to try and keep the LWGEOM disk format unchanged from
> 1.3 to 1.4 just so that people can just upgrade and hence migrate away from
> 1.3 to the newer codebase as quickly as possible :)

Were you thinking of doing this for 1.4? I figured we were getting
close to "fix bugs and start release candidates". Although, now that I
type that, I *really* should force GEOS 3.1 out before we put 1.4 out,
so that 1.4 can claim all the new features of GEOS at the same time.

P.


From mark.cave-ayland at siriusit.co.uk  Thu Jan  8 12:18:34 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 08 Jan 2009 20:18:34 +0000
Subject: [postgis-devel] Naming Nit
In-Reply-To: <87545C5B-57B3-46D7-A522-774A1AEB4DC2@opengeo.org>
References: <87545C5B-57B3-46D7-A522-774A1AEB4DC2@opengeo.org>
Message-ID: <49665F9A.9060408@siriusit.co.uk>

Paul Ramsey wrote:

> As I did the memory change this morning, I noticed I was changing 
> lwfree_<type> to <type>_release.  Given the layout of code in the 
> <type>.c files, probably lwfree_<type> should be <type>_free.
> 
> This is the kind of tidying which is useful but feels pointless, and 
> potentially annoys people, hence the e-mail.

+1 from me - I've noticed this before but never got around to doing 
anything about it.

> A second nit, we've got
> 
> extern POINTARRAY *pointArray_construct(uchar *points, char hasz, char 
> hasm, uint32 npoints);
> which lives in lwgeom_api.c
> 
> and
> 
> extern POINTARRAY *ptarray_construct(char hasz, char hasm, unsigned int 
> npoints);
> which lives in ptarray.c
> 
> w00t!

???!


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Thu Jan  8 12:24:12 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 08 Jan 2009 20:24:12 +0000
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>	<49648911.5000303@siriusit.co.uk>	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>	<49653011.50307@siriusit.co.uk>	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>	<4965D60A.1010405@siriusit.co.uk>
	<30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>
Message-ID: <496660EC.4010501@siriusit.co.uk>

Paul Ramsey wrote:

>> Indeed. I'm inclined to try and keep the LWGEOM disk format unchanged from
>> 1.3 to 1.4 just so that people can just upgrade and hence migrate away from
>> 1.3 to the newer codebase as quickly as possible :)
> 
> Were you thinking of doing this for 1.4? I figured we were getting
> close to "fix bugs and start release candidates". Although, now that I
> type that, I *really* should force GEOS 3.1 out before we put 1.4 out,
> so that 1.4 can claim all the new features of GEOS at the same time.
> 
> P.

Ah okay - I got the impression you were trying to do a lot more work for 
1.4 such as the shp2pgsql GUI and the extra lwalgorithm functions, but 
I'd be quite happy to start to tie up the loose ends and get this ready 
for general use sooner.

How about creating a page on the wiki called PostGIS14ToDo or similar 
where we can devise a complete list of outstanding issues for 1.4, 
listed by developer name? We can then go through and resolve them 
one-by-one.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at cleverelephant.ca  Thu Jan  8 12:37:21 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 8 Jan 2009 12:37:21 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <496660EC.4010501@siriusit.co.uk>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>	<49648911.5000303@siriusit.co.uk>	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>	<49653011.50307@siriusit.co.uk>	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>	<4965D60A.1010405@siriusit.co.uk>
	<30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>
	<496660EC.4010501@siriusit.co.uk>
Message-ID: <A1DEFA02-BD05-430C-BDFD-65C49A945870@cleverelephant.ca>

Let's just set the milestone of the bugs we care about to 1.4, and all  
the rest to 1.5

P

On Jan 8, 2009, at 12:24 PM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>>> Indeed. I'm inclined to try and keep the LWGEOM disk format  
>>> unchanged from
>>> 1.3 to 1.4 just so that people can just upgrade and hence migrate  
>>> away from
>>> 1.3 to the newer codebase as quickly as possible :)
>> Were you thinking of doing this for 1.4? I figured we were getting
>> close to "fix bugs and start release candidates". Although, now  
>> that I
>> type that, I *really* should force GEOS 3.1 out before we put 1.4  
>> out,
>> so that 1.4 can claim all the new features of GEOS at the same time.
>> P.
>
> Ah okay - I got the impression you were trying to do a lot more work  
> for 1.4 such as the shp2pgsql GUI and the extra lwalgorithm  
> functions, but I'd be quite happy to start to tie up the loose ends  
> and get this ready for general use sooner.
>
> How about creating a page on the wiki called PostGIS14ToDo or  
> similar where we can devise a complete list of outstanding issues  
> for 1.4, listed by developer name? We can then go through and  
> resolve them one-by-one.
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From strk at keybit.net  Thu Jan  8 12:40:43 2009
From: strk at keybit.net (strk)
Date: Thu, 8 Jan 2009 21:40:43 +0100
Subject: [postgis-devel] Naming Nit
In-Reply-To: <49665F9A.9060408@siriusit.co.uk>
References: <87545C5B-57B3-46D7-A522-774A1AEB4DC2@opengeo.org>
	<49665F9A.9060408@siriusit.co.uk>
Message-ID: <20090108204043.GD35093@keybit.net>

On Thu, Jan 08, 2009 at 08:18:34PM +0000, Mark Cave-Ayland wrote:
> Paul Ramsey wrote:
> 
...
> >A second nit, we've got
> >
> >extern POINTARRAY *pointArray_construct(uchar *points, char hasz, char 
> >hasm, uint32 npoints);
> >which lives in lwgeom_api.c
> >
> >and
> >
> >extern POINTARRAY *ptarray_construct(char hasz, char hasm, unsigned int 
> >npoints);
> >which lives in ptarray.c
> >
> >w00t!
> 
> ???!

The second version allocates tha actual points, the first doesn't.
The POINTARRAY constructed with the first version doesn't need
deep memory release, the second does.

--strk; 

 GIS & Flash consultant/developer           ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From mark.cave-ayland at siriusit.co.uk  Thu Jan  8 12:41:14 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 08 Jan 2009 20:41:14 +0000
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <A1DEFA02-BD05-430C-BDFD-65C49A945870@cleverelephant.ca>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>	<49648911.5000303@siriusit.co.uk>	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>	<49653011.50307@siriusit.co.uk>	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>	<4965D60A.1010405@siriusit.co.uk>	<30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>	<496660EC.4010501@siriusit.co.uk>
	<A1DEFA02-BD05-430C-BDFD-65C49A945870@cleverelephant.ca>
Message-ID: <496664EA.8080803@siriusit.co.uk>

Paul Ramsey wrote:

> Let's just set the milestone of the bugs we care about to 1.4, and all 
> the rest to 1.5
> 
> P

..except that currently some of the things I had planned are not 
currently logged as bugs. Do you want me to go through and add them to 
the GBT?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at cleverelephant.ca  Thu Jan  8 15:24:53 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 8 Jan 2009 15:24:53 -0800
Subject: [postgis-devel] Memory Leak (Two Senses)
In-Reply-To: <496664EA.8080803@siriusit.co.uk>
References: <30fe546d0901062235h28ffad5as93cb2ce184baafd3@mail.gmail.com>
	<49648911.5000303@siriusit.co.uk>
	<30fe546d0901070846q1b2fc91bwd70dae67f5cc12b@mail.gmail.com>
	<49653011.50307@siriusit.co.uk>
	<30fe546d0901071521n2e5af3b6iea85ec42d30413e0@mail.gmail.com>
	<4965D60A.1010405@siriusit.co.uk>
	<30fe546d0901080845o719899d2p4528d9b3c868e908@mail.gmail.com>
	<496660EC.4010501@siriusit.co.uk>
	<A1DEFA02-BD05-430C-BDFD-65C49A945870@cleverelephant.ca>
	<496664EA.8080803@siriusit.co.uk>
Message-ID: <2759D0F4-948B-4E7E-8B86-854D7EAEE6CD@cleverelephant.ca>

I think that would be good if you could

P

Sent from my iPod

On 8-Jan-09, at 12:41 PM, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk 
 > wrote:

> Paul Ramsey wrote:
>
>> Let's just set the milestone of the bugs we care about to 1.4, and  
>> all the rest to 1.5
>> P
>
> ..except that currently some of the things I had planned are not  
> currently logged as bugs. Do you want me to go through and add them  
> to the GBT?
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From strk at keybit.net  Fri Jan  9 02:02:16 2009
From: strk at keybit.net (strk)
Date: Fri, 9 Jan 2009 11:02:16 +0100
Subject: [postgis-devel] [Pierre.Racine@sbf.ulaval.ca: [postgis-users]
	Enabling Tables or HTML in the PostGIS Wiki]
Message-ID: <20090109100216.GF35093@keybit.net>

Any chance to fix this ?
Pierre is trying to use the postgis wiki as the central web page for th WKTRaster...

--strk;

----- Forwarded message from Pierre Racine <Pierre.Racine at sbf.ulaval.ca> -----

Date: Mon, 5 Jan 2009 14:02:34 -0500
From: "Pierre Racine" <Pierre.Racine at sbf.ulaval.ca>
Subject: [postgis-users] Enabling Tables or HTML in the PostGIS Wiki 
Reply-To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
To: <postgis-users at postgis.refractions.net>
X-BeenThere: postgis-users at postgis.refractions.net

Hi, 

I was trying to make a table in a page of the PostGIS wiki without
success. I could find that the wiki engine is PhpWiki and had a look at
its documentation
(http://www.nvg.ntnu.no/phpwiki/index.php/TextFormattingRules). It's
normally possible to insert tables but it does not work in the PostGIS
wiki. 

Otherwise it seems possible to enable HTML tag in the PhpWiki
configuration (look at the last phrase of this page
(http://postgis.refractions.net/support/wiki/index.php?TextFormattingRul
es)). This must be done by the wiki administrator. Who is the
administrator? 

Enabling HTML would allow us to build much more attractive/comprehensive
pages... 

Thanks, 

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

----- End forwarded message -----


From codesite-noreply at google.com  Fri Jan  9 02:25:08 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:25:08 +0000
Subject: [postgis-devel] Issue 92 in postgis: Error in Estimated_Extent()
	when used with point geometry
Message-ID: <000e0cd6ae3ad8bb1204600a2bf1@google.com>

Updates:
	Status: WontFix

Comment #3 on issue 92 by mark.cav... at siriusit.co.uk: Error in  
Estimated_Extent() when used with point geometry
http://code.google.com/p/postgis/issues/detail?id=92

Closing as "Won't Fix".


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:29:08 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:29:08 +0000
Subject: [postgis-devel] Issue 86 in postgis: ST_LineToCurve produces
	invalid curves
Message-ID: <0016361e88342b40e204600a3a06@google.com>

Updates:
	Labels: Milestone-1.4

Comment #3 on issue 86 by mark.cav... at siriusit.co.uk: ST_LineToCurve  
produces invalid curves
http://code.google.com/p/postgis/issues/detail?id=86

Setting milestone to 1.4 to track changes ready for release.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:33:09 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:33:09 +0000
Subject: [postgis-devel] Issue 82 in postgis: Bug in bug tracker
Message-ID: <001485f91cb281a58604600a4894@google.com>


Comment #2 on issue 82 by mark.cav... at siriusit.co.uk: Bug in bug tracker
http://code.google.com/p/postgis/issues/detail?id=82

I've just changed the sorting order again based upon Milestone / Priority /  
Id so it
should make it easier to see which bugs are new, and which ones we need to  
close to
do a release.


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:37:09 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:37:09 +0000
Subject: [postgis-devel] Issue 11 in postgis: intersection - possible Bug
Message-ID: <0016e640985ad240ad04600a5671@google.com>

Updates:
	Status: WontFix

Comment #2 on issue 11 by mark.cav... at siriusit.co.uk: intersection -  
possible Bug
http://code.google.com/p/postgis/issues/detail?id=11

Closing due to lack of activity.


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:41:09 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:41:09 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <0016e644ba1a2425b504600a6594@google.com>


Comment #3 on issue 89 by mark.cav... at siriusit.co.uk: transform()  
grid-shift 2nd chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Hi William,

I understand that in your case of a NAD83 -> NAD27 transformation, ignoring  
the datum
is an acceptable error to you, but I can't see this being the case with all
applications and all datum shifts. We see people being caught out a lot  
because
they've installed the grid shift files on one server (and not another) and  
wonder why
the results beween 2 servers are different.

 From a strictness point of view, I would argue that any transformation  
requested by
the user that cannot be achieved using the current installation should  
throw an ERROR
rather than trying to second-guess the user. At least then it would be very  
clear
that they need to re-install PROJ.4 rather than wondering why they are  
getting
erroneus results.

Frank, what are your thoughts on this?


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:45:10 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:45:10 +0000
Subject: [postgis-devel] Issue 93 in postgis: ST_Extent() and
	ST_Estimated_Extent() return BOX2DFLOAT4s
Message-ID: <00151751146c7891d204600a73b3@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 93 by mark.cav... at siriusit.co.uk: ST_Extent() and  
ST_Estimated_Extent() return BOX2DFLOAT4s
http://code.google.com/p/postgis/issues/detail?id=93

In the case of ST_Extent(), this is serious because it means that
ST_Extent(col) will never return the exact extent of a column - it will
always be inflated by a small amount due to the extra conversion between
BOX3D and BOX2DFLOAT4.

* BOX2DFLOAT4s should never be exposed to the user, especially in that
ST_Extent() returns a string containing BOX (a legacy PostgreSQL type)
rather than BOX3D *

ST_Estimated_Extent() should also return a string beginning "BOX3D" for the
same reason.




--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:49:10 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:49:10 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <001636499441d22adf04600a812e@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 94 by mark.cav... at siriusit.co.uk: Rename folders/files to be more  
consistent
http://code.google.com/p/postgis/issues/detail?id=94

With the clear split between liblwgeom and the PostgreSQL-specific lwgeom/
directory, it would make sense to rename the lwgeom/ directory to postgis/.

Similarly I'd like to suggest renaming the following files:

lwpostgis.sql -> postgis.sql
liblwpostgis  -> libpostgis-1.4

I think this will make things much clearer. Also by adding in the version
number into the PostgreSQL shared library, it means moving ahead that
developers/users can easily have multiple versions installed which I see as
being very useful in the time ahead.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 02:53:11 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 10:53:11 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <0016362835a62f84ed04600a9039@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 95 by mark.cav... at siriusit.co.uk: PostGIS 1.4 documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Most of the examples in the documentation still refer to the non ST_
variants of the PostGIS functions.

Given that these functions are deprecated, we really should not be trying
to encourage their use ;)




--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:23:26 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:23:26 +0000
Subject: [postgis-devel] Issue 96 in postgis: ST_Multi on the new SQL-MM
	curve types should return a MULTICURVE
Message-ID: <0016e64652e258f23e04600afcd9@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 96 by mark.cav... at siriusit.co.uk: ST_Multi on the new SQL-MM  
curve types should return a MULTICURVE
http://code.google.com/p/postgis/issues/detail?id=96

postgis=# select
st_astext(st_multi(st_geomfromtext('COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1,
1 0),(1 0, 0 1))')));
                       st_astext
------------------------------------------------------
  COMPOUNDCURVE(CIRCULARSTRING(0 0,1 1,1 0),(1 0,0 1))

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:27:27 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:27:27 +0000
Subject: [postgis-devel] Issue 97 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <00151750eebab90dc804600b0a0e@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 97 by mark.cav... at siriusit.co.uk: Rename LWCURVE to LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=97

See explanation here:

http://postgis.refractions.net/pipermail/postgis-devel/2008-December/004421.html

The confusion stems from the fact that internally what we call a curve is
actually a circularstring; hence when reading code it gets very confusing
since in the SQL-MM spec, a curve is an abstract supertype and not a real  
type.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From mark.cave-ayland at siriusit.co.uk  Fri Jan  9 03:29:04 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 09 Jan 2009 11:29:04 +0000
Subject: [postgis-devel] TODO list for 1.4
Message-ID: <49673500.1060903@siriusit.co.uk>

Hi everyone,

I've just done a braindump into the GBT with regards to things that I 
really should be done for 1.4 with the aim of trying to find out how 
close we are to release.

Please add anything you feel should be included in 1.4 to the GBT marked 
with a milestone of 1.4. Note I've revised the sorting order again to 
make things a little clearer.


ATB.

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Fri Jan  9 03:31:28 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:31:28 +0000
Subject: [postgis-devel] Issue 98 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <00163616489918dc3e04600b1959@google.com>

Status: Accepted
Owner: mark.cav... at siriusit.co.uk
Labels: Milestone-1.4

New issue 98 by mark.cav... at siriusit.co.uk: Rename LWCURVE to LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=98

See explanation here:

http://postgis.refractions.net/pipermail/postgis-devel/2008-December/004421.html

The confusion stems from the fact that internally what we call a curve is
actually a circularstring; hence when reading code it gets very confusing
since in the SQL-MM spec, a curve is an abstract supertype and not a real  
type.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:35:28 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:35:28 +0000
Subject: [postgis-devel] Issue 98 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <000e0cd6ac9e68aef004600b271a@google.com>

Updates:
	Status: Duplicate

Comment #1 on issue 98 by mark.cav... at siriusit.co.uk: Rename LWCURVE to  
LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=98

(No comment was entered for this change.)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:39:29 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:39:29 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <000e0cd6ac9ebb63fa04600b3594@google.com>


Comment #1 on issue 95 by mark.cav... at siriusit.co.uk: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Hmmm I also just noticed that the operators section is empty in the 1.4-SVN
documentation too :(


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:43:30 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:43:30 +0000
Subject: [postgis-devel] Issue 34 in postgis: .prj creation by pgsql2shp
Message-ID: <0016e645b9b41b73dc04600b4408@google.com>


Comment #20 on issue 34 by mark.cav... at siriusit.co.uk: .prj creation by  
pgsql2shp
http://code.google.com/p/postgis/issues/detail?id=34

Can we mark this as done? Or have people still not done enough testing in  
1.3 branch?


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:47:30 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:47:30 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <000e0cd517c86dc1d004600b529e@google.com>


Comment #4 on issue 89 by william.... at acm.org: transform() grid-shift 2nd  
chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Mark,

Yep, I've had exactly the problem you cite: the Ubuntu and Debian PostGIS  
packages I
was using lacked the grid-shift files and I was scratching my head  
wondering why my
NAD83->NAD27 transformation did nothing.  Had to build my own PostGIS to  
fix it --
and that was long before I patched PostGIS for this issue.  However, I  
believe my
patch provides adequate safeguards for this problem.  I believe the other  
reasons I
give for the behavior I advocate are of equal or greater importance.  To  
briefly
summarize them:

* My patch throws a warning, so the user knows something is wrong unless  
they have
actively suppressed warnings.  (Improving that warning by identifying the  
offending
geometry would be an important improvement to my patch.  I'll try to do it  
if the
team doesn't have the resources to do so, though your C skills are surely  
far
stronger than mine.)

* In all other cases (AFAIK), PostGIS simply "wraps" proj.4 behavior and a
knowledgeable user expects to see that behavior propagated without change.   
PostGIS
does not abort transformations outside the defined grid-shift region; its  
cs2cs
utility glides past this problem without even a warning.

* I'm just a newbie to cartographic grid shifts, but from reading the proj.4
documentation, I don't think that NAD27 is unusual in being defined over a  
limited
region.  Anyone who's using grid shifts should know the limitations of what  
they're
doing.  Thus, if they present geometries for transformation outside the  
defined
region, they presumably wish to obtain the transformation in all cases,  
even if it
cannot be grid-shifted.  I believe this behavior manifests the "principle  
of least
surprise."

Whatever y'all decide, thanks so much for what you're doing!

-- Bill

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:51:31 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:51:31 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <001636164899c4cfac04600b60ef@google.com>


Comment #2 on issue 95 by robe.... at cityofboston.gov: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Its still in the old section. It is on my todo and Kevin's todo to figure  
out how to
bring it into the new section.

I think Kevin was talking about new tags to describe the operators -- Here  
is a
snippet from his email.  Kevin you want to do the template and I'll move  
over the
operators.  Let me know if you need help with the xsl.  I think I can write  
the xsl
stylesheet, but not sure how to integrate it with the doc book build.

Maybe something like this:
http://www.docbook.org/tdg/en/html/ch05.html#ex.addsect6
and extend the refentry to include an operatorsynopsis or something.

---Other relevant excerpts from our correspondence - snippet from Kevin's  
email to me --
  I've been
fighting with getting the Operators moved over, but, there doesn't seem
to be proper tags for an operator type.  It looks funny using the
standard functionsynopsis tag.  I'm thinking that a custom xsl parser
could be written and and added to the docbook xsl parser.  I've done
very little to no work with stylesheets in the past.  Any idea how we
can make such a thing happen?



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 03:55:32 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:55:32 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <0016e64084b22ca3a804600b6ffa@google.com>


Comment #5 on issue 89 by william.... at acm.org: transform() grid-shift 2nd  
chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Correction: 2nd bullet above, second sentence, first word, "PosgGIS" should  
read
"proj.4".  Sorry.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From robe.dnd at cityofboston.gov  Fri Jan  9 03:56:47 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 9 Jan 2009 06:56:47 -0500
Subject: [postgis-devel] [Pierre.Racine@sbf.ulaval.ca:
	[postgis-users]Enabling Tables or HTML in the PostGIS Wiki]
In-Reply-To: <20090109100216.GF35093@keybit.net>
References: <20090109100216.GF35093@keybit.net>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20544221A@ZDND.DND.boston.cob>

I'd be all for this.  Trying to write documentation in wiki format is
terribly annoying though I understand the concern of html
injection/defamation.

Alternatively I guess for now he could just post a link. 


If we could give out special accounts and let those accounts be able to
post in HTML, I think that would be ideal.  Can we have both html and
wiki style controlled by account? So the generic account wiki can only
post in wiki style and special accounts can post in HTML?

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
Sent: Friday, January 09, 2009 5:02 AM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] [Pierre.Racine at sbf.ulaval.ca:
[postgis-users]Enabling Tables or HTML in the PostGIS Wiki]

Any chance to fix this ?
Pierre is trying to use the postgis wiki as the central web page for th
WKTRaster...

--strk;

----- Forwarded message from Pierre Racine <Pierre.Racine at sbf.ulaval.ca>
-----

Date: Mon, 5 Jan 2009 14:02:34 -0500
From: "Pierre Racine" <Pierre.Racine at sbf.ulaval.ca>
Subject: [postgis-users] Enabling Tables or HTML in the PostGIS Wiki 
Reply-To: PostGIS Users Discussion
<postgis-users at postgis.refractions.net>
To: <postgis-users at postgis.refractions.net>
X-BeenThere: postgis-users at postgis.refractions.net

Hi, 

I was trying to make a table in a page of the PostGIS wiki without
success. I could find that the wiki engine is PhpWiki and had a look at
its documentation
(http://www.nvg.ntnu.no/phpwiki/index.php/TextFormattingRules). It's
normally possible to insert tables but it does not work in the PostGIS
wiki. 

Otherwise it seems possible to enable HTML tag in the PhpWiki
configuration (look at the last phrase of this page
(http://postgis.refractions.net/support/wiki/index.php?TextFormattingRul
es)). This must be done by the wiki administrator. Who is the
administrator? 

Enabling HTML would allow us to build much more attractive/comprehensive
pages... 

Thanks, 

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

----- End forwarded message -----
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From codesite-noreply at google.com  Fri Jan  9 03:59:33 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 11:59:33 +0000
Subject: [postgis-devel] Issue 34 in postgis: .prj creation by pgsql2shp
Message-ID: <0016e644ddec81805a04600b7da9@google.com>

Updates:
	Status: Fixed

Comment #21 on issue 34 by robe.... at cityofboston.gov: .prj creation by  
pgsql2shp
http://code.google.com/p/postgis/issues/detail?id=34

I'm all for closing this out.  Someone can reopen it if they feel the  
need.  I've
tested the 1.3.6 under OpenSUSE, Vista, and Windows 2000 and seems to  
generate the
.prj fine.  I've only tested the 1.4 under OpenSUSE, but plan to test 1.4  
under
Windows 2000, XP and Vista before release.

I have opened both OpenSUSE and Windows generated with ArcGIS 9.3 on a  
Windows 2000
and that seems to overlay them correctly against other data in another  
projection.
Also had someone else do the same test under Windows XP (ArcGIS 9.3).  He  
said it worked.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 04:53:02 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 12:53:02 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <0016e644ddecc87e3504600c3cb1@google.com>

Updates:
	Status: Testing
	Owner: robe.... at cityofboston.gov

Comment #3 on issue 95 by robe.... at cityofboston.gov: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Are you sure most.  Most seemed to have the new ST.  Anyrate I fixed the  
few I found
that were an issue.  Can you point out others you see that are missing the  
ST_?

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 05:05:07 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 13:05:07 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <0016e644ba1a03f89b04600c684a@google.com>


Comment #4 on issue 95 by mark.cav... at siriusit.co.uk: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Okay... maybe most was a little exaggeration! I guess it was just the  
sections I was
looking at:

4.1.1
4.1.2
4.3.1
4.4.1
4.6.1


Most of them are GeomFromText() missing the ST_ prefix, which I assume  
since we are
moving towards SQL-MM should be the way forward?


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 05:12:08 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 13:12:08 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <000e0cd6ae8c1c6fd104600c8138@google.com>


Comment #5 on issue 95 by robe.... at cityofboston.gov: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Alright that's what I thought.  I macro replaced all those -- so check it  
out and see
if I missed a spot.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Fri Jan  9 05:58:15 2009
From: strk at keybit.net (strk)
Date: Fri, 9 Jan 2009 14:58:15 +0100
Subject: [postgis-devel] About the ST_ prefix
Message-ID: <20090109135815.GB54902@keybit.net>

I noticed you're switching a lot postgis functions to
start with the ST_ prefix, no matter wheter they are
or not defined by ISO/SQLMM.

What's the rationale behind that ?

If I'm not wrong the OGC standard had its own naming
for the same functions, and I tought it was planned
for postgis to keep the no-prefix
functions as primary and add the compliant-version on
top ?

--strk;

 GIS & Flash consultant/developer           ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From robe.dnd at cityofboston.gov  Fri Jan  9 06:14:05 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 9 Jan 2009 09:14:05 -0500
Subject: [postgis-devel] About the ST_ prefix
In-Reply-To: <20090109135815.GB54902@keybit.net>
References: <20090109135815.GB54902@keybit.net>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054422DB@ZDND.DND.boston.cob>

Someone else mentioned this. Yes part of me wishes it wasn't so.

The thinking (who's thinking was this?  Maybe Paul) was that it would be
easier if people didn't have to 
worry about putting ST_ or not putting ST_ in front of functions.  also
the functions appear nicely together to compensate for the fact that
we didn't put the functions in a schema.

Having now worked with SQL Server 2008 a bit.  They don't put ST in
front of functions that are obviously not OGC compliant and are their
own creation.  
I suspect other spatial databases follow that convention -- of using a
different prefix for their custom things or no prefix at all.

To compensate for this compromise - that may lead people to believe taht
all ST_s are compliant, that is why we have this section

http://postgis.refractions.net/documentation/manual-svn/ch08.html#id2665
244

So people who only want to use compliant functions can look at that list
and only use those.



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
Sent: Friday, January 09, 2009 8:58 AM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] About the ST_ prefix

I noticed you're switching a lot postgis functions to
start with the ST_ prefix, no matter wheter they are
or not defined by ISO/SQLMM.

What's the rationale behind that ?

If I'm not wrong the OGC standard had its own naming
for the same functions, and I tought it was planned
for postgis to keep the no-prefix
functions as primary and add the compliant-version on
top ?

--strk;

 GIS & Flash consultant/developer           ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From codesite-noreply at google.com  Fri Jan  9 07:25:20 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 15:25:20 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <0016e64355de6da80404600e5da5@google.com>


Comment #1 on issue 94 by robe.... at cityofboston.gov: Rename folders/files  
to be more consistent
http://code.google.com/p/postgis/issues/detail?id=94

I'm okay with renaming to postgis.sql and even renaming the foler.  Would  
it be too
much to ask to move the postgis.sql file back to the root where the
spatial_ref_sys.sql is.  It is too much of a brain cramp for me to look for  
it
elsewhere :)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan  9 08:25:43 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 16:25:43 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <0016361e87f05fa71604600f3598@google.com>


Comment #6 on issue 89 by william.... at acm.org: transform() grid-shift 2nd  
chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Mark, my previous comment omitted (a) the real root cause of this problem  
and (b)
two possible fixes that might leave us both reasonably satisfied.

Real root cause, highlighted by your last remark:  proj.4's error return  
code
currently makes no distinction between (1) unavailable grid shift files and  
(2)
points that fall outside the boundaries of an available grid shift file.

Best possible fix: PostGIS would throw an error in case 1 and throw a  
warning in
case 2 -- but there's presently no way for PostGIS to distinguish between  
the two
cases.  Any chance you could get the proj.4 team to add a distinct error  
code and
message for case 2?

Second-choice fix: return NULL when proj.4 reports a grid-shift error (in  
either
error case above).  The user who wishes to obtain a non-grid-shifted  
transform as a
fallback could then do so with coalesce().  On the other hand, a user who
unexpectedly has rows with geometries that fall outside the area for which  
the grid
shift is defined could easily identify all such rows in a single SELECT,  
which is
impossible if you throw an error on the first offense.  Finally, users who  
are
missing a necessary grid-shift file at least won't get SLIGHTLY different  
answers
from systems that have the necessary files; this should make it easier for  
them to
find their real problem.

Throwing a generic error like PostGIS now does makes it very difficult for  
a user
whose table contains a subset of rows with geometries outside a grid-shift  
region to
identify those offending rows.  The user must discover the boundaries of  
the grid
shift file (how?), then craft a query to find geometries that fall outside  
tha area.

One last thought about improving the warning in my preferred fix:  my  
current patch
throws a warning for every offending POINT; this increases error-handling  
load by
several orders of magnitude for complex geometries.  Better would be to  
throw one
warning for every GEOMETRY with an offending point, identifying the  
offendor by the
first line of the geometry's summary() plus the coordinates of the first  
point in
the geometry and the first offending point (if different).  I haven't dug  
into the
PostGIS transform code enough to see how difficult this might be.

Sorry to belabor this, but the current generic error behavior really cost  
me a lot
of time, and I'd like to save others the inconvenience.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From kneufeld at refractions.net  Fri Jan  9 08:41:54 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 09 Jan 2009 08:41:54 -0800
Subject: [postgis-devel]
	[Pierre.Racine@sbf.ulaval.ca:	[postgis-users]Enabling
	Tables or HTML in the PostGIS Wiki]
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20544221A@ZDND.DND.boston.cob>
References: <20090109100216.GF35093@keybit.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20544221A@ZDND.DND.boston.cob>
Message-ID: <49677E52.50405@refractions.net>

I put in another request to our IT department to have this looked at.
-- Kevin

Obe, Regina wrote:
> I'd be all for this.  Trying to write documentation in wiki format is
> terribly annoying though I understand the concern of html
> injection/defamation.
> 
> Alternatively I guess for now he could just post a link. 
> 
> 
> If we could give out special accounts and let those accounts be able to
> post in HTML, I think that would be ideal.  Can we have both html and
> wiki style controlled by account? So the generic account wiki can only
> post in wiki style and special accounts can post in HTML?
> 
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
> Sent: Friday, January 09, 2009 5:02 AM
> To: postgis-devel at postgis.refractions.net
> Subject: [postgis-devel] [Pierre.Racine at sbf.ulaval.ca:
> [postgis-users]Enabling Tables or HTML in the PostGIS Wiki]
> 
> Any chance to fix this ?
> Pierre is trying to use the postgis wiki as the central web page for th
> WKTRaster...
> 
> --strk;
> 
> ----- Forwarded message from Pierre Racine <Pierre.Racine at sbf.ulaval.ca>
> -----
> 
> Date: Mon, 5 Jan 2009 14:02:34 -0500
> From: "Pierre Racine" <Pierre.Racine at sbf.ulaval.ca>
> Subject: [postgis-users] Enabling Tables or HTML in the PostGIS Wiki 
> Reply-To: PostGIS Users Discussion
> <postgis-users at postgis.refractions.net>
> To: <postgis-users at postgis.refractions.net>
> X-BeenThere: postgis-users at postgis.refractions.net
> 
> Hi, 
> 
> I was trying to make a table in a page of the PostGIS wiki without
> success. I could find that the wiki engine is PhpWiki and had a look at
> its documentation
> (http://www.nvg.ntnu.no/phpwiki/index.php/TextFormattingRules). It's
> normally possible to insert tables but it does not work in the PostGIS
> wiki. 
> 
> Otherwise it seems possible to enable HTML tag in the PhpWiki
> configuration (look at the last phrase of this page
> (http://postgis.refractions.net/support/wiki/index.php?TextFormattingRul
> es)). This must be done by the wiki administrator. Who is the
> administrator? 
> 
> Enabling HTML would allow us to build much more attractive/comprehensive
> pages... 
> 
> Thanks, 
> 
> Pierre
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> ----- End forwarded message -----
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From kneufeld at refractions.net  Fri Jan  9 08:56:04 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 09 Jan 2009 08:56:04 -0800
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
In-Reply-To: <001636164899c4cfac04600b60ef@google.com>
References: <001636164899c4cfac04600b60ef@google.com>
Message-ID: <496781A4.6020703@refractions.net>

Oh, right.... K, I'll try to play with this a bit more this weekend.
-- Kevin

codesite-noreply at google.com wrote:
> 
> Comment #2 on issue 95 by robe.... at cityofboston.gov: PostGIS 1.4 
> documentation update
> http://code.google.com/p/postgis/issues/detail?id=95
> 
> Its still in the old section. It is on my todo and Kevin's todo to 
> figure out how to
> bring it into the new section.
> 
> I think Kevin was talking about new tags to describe the operators -- 
> Here is a
> snippet from his email.  Kevin you want to do the template and I'll move 
> over the
> operators.  Let me know if you need help with the xsl.  I think I can 
> write the xsl
> stylesheet, but not sure how to integrate it with the doc book build.
> 
> Maybe something like this:
> http://www.docbook.org/tdg/en/html/ch05.html#ex.addsect6
> and extend the refentry to include an operatorsynopsis or something.
> 
> ---Other relevant excerpts from our correspondence - snippet from 
> Kevin's email to me --
>  I've been
> fighting with getting the Operators moved over, but, there doesn't seem
> to be proper tags for an operator type.  It looks funny using the
> standard functionsynopsis tag.  I'm thinking that a custom xsl parser
> could be written and and added to the docbook xsl parser.  I've done
> very little to no work with stylesheets in the past.  Any idea how we
> can make such a thing happen?
> 
> 
> 
> -- 
> You received this message because you are listed in the owner
> or CC fields of this issue, or because you starred this issue.
> You may adjust your issue notification preferences at:
> http://code.google.com/hosting/settings
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From codesite-noreply at google.com  Fri Jan  9 09:01:54 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 09 Jan 2009 17:01:54 +0000
Subject: [postgis-devel] Issue 99 in postgis: shp2pgsql 'Only import DBF'
	error.
Message-ID: <00151750da48d3955104600fb697@google.com>

Status: New
Owner: ----

New issue 99 by brunocaponi: shp2pgsql 'Only import DBF' error.
http://code.google.com/p/postgis/issues/detail?id=99

What steps will reproduce the problem?
1. shp2pgsql -n input

What is the expected output? What do you see instead?
Must return all queries to insert only content of .DBF file, but that
returned empty (or only BEGIN;END;) queries.


What version of the product are you using? On what operating system?
postgis 1.3.5, linux - fedora 8.

Please provide any additional information below.
Inthe version 1.3.3 shp2pgsql -n works perfectly. Only change in the file
shp2pgsql.c is in:

if(readshape != 1 && DBFReadDeleted(hDBFHandle, j)) {
   continue;
}

but I don't debug the function DBFReadDeleted...



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at opengeo.org  Fri Jan  9 12:32:57 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 9 Jan 2009 12:32:57 -0800
Subject: [postgis-devel] Issue 19
Message-ID: <8251C17E-7399-434A-AC43-E7E84065D115@opengeo.org>

http://code.google.com/p/postgis/issues/detail?id=18

Mark, you've upgraded this to 1.4, so we should discuss. Your comment  
in the 8.4 block indicates you think we do need to re-check. I'm  
pretty sure right now our re-check just testings the float4 boxes  
again, so it doesn't accomplish anything. And I'm not sure our  
contract with users is to be anything but inexact (but overdetermined)  
on index searches.

Now, I think Kevin has some use cases where the float4 round causes  
issues. I guess "group by" for points, yes? I think that the use case  
of "faster for large geometries" outweighs the use case of "group by  
for points", but I could be wrong.

P.

PS - I see the recheck value getting set in the gist_consistent test,  
but where does the recheck then occur, if we return true?

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From strk at keybit.net  Fri Jan  9 12:58:50 2009
From: strk at keybit.net (strk)
Date: Fri, 9 Jan 2009 21:58:50 +0100
Subject: [postgis-devel] About the ST_ prefix
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054422DB@ZDND.DND.boston.cob>
References: <20090109135815.GB54902@keybit.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054422DB@ZDND.DND.boston.cob>
Message-ID: <20090109205850.GA59234@keybit.net>

On Fri, Jan 09, 2009 at 09:14:05AM -0500, Obe, Regina wrote:

> The thinking (who's thinking was this?  Maybe Paul) was that it would be
> easier if people didn't have to 
> worry about putting ST_ or not putting ST_ in front of functions. 

Indeed I wouldn't worry and *never* use it, unless doing code supposed
to be portable across ISO-SQLMM standard dbs, in which case I'd only use
ST_ prefixed ones and count on them to be standard.

Beside, doesn't OGC expect non-prefixed ones ?

--strk;



From kneufeld at refractions.net  Fri Jan  9 13:47:28 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 09 Jan 2009 13:47:28 -0800
Subject: [postgis-devel] Issue 19
In-Reply-To: <8251C17E-7399-434A-AC43-E7E84065D115@opengeo.org>
References: <8251C17E-7399-434A-AC43-E7E84065D115@opengeo.org>
Message-ID: <4967C5F0.1030103@refractions.net>

Paul Ramsey wrote:
> Now, I think Kevin has some use cases where the float4 round causes 
> issues. I guess "group by" for points, yes? I think that the use case of 
> "faster for large geometries" outweighs the use case of "group by for 
> points", but I could be wrong.
> 

I would agree.  Yes, group by for points does cause issues, but that's the nice thing about SQL ... there's often many 
ways to ask the same question.  In this case, grouping by the hex string works just fine.
-- Kevin


From robe.dnd at cityofboston.gov  Fri Jan  9 14:00:38 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 9 Jan 2009 17:00:38 -0500
Subject: [postgis-devel] About the ST_ prefix
In-Reply-To: <20090109205850.GA59234@keybit.net>
References: <20090109135815.GB54902@keybit.net><53F9CF533E1AA14EA1F8C5C08ABC08D2054422DB@ZDND.DND.boston.cob>
	<20090109205850.GA59234@keybit.net>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D205442AC9@ZDND.DND.boston.cob>

Yes I think OGC (the old standard is non-prefixed and the MM new is
ST_), but I've since forgotten old so except for GeometryType.
I use the term OGC interchangeable with MM (I mean OGC is really an
organization right so its a misnomer to begin with?)
   

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
Sent: Friday, January 09, 2009 3:59 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] About the ST_ prefix

On Fri, Jan 09, 2009 at 09:14:05AM -0500, Obe, Regina wrote:

> The thinking (who's thinking was this?  Maybe Paul) was that it would
be
> easier if people didn't have to 
> worry about putting ST_ or not putting ST_ in front of functions. 

Indeed I wouldn't worry and *never* use it, unless doing code supposed
to be portable across ISO-SQLMM standard dbs, in which case I'd only use
ST_ prefixed ones and count on them to be standard.

Beside, doesn't OGC expect non-prefixed ones ?

--strk;

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From kneufeld at refractions.net  Fri Jan  9 14:06:50 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 09 Jan 2009 14:06:50 -0800
Subject: [postgis-devel] About the ST_ prefix
In-Reply-To: <20090109205850.GA59234@keybit.net>
References: <20090109135815.GB54902@keybit.net>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054422DB@ZDND.DND.boston.cob>
	<20090109205850.GA59234@keybit.net>
Message-ID: <4967CA7A.4080207@refractions.net>

strk wrote:
> Beside, doesn't OGC expect non-prefixed ones ?

Possibly, but the latest OGC read is so heavily interlaced with SQLMM stuff, it makes one think that the two will 
eventually merge together.
-- Kevin


From mark.cave-ayland at siriusit.co.uk  Sat Jan 10 04:54:48 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Sat, 10 Jan 2009 12:54:48 +0000
Subject: [postgis-devel] Issue 19
In-Reply-To: <8251C17E-7399-434A-AC43-E7E84065D115@opengeo.org>
References: <8251C17E-7399-434A-AC43-E7E84065D115@opengeo.org>
Message-ID: <49689A98.9000004@siriusit.co.uk>

Paul Ramsey wrote:

> http://code.google.com/p/postgis/issues/detail?id=18
> 
> Mark, you've upgraded this to 1.4, so we should discuss. Your comment in 
> the 8.4 block indicates you think we do need to re-check. I'm pretty 
> sure right now our re-check just testings the float4 boxes again, so it 
> doesn't accomplish anything. And I'm not sure our contract with users is 
> to be anything but inexact (but overdetermined) on index searches.
> 
> Now, I think Kevin has some use cases where the float4 round causes 
> issues. I guess "group by" for points, yes? I think that the use case of 
> "faster for large geometries" outweighs the use case of "group by for 
> points", but I could be wrong.
> 
> P.

It wasn't supposed to be like that, although re-reading it now I see 
that it comes across differently than was intended. At the end of the 
day, there needs to be a compromise between usability and performance - 
and while I was originally for the RECHECK to help beginners, we now 
have a reasonable body of evidence that shows we are seriously 
penalising performance on large databases. So given that Kevin has a 
work-around, it makes more sense to add a note to the documentation and 
make the change.

> PS - I see the recheck value getting set in the gist_consistent test, 
> but where does the recheck then occur, if we return true?

The RECHECK is performed by the executor; the query planner inserts an 
extra join filter condition to re-evaluate the geometry as the join is 
executed.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Sat Jan 10 22:10:13 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 Jan 2009 06:10:13 +0000
Subject: [postgis-devel] Issue 18 in postgis: Remove RECHECK requirement on
	index
Message-ID: <0016362835a6daed6004602ed7f2@google.com>


Comment #2 on issue 18 by pwramsey3: Remove RECHECK requirement on index
http://code.google.com/p/postgis/issues/detail?id=18

Removed recheck from opclass definition, and from consistent test for 8.4+,  
in r3514.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sat Jan 10 22:14:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 Jan 2009 06:14:14 +0000
Subject: [postgis-devel] Issue 18 in postgis: Remove RECHECK requirement on
	index
Message-ID: <00151750d990387bd704602ee65d@google.com>

Updates:
	Status: Testing

Comment #3 on issue 18 by pwramsey3: Remove RECHECK requirement on index
http://code.google.com/p/postgis/issues/detail?id=18

(No comment was entered for this change.)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sat Jan 10 22:18:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 Jan 2009 06:18:14 +0000
Subject: [postgis-devel] Issue 4 in postgis: Problem with
	LWGEOM_collect_garray - never returns MultiX from MultiX?
Message-ID: <001517573cfa8865ff04602ef4b2@google.com>

Updates:
	Status: WontFix

Comment #3 on issue 4 by pwramsey3: Problem with LWGEOM_collect_garray -  
never returns MultiX from MultiX?
http://code.google.com/p/postgis/issues/detail?id=4

No answers or concerns. Err'ing on the side of stasis until we hear more.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sat Jan 10 22:22:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 Jan 2009 06:22:14 +0000
Subject: [postgis-devel] Issue 97 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <000e0cd6ae8cd72d8004602f02bb@google.com>


Comment #1 on issue 97 by pwramsey3: Rename LWCURVE to LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=97

Another issue with LWCURVE is that the changes are compartmentalized at the  
bottom of liblwgeom.h. This was
fine when it was a work-in-progress, but if we're going to support curves,  
we need to integrate their support
with the rest of the API, so that it is obvious when we're missing global  
support functions (lwcurve_free?).

If you're doing the re-naming house-keeping anyways, moving the struct  
defns with teh other structs, and casts
with other casts, etc, etc, would be good.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sat Jan 10 22:26:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 Jan 2009 06:26:14 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <00163630f62926875604602f1198@google.com>


Comment #2 on issue 94 by pwramsey3: Rename folders/files to be more  
consistent
http://code.google.com/p/postgis/issues/detail?id=94

Re-naming commonly known things (this name has been around for a while now)  
is generally bad, but since
we've already *moved* the file, we might as well re-name it too. I wish we  
could put a number on it without
breaking other things... postgis-14.sql. But then we'd have to number our  
so/dlls and then upgrades would get
even tricker, and then...


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at cleverelephant.ca  Sun Jan 11 14:00:53 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Sun, 11 Jan 2009 14:00:53 -0800
Subject: [postgis-devel] Toronto Code Sprint: March 7-10
Message-ID: <30fe546d0901111400i4b192724w439de72641c91e79@mail.gmail.com>

Community members,

Reminder, there is a Code Sprint event occurring this spring that
members of the "C tribe" of open source GIS projects might be
interested in attending.

  http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009

We have space for only about five more attendees, and a couple more
sponsors, so don't be shy (sponsors please contact me directly). Those
who have already signed up, please finalize your travel plans and mark
your attendance confirmed ASAP in case we have to cap attendance at
the event as we approach the date.

Thanks,

Paul


From mark.cave-ayland at siriusit.co.uk  Mon Jan 12 01:29:25 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 12 Jan 2009 09:29:25 +0000
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>
	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
Message-ID: <496B0D75.9020708@siriusit.co.uk>

Paul Ramsey wrote:

> I've looked, it's really not a big deal, I'm happy to do it, and I
> want to, since the memory implications for the loader are *massive*
> (fixing the loader requires more than just adding one line, it
> requires a replacement for lwfree_poly which actually does the deep
> free... so, 8 lines :) But still feels wrong to be building what
> should be library infrastructure into the loader.
> 
> I'm going ahead with it, it will allow me to finish up the GUI. Which,
> BTW, feels like a step backwards in code attractiveness, since I
> didn't re-write the core code in the end, just retrofitted the output
> handling.
> 
> P.


Hi Paul,

I've just done a fresh checkout of SVN trunk with this commit and I now 
get multiple double-free errors in shp2pgsql on "make check":


  loader/Arc.*** glibc detected *** ../loader/shp2pgsql: free(): invalid 
pointer: 0x00007fff3b79e290 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b5f6f59b948]
/lib/libc.so.6(cfree+0x76)[0x2b5f6f59da56]
../loader/shp2pgsql[0x4111e2]
../loader/shp2pgsql[0x40b831]
../loader/shp2pgsql[0x40bbf5]
../loader/shp2pgsql[0x40bd0d]
/lib/libc.so.6(__libc_start_main+0xe6)[0x2b5f6f5461a6]
../loader/shp2pgsql[0x4033a9]
======= Memory map: ========
00400000-00433000 r-xp 00000000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00633000-00634000 rw-p 00033000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00634000-00655000 rw-p 00634000 00:00 0 
  [heap]
2b5f6f30b000-2b5f6f327000 r-xp 00000000 fe:00 131628 
  /lib/ld-2.7.so
2b5f6f327000-2b5f6f32e000 rw-p 2b5f6f327000 00:00 0
2b5f6f526000-2b5f6f528000 rw-p 0001b000 fe:00 131628 
  /lib/ld-2.7.so
2b5f6f528000-2b5f6f672000 r-xp 00000000 fe:00 131625 
  /lib/libc-2.7.so
2b5f6f672000-2b5f6f871000 ---p 0014a000 fe:00 131625 
  /lib/libc-2.7.so
2b5f6f871000-2b5f6f874000 r--p 00149000 fe:00 131625 
  /lib/libc-2.7.so
2b5f6f874000-2b5f6f876000 rw-p 0014c000 fe:00 131625 
  /lib/libc-2.7.so
2b5f6f876000-2b5f6f87b000 rw-p 2b5f6f876000 00:00 0
2b5f6f87b000-2b5f6f8fd000 r-xp 00000000 fe:00 131624 
  /lib/libm-2.7.so
2b5f6f8fd000-2b5f6fafc000 ---p 00082000 fe:00 131624 
  /lib/libm-2.7.so
2b5f6fafc000-2b5f6fafe000 rw-p 00081000 fe:00 131624 
  /lib/libm-2.7.so
2b5f6fafe000-2b5f6fb00000 rw-p 2b5f6fafe000 00:00 0
2b5f6fb00000-2b5f6fb16000 r-xp 00000000 fe:00 131609 
  /lib/libgcc_s.so.1
2b5f6fb16000-2b5f6fd16000 ---p 00016000 fe:00 131609 
  /lib/libgcc_s.so.1
2b5f6fd16000-2b5f6fd17000 rw-p 00016000 fe:00 131609 
  /lib/libgcc_s.so.1
2b5f70000000-2b5f70021000 rw-p 2b5f70000000 00:00 0
2b5f70021000-2b5f74000000 ---p 2b5f70021000 00:00 0
7fff3b78a000-7fff3b79f000 rw-p 7ffffffea000 00:00 0 
  [stack]
7fff3b7ff000-7fff3b800000 r-xp 7fff3b7ff000 00:00 0 
  [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 
  [vsyscall]
./run_test: line 153:  7366 Aborted                 ${SHP2PGSQL} 
${TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
  failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
  loader/ArcM.*** glibc detected *** ../loader/shp2pgsql: double free or 
corruption (out): 0x00007fff9fd90880 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b6a0afa9948]
/lib/libc.so.6(cfree+0x76)[0x2b6a0afaba56]
../loader/shp2pgsql[0x4111e2]
../loader/shp2pgsql[0x40b831]
../loader/shp2pgsql[0x40bbf5]
../loader/shp2pgsql[0x40bd0d]
/lib/libc.so.6(__libc_start_main+0xe6)[0x2b6a0af541a6]
../loader/shp2pgsql[0x4033a9]
======= Memory map: ========
00400000-00433000 r-xp 00000000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00633000-00634000 rw-p 00033000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00634000-00655000 rw-p 00634000 00:00 0 
  [heap]
2b6a0ad19000-2b6a0ad35000 r-xp 00000000 fe:00 131628 
  /lib/ld-2.7.so
2b6a0ad35000-2b6a0ad3c000 rw-p 2b6a0ad35000 00:00 0
2b6a0af34000-2b6a0af36000 rw-p 0001b000 fe:00 131628 
  /lib/ld-2.7.so
2b6a0af36000-2b6a0b080000 r-xp 00000000 fe:00 131625 
  /lib/libc-2.7.so
2b6a0b080000-2b6a0b27f000 ---p 0014a000 fe:00 131625 
  /lib/libc-2.7.so
2b6a0b27f000-2b6a0b282000 r--p 00149000 fe:00 131625 
  /lib/libc-2.7.so
2b6a0b282000-2b6a0b284000 rw-p 0014c000 fe:00 131625 
  /lib/libc-2.7.so
2b6a0b284000-2b6a0b289000 rw-p 2b6a0b284000 00:00 0
2b6a0b289000-2b6a0b30b000 r-xp 00000000 fe:00 131624 
  /lib/libm-2.7.so
2b6a0b30b000-2b6a0b50a000 ---p 00082000 fe:00 131624 
  /lib/libm-2../run_test: line 153:  7372 Aborted 
${SHP2PGSQL} ${TEST}.shp $_tblname > ${TMPDIR}/loader 2> 
${TMPDIR}/loader.err
  failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
  loader/ArcZ.*** glibc detected *** ../loader/shp2pgsql: double free or 
corruption (out): 0x00007ffffade08d0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2affaff57948]
/lib/libc.so.6(cfree+0x76)[0x2affaff59a56]
../loader/shp2pgsql[0x4111e2]
../loader/shp2pgsql[0x40b831]
../loader/shp2pgsql[0x40bbf5]
../loader/shp2pgsql[0x40bd0d]
/lib/libc.so.6(__libc_start_main+0xe6)[0x2affaff021a6]
../loader/shp2pgsql[0x4033a9]
======= Memory map: ========
00400000-00433000 r-xp 00000000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00633000-00634000 rw-p 00033000 fe:05 1057318 
  /home/pg83/src/postgis-svn/trunk/loader/shp2pgsql
00634000-00655000 rw-p 00634000 00:00 0 
  [heap]
2affafcc7000-2affafce3000 r-xp 00000000 fe:00 131628 
  /lib/ld-2.7.so
2affafce3000-2affafcea000 rw-p 2affafce3000 00:00 0
2affafee2000-2affafee4000 rw-p 0001b000 fe:00 131628 
  /lib/ld-2.7.so
2affafee4000-2affb002e000 r-xp 00000000 fe:00 131625 
  /lib/libc-2.7.so
2affb002e000-2affb022d000 ---p 0014a000 fe:00 131625 
  /lib/libc-2.7.so
2affb022d000-2affb0230000 r--p 00149000 fe:00 131625 
  /lib/libc-2.7.so
2affb0230000-2affb0232000 rw-p 0014c000 fe:00 131625 
  /lib/libc-2.7.so
2affb0232000-2affb0237000 rw-p 2affb0232000 00:00 0
2affb0237000-2affb02b9000 r-xp 00000000 fe:00 131624 
  /lib/libm-2.7.so
2affb02b9000-2affb04b8000 ---p 00082000 fe:00 131624 
  /lib/libm-2.7.so
2affb04b8000-2affb04ba000 rw-p 00081000 fe:00 131624 
  /lib/libm-2.7.so
2affb04ba000-2affb04bc000 rw-p 2affb04ba000 00:00 0
2affb04bc000-2affb04d2000 r-xp 00000000 fe:00 131609 
  /lib/libgcc_s.so.1
2affb04d2000-2affb06d2000 ---p 00016000 fe:00 131609 
  /lib/libgcc_s.so.1
2affb06d2000-2affb06d3000 rw-p 00016000 fe:00 131609 
  /lib/libgcc_s.so.1
2affb4000000-2affb4021000 rw-p 2affb4000000 00:00 0
2affb4021000-2affb8000000 ---p 2affb4021000 00:00 0
7ffffadcd000-7ffffade2000 rw-p 7ffffffea000 00:00 0 
  [stack]
7ffffadfe000-7ffffadff000 r-xp 7ffffadfe000 00:00 0 
  [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 
  [vsyscall]
./run_test: line 153:  7378 Aborted                 ${SHP2PGSQL} 
${TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
  failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
  loader/Polygon.*** glibc detected *** ../loader/shp2pgsql: double free 
or corruption (out): 0x00007ffff3c63740 ***


Any chance you could take a look?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Mon Jan 12 03:27:41 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 11:27:41 +0000
Subject: [postgis-devel] Issue 95 in postgis: PostGIS 1.4 documentation
	update
Message-ID: <0015174ff5d60cebeb046047657c@google.com>


Comment #6 on issue 95 by mark.cav... at siriusit.co.uk: PostGIS 1.4  
documentation update
http://code.google.com/p/postgis/issues/detail?id=95

Thanks Regina, that look good to me. So it's now just the operators  
outstanding,
which hopefully you and Kevin will be able to solve :)


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 03:32:41 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 11:32:41 +0000
Subject: [postgis-devel] Issue 97 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <0016e64f50fef974d804604776db@google.com>


Comment #2 on issue 97 by mark.cav... at siriusit.co.uk: Rename LWCURVE to  
LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=97

+1 from me - I found exactly the same thing when I was trying to find some  
of the
CIRCULARSTRING crashes. Well, since I RFC'd this before Xmas and no was has
commented, I'll go and ahead and make this happen (will probably take a few  
days as
we have a show this week)...


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 03:36:42 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 11:36:42 +0000
Subject: [postgis-devel] Issue 18 in postgis: Remove RECHECK requirement on
	index
Message-ID: <0016e643594651ce1304604785fa@google.com>


Comment #4 on issue 18 by mark.cav... at siriusit.co.uk: Remove RECHECK  
requirement on index
http://code.google.com/p/postgis/issues/detail?id=18

Excellent. One of things I've been thinking is that with this change (and  
also
potential alignment changes after 1.4), how do we benchmark this to show it  
actually
is an improvement? At the moment, I don't think there is anything in the  
regression
tests to do this...


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 03:40:43 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 11:40:43 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <00151750da5aa9800b04604793d8@google.com>


Comment #3 on issue 94 by mark.cav... at siriusit.co.uk: Rename folders/files  
to be more consistent
http://code.google.com/p/postgis/issues/detail?id=94

Regina: this also brings in the issue that since PROJ.4 is compulsary for  
SVN trunk,
should we automatically #include spatial_ref_sys into postgis.sql?

Paul: I don't have a problem with renaming files on a minor version bump.  
Anything
that changes a minor release screams "there have been some changes here,  
please test
first before deployment". So as long as we document this, I don't see this  
being a
problem.

Also, I'd still like to propose version numbering the so/DLL - this will  
make
testing/installing multiple versions so much easier. I don't see upgrades  
being a
problem, since you don't need to know the name of so/DLL containing a  
function to be
able to drop it, and the upgrade script for version X already knows the  
name of its
own so/DLL. I'm sure we can also devise something that will flag big  
warnings/errors
if mixed so/DLL versions are present in the system catalogs.


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 03:54:44 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 11:54:44 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <0016e645b8f6d32d60046047c5c6@google.com>


Comment #4 on issue 94 by robe.... at cityofboston.gov: Rename folders/files  
to be more consistent
http://code.google.com/p/postgis/issues/detail?id=94

Mark,

The answer to your question about spatial_ref_sys.sql is NO.

The reason I feel that way is if I'm doing a hard dump reload -- I have a  
lot of
custom records in my spatial_ref_sys and I may not care to load the ones  
you have or
I may want a partial set to save space.  This is not true with the  
functions.  I
always want all of those :).  Call me selfish :)---.

I'm all for going hog wild on stamping 1.4.  1.4 will be a big change and  
it would be
really nice if I can run both simultaneously on the same PostgreSQL service  
and then
slowly port over at my leisure.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 06:41:37 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 14:41:37 +0000
Subject: [postgis-devel] Issue 12 in postgis: precision problem in
	ST_Intersection 
Message-ID: <0016e645b9b49db2c104604a1adf@google.com>


Comment #2 on issue 12 by christiangda: precision problem in ST_Intersection
http://code.google.com/p/postgis/issues/detail?id=12

Hi,
   I tried with the new version and got the same result.

SELECT postgis_full_version();
"POSTGIS="1.3.5" GEOS="3.0.3-CAPI-1.4.2" PROJ="Rel. 4.6.1, 21 August 2008"  
USE_STATS
(procs from 1.3.4 need upgrade)"

SELECT version();
"PostgreSQL 8.3.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)  
4.3.0
20080428 (Red Hat 4.3.0-8)"

regards,
Christian

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Mon Jan 12 07:01:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 15:01:14 +0000
Subject: [postgis-devel] Issue 12 in postgis: precision problem in
	ST_Intersection 
Message-ID: <000e0cd4cd76cd468004604a60f9@google.com>


Comment #3 on issue 12 by robe.... at cityofboston.gov: precision problem in  
ST_Intersection
http://code.google.com/p/postgis/issues/detail?id=12

I'm not sure this is fixable isn't this the same issue as was brought up in  
this thread

http://postgis.refractions.net/pipermail/postgis-users/2008-December/022277.html


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at cleverelephant.ca  Mon Jan 12 08:20:14 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 12 Jan 2009 08:20:14 -0800
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <496B0D75.9020708@siriusit.co.uk>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>
	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
	<496B0D75.9020708@siriusit.co.uk>
Message-ID: <54C35A4A-B76B-4242-A81A-C0BDDDC69ED9@cleverelephant.ca>

Yes, I'll fix this. I'm pretty sure I found this already, but may have  
only fixed it in my GUI sandbox.
P

On Jan 12, 2009, at 1:29 AM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>> I've looked, it's really not a big deal, I'm happy to do it, and I
>> want to, since the memory implications for the loader are *massive*
>> (fixing the loader requires more than just adding one line, it
>> requires a replacement for lwfree_poly which actually does the deep
>> free... so, 8 lines :) But still feels wrong to be building what
>> should be library infrastructure into the loader.
>> I'm going ahead with it, it will allow me to finish up the GUI.  
>> Which,
>> BTW, feels like a step backwards in code attractiveness, since I
>> didn't re-write the core code in the end, just retrofitted the output
>> handling.
>> P.
>
>
> Hi Paul,
>
> I've just done a fresh checkout of SVN trunk with this commit and I  
> now get multiple double-free errors in shp2pgsql on "make check":
>
>
> loader/Arc.*** glibc detected *** ../loader/shp2pgsql: free():  
> invalid pointer: 0x00007fff3b79e290 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2b5f6f59b948]
> /lib/libc.so.6(cfree+0x76)[0x2b5f6f59da56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2b5f6f5461a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2b5f6f30b000-2b5f6f327000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2b5f6f327000-2b5f6f32e000 rw-p 2b5f6f327000 00:00 0
> 2b5f6f526000-2b5f6f528000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2b5f6f528000-2b5f6f672000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f672000-2b5f6f871000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f871000-2b5f6f874000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f874000-2b5f6f876000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f876000-2b5f6f87b000 rw-p 2b5f6f876000 00:00 0
> 2b5f6f87b000-2b5f6f8fd000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6f8fd000-2b5f6fafc000 ---p 00082000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6fafc000-2b5f6fafe000 rw-p 00081000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6fafe000-2b5f6fb00000 rw-p 2b5f6fafe000 00:00 0
> 2b5f6fb00000-2b5f6fb16000 r-xp 00000000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f6fb16000-2b5f6fd16000 ---p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f6fd16000-2b5f6fd17000 rw-p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f70000000-2b5f70021000 rw-p 2b5f70000000 00:00 0
> 2b5f70021000-2b5f74000000 ---p 2b5f70021000 00:00 0
> 7fff3b78a000-7fff3b79f000 rw-p 7ffffffea000 00:00 0  [stack]
> 7fff3b7ff000-7fff3b800000 r-xp 7fff3b7ff000 00:00 0  [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
> ./run_test: line 153:  7366 Aborted                 ${SHP2PGSQL} $ 
> {TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/ArcM.*** glibc detected *** ../loader/shp2pgsql: double free  
> or corruption (out): 0x00007fff9fd90880 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2b6a0afa9948]
> /lib/libc.so.6(cfree+0x76)[0x2b6a0afaba56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2b6a0af541a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2b6a0ad19000-2b6a0ad35000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2b6a0ad35000-2b6a0ad3c000 rw-p 2b6a0ad35000 00:00 0
> 2b6a0af34000-2b6a0af36000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2b6a0af36000-2b6a0b080000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b080000-2b6a0b27f000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b27f000-2b6a0b282000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b282000-2b6a0b284000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b284000-2b6a0b289000 rw-p 2b6a0b284000 00:00 0
> 2b6a0b289000-2b6a0b30b000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2b6a0b30b000-2b6a0b50a000 ---p 00082000 fe:00 131624  /lib/libm-2../ 
> run_test: line 153:  7372 Aborted ${SHP2PGSQL} ${TEST}.shp $_tblname  
> > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/ArcZ.*** glibc detected *** ../loader/shp2pgsql: double free  
> or corruption (out): 0x00007ffffade08d0 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2affaff57948]
> /lib/libc.so.6(cfree+0x76)[0x2affaff59a56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2affaff021a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2affafcc7000-2affafce3000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2affafce3000-2affafcea000 rw-p 2affafce3000 00:00 0
> 2affafee2000-2affafee4000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2affafee4000-2affb002e000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2affb002e000-2affb022d000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2affb022d000-2affb0230000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2affb0230000-2affb0232000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2affb0232000-2affb0237000 rw-p 2affb0232000 00:00 0
> 2affb0237000-2affb02b9000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2affb02b9000-2affb04b8000 ---p 00082000 fe:00 131624  /lib/libm-2.7.so
> 2affb04b8000-2affb04ba000 rw-p 00081000 fe:00 131624  /lib/libm-2.7.so
> 2affb04ba000-2affb04bc000 rw-p 2affb04ba000 00:00 0
> 2affb04bc000-2affb04d2000 r-xp 00000000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb04d2000-2affb06d2000 ---p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb06d2000-2affb06d3000 rw-p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb4000000-2affb4021000 rw-p 2affb4000000 00:00 0
> 2affb4021000-2affb8000000 ---p 2affb4021000 00:00 0
> 7ffffadcd000-7ffffade2000 rw-p 7ffffffea000 00:00 0  [stack]
> 7ffffadfe000-7ffffadff000 r-xp 7ffffadfe000 00:00 0  [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
> ./run_test: line 153:  7378 Aborted                 ${SHP2PGSQL} $ 
> {TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/Polygon.*** glibc detected *** ../loader/shp2pgsql: double  
> free or corruption (out): 0x00007ffff3c63740 ***
>
>
> Any chance you could take a look?
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From codesite-noreply at google.com  Mon Jan 12 08:24:18 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 Jan 2009 16:24:18 +0000
Subject: [postgis-devel] Issue 18 in postgis: Remove RECHECK requirement on
	index
Message-ID: <0016e64418dcdb41f604604b8902@google.com>


Comment #5 on issue 18 by pwramsey3: Remove RECHECK requirement on index
http://code.google.com/p/postgis/issues/detail?id=18

Regressing for performance is practically impossible, as far as I know. If  
we were a huge organizations, we would
maintain a set of older versions we could run a performance regression  
suite on, but we're not, and I cannot
think of any general purpose way to build performance improvement testing  
into our regression suite so it could
make a meaningful determination with just one copy of the software.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Mon Jan 12 08:30:44 2009
From: strk at keybit.net (strk)
Date: Mon, 12 Jan 2009 17:30:44 +0100
Subject: [postgis-devel] Transparent GiST indexing support ?
Message-ID: <20090112163044.GD25688@keybit.net>

(Context: WKTRaster project)

Out of the box, can the currently min-required postgres
version provide transparent GiST support for a RASTER type
by means of implicit casts to some of the BOX* types ? 

TIA

--strk;


From pramsey at cleverelephant.ca  Mon Jan 12 08:56:18 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 12 Jan 2009 08:56:18 -0800
Subject: [postgis-devel] Transparent GiST indexing support ?
In-Reply-To: <20090112163044.GD25688@keybit.net>
References: <20090112163044.GD25688@keybit.net>
Message-ID: <131FD7AB-F956-4524-8223-6CE2A876AA23@cleverelephant.ca>

It doesn't seem like it:

create type pseudobox as ( minx real, miny real, maxx real, maxy real );
create table boxtest ( bb pseudobox ) ;
insert into boxtest values ( '(0, 0, 1, 1)' );
create function pseudo2box ( pseudobox ) returns box2d language sql  
immutable as
'select (''BOX('' || ($1).minx || '' '' || ($1).miny || '','' ||  
($1).maxx || '' '' || ($1).maxy || '')'')::box2d';
create cast ( pseudobox as box2d) with function pseudo2box(pseudobox);
select bb::box2d from boxtest;

pramsey=# create index bboxtest_idx on boxtest using gist ( bb  
gist_geometry_ops );
ERROR:  operator class "gist_geometry_ops" does not accept data type  
pseudobox
pramsey=# create index bboxtest_idx on boxtest using gist  
( pseudo2box(bb) gist_geometry_ops );
ERROR:  operator class "gist_geometry_ops" does not accept data type  
box2d
pramsey=# create index bboxtest_idx on boxtest using gist  
( geometry(pseudo2box(bb))
CREATE INDEX



On Jan 12, 2009, at 8:30 AM, strk wrote:

> (Context: WKTRaster project)
>
> Out of the box, can the currently min-required postgres
> version provide transparent GiST support for a RASTER type
> by means of implicit casts to some of the BOX* types ?
>
> TIA
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From pramsey at opengeo.org  Mon Jan 12 09:38:14 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 12 Jan 2009 09:38:14 -0800
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <496B0D75.9020708@siriusit.co.uk>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>
	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>
	<496B0D75.9020708@siriusit.co.uk>
Message-ID: <10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>

I take it back, I cannot reproduce this on a clean check-out... make  
check runs fine for me, as do other shp2pgsql runs on various files...  
are you certain you are complete up-to-date?

P

On Jan 12, 2009, at 1:29 AM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>> I've looked, it's really not a big deal, I'm happy to do it, and I
>> want to, since the memory implications for the loader are *massive*
>> (fixing the loader requires more than just adding one line, it
>> requires a replacement for lwfree_poly which actually does the deep
>> free... so, 8 lines :) But still feels wrong to be building what
>> should be library infrastructure into the loader.
>> I'm going ahead with it, it will allow me to finish up the GUI.  
>> Which,
>> BTW, feels like a step backwards in code attractiveness, since I
>> didn't re-write the core code in the end, just retrofitted the output
>> handling.
>> P.
>
>
> Hi Paul,
>
> I've just done a fresh checkout of SVN trunk with this commit and I  
> now get multiple double-free errors in shp2pgsql on "make check":
>
>
> loader/Arc.*** glibc detected *** ../loader/shp2pgsql: free():  
> invalid pointer: 0x00007fff3b79e290 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2b5f6f59b948]
> /lib/libc.so.6(cfree+0x76)[0x2b5f6f59da56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2b5f6f5461a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2b5f6f30b000-2b5f6f327000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2b5f6f327000-2b5f6f32e000 rw-p 2b5f6f327000 00:00 0
> 2b5f6f526000-2b5f6f528000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2b5f6f528000-2b5f6f672000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f672000-2b5f6f871000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f871000-2b5f6f874000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f874000-2b5f6f876000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2b5f6f876000-2b5f6f87b000 rw-p 2b5f6f876000 00:00 0
> 2b5f6f87b000-2b5f6f8fd000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6f8fd000-2b5f6fafc000 ---p 00082000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6fafc000-2b5f6fafe000 rw-p 00081000 fe:00 131624  /lib/libm-2.7.so
> 2b5f6fafe000-2b5f6fb00000 rw-p 2b5f6fafe000 00:00 0
> 2b5f6fb00000-2b5f6fb16000 r-xp 00000000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f6fb16000-2b5f6fd16000 ---p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f6fd16000-2b5f6fd17000 rw-p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2b5f70000000-2b5f70021000 rw-p 2b5f70000000 00:00 0
> 2b5f70021000-2b5f74000000 ---p 2b5f70021000 00:00 0
> 7fff3b78a000-7fff3b79f000 rw-p 7ffffffea000 00:00 0  [stack]
> 7fff3b7ff000-7fff3b800000 r-xp 7fff3b7ff000 00:00 0  [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
> ./run_test: line 153:  7366 Aborted                 ${SHP2PGSQL} $ 
> {TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/ArcM.*** glibc detected *** ../loader/shp2pgsql: double free  
> or corruption (out): 0x00007fff9fd90880 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2b6a0afa9948]
> /lib/libc.so.6(cfree+0x76)[0x2b6a0afaba56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2b6a0af541a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2b6a0ad19000-2b6a0ad35000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2b6a0ad35000-2b6a0ad3c000 rw-p 2b6a0ad35000 00:00 0
> 2b6a0af34000-2b6a0af36000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2b6a0af36000-2b6a0b080000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b080000-2b6a0b27f000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b27f000-2b6a0b282000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b282000-2b6a0b284000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2b6a0b284000-2b6a0b289000 rw-p 2b6a0b284000 00:00 0
> 2b6a0b289000-2b6a0b30b000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2b6a0b30b000-2b6a0b50a000 ---p 00082000 fe:00 131624  /lib/libm-2../ 
> run_test: line 153:  7372 Aborted ${SHP2PGSQL} ${TEST}.shp $_tblname  
> > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/ArcZ.*** glibc detected *** ../loader/shp2pgsql: double free  
> or corruption (out): 0x00007ffffade08d0 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x2affaff57948]
> /lib/libc.so.6(cfree+0x76)[0x2affaff59a56]
> ../loader/shp2pgsql[0x4111e2]
> ../loader/shp2pgsql[0x40b831]
> ../loader/shp2pgsql[0x40bbf5]
> ../loader/shp2pgsql[0x40bd0d]
> /lib/libc.so.6(__libc_start_main+0xe6)[0x2affaff021a6]
> ../loader/shp2pgsql[0x4033a9]
> ======= Memory map: ========
> 00400000-00433000 r-xp 00000000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00633000-00634000 rw-p 00033000 fe:05 1057318  /home/pg83/src/ 
> postgis-svn/trunk/loader/shp2pgsql
> 00634000-00655000 rw-p 00634000 00:00 0  [heap]
> 2affafcc7000-2affafce3000 r-xp 00000000 fe:00 131628  /lib/ld-2.7.so
> 2affafce3000-2affafcea000 rw-p 2affafce3000 00:00 0
> 2affafee2000-2affafee4000 rw-p 0001b000 fe:00 131628  /lib/ld-2.7.so
> 2affafee4000-2affb002e000 r-xp 00000000 fe:00 131625  /lib/libc-2.7.so
> 2affb002e000-2affb022d000 ---p 0014a000 fe:00 131625  /lib/libc-2.7.so
> 2affb022d000-2affb0230000 r--p 00149000 fe:00 131625  /lib/libc-2.7.so
> 2affb0230000-2affb0232000 rw-p 0014c000 fe:00 131625  /lib/libc-2.7.so
> 2affb0232000-2affb0237000 rw-p 2affb0232000 00:00 0
> 2affb0237000-2affb02b9000 r-xp 00000000 fe:00 131624  /lib/libm-2.7.so
> 2affb02b9000-2affb04b8000 ---p 00082000 fe:00 131624  /lib/libm-2.7.so
> 2affb04b8000-2affb04ba000 rw-p 00081000 fe:00 131624  /lib/libm-2.7.so
> 2affb04ba000-2affb04bc000 rw-p 2affb04ba000 00:00 0
> 2affb04bc000-2affb04d2000 r-xp 00000000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb04d2000-2affb06d2000 ---p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb06d2000-2affb06d3000 rw-p 00016000 fe:00 131609  /lib/ 
> libgcc_s.so.1
> 2affb4000000-2affb4021000 rw-p 2affb4000000 00:00 0
> 2affb4021000-2affb8000000 ---p 2affb4021000 00:00 0
> 7ffffadcd000-7ffffade2000 rw-p 7ffffffea000 00:00 0  [stack]
> 7ffffadfe000-7ffffadff000 r-xp 7ffffadfe000 00:00 0  [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
> ./run_test: line 153:  7378 Aborted                 ${SHP2PGSQL} $ 
> {TEST}.shp $_tblname > ${TMPDIR}/loader 2> ${TMPDIR}/loader.err
> failed (running shp2pgsql: /tmp/pgis_reg_6744/loader.err)
> loader/Polygon.*** glibc detected *** ../loader/shp2pgsql: double  
> free or corruption (out): 0x00007ffff3c63740 ***
>
>
> Any chance you could take a look?
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From mark.cave-ayland at siriusit.co.uk  Mon Jan 12 09:50:58 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 12 Jan 2009 17:50:58 +0000
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>	<496B0D75.9020708@siriusit.co.uk>
	<10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>
Message-ID: <496B8302.1050609@siriusit.co.uk>

Paul Ramsey wrote:

> I take it back, I cannot reproduce this on a clean check-out... make 
> check runs fine for me, as do other shp2pgsql runs on various files... 
> are you certain you are complete up-to-date?
> 
> P

Yeah; I just blew away my complete trunk directory and re-checked out 
the source and I still see the error. This is on Debian Lenny, amd64 
architecture if that helps?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Mon Jan 12 09:52:08 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 12 Jan 2009 17:52:08 +0000
Subject: [postgis-devel] Toronto Code Sprint: March 7-10
In-Reply-To: <30fe546d0901111400i4b192724w439de72641c91e79@mail.gmail.com>
References: <30fe546d0901111400i4b192724w439de72641c91e79@mail.gmail.com>
Message-ID: <496B8348.4090904@siriusit.co.uk>

Paul Ramsey wrote:

> Community members,
> 
> Reminder, there is a Code Sprint event occurring this spring that
> members of the "C tribe" of open source GIS projects might be
> interested in attending.
> 
>   http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
> 
> We have space for only about five more attendees, and a couple more
> sponsors, so don't be shy (sponsors please contact me directly). Those
> who have already signed up, please finalize your travel plans and mark
> your attendance confirmed ASAP in case we have to cap attendance at
> the event as we approach the date.
> 
> Thanks,
> 
> Paul


Hi Paul,

I'm pleased to say that I now have approval to come to the sprint - so 
count me in! :D


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at cleverelephant.ca  Mon Jan 12 10:08:20 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 12 Jan 2009 10:08:20 -0800
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <496B8302.1050609@siriusit.co.uk>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>	<496B0D75.9020708@siriusit.co.uk>
	<10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>
	<496B8302.1050609@siriusit.co.uk>
Message-ID: <1A5D60E7-AE13-4605-8B6B-5065D58A03BD@cleverelephant.ca>

I'll see if it shows under Linux, I'm in os/x...

P

On Jan 12, 2009, at 9:50 AM, Mark Cave-Ayland wrote:

> Paul Ramsey wrote:
>
>> I take it back, I cannot reproduce this on a clean check-out...  
>> make check runs fine for me, as do other shp2pgsql runs on various  
>> files... are you certain you are complete up-to-date?
>> P
>
> Yeah; I just blew away my complete trunk directory and re-checked  
> out the source and I still see the error. This is on Debian Lenny,  
> amd64 architecture if that helps?
>
>
> ATB,
>
> Mark.
>
> -- 
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From pramsey at cleverelephant.ca  Mon Jan 12 10:30:39 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 12 Jan 2009 10:30:39 -0800
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <1A5D60E7-AE13-4605-8B6B-5065D58A03BD@cleverelephant.ca>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>	<496B0D75.9020708@siriusit.co.uk>
	<10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>
	<496B8302.1050609@siriusit.co.uk>
	<1A5D60E7-AE13-4605-8B6B-5065D58A03BD@cleverelephant.ca>
Message-ID: <DEDBE170-7D16-49DD-88A3-BC2170E0592B@cleverelephant.ca>

Found and removed from trunk. I had found it before in OS/X. There's  
an uninitialized &bbox getting passed around. I just changed it to a  
NULL, since it's never used.

On Jan 12, 2009, at 10:08 AM, Paul Ramsey wrote:

> I'll see if it shows under Linux, I'm in os/x...
>
> P
>
> On Jan 12, 2009, at 9:50 AM, Mark Cave-Ayland wrote:
>
>> Paul Ramsey wrote:
>>
>>> I take it back, I cannot reproduce this on a clean check-out...  
>>> make check runs fine for me, as do other shp2pgsql runs on various  
>>> files... are you certain you are complete up-to-date?
>>> P
>>
>> Yeah; I just blew away my complete trunk directory and re-checked  
>> out the source and I still see the error. This is on Debian Lenny,  
>> amd64 architecture if that helps?
>>
>>
>> ATB,
>>
>> Mark.
>>
>> -- 
>> Mark Cave-Ayland
>> Sirius Corporation - The Open Source Experts
>> http://www.siriusit.co.uk
>> T: +44 870 608 0063
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> --
> Paul Ramsey
> pramsey at cleverelephant.ca
> +1 250 885 0632
>


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From mark.cave-ayland at siriusit.co.uk  Tue Jan 13 00:59:45 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 13 Jan 2009 08:59:45 +0000
Subject: [postgis-devel] Memory in the Meantime
In-Reply-To: <DEDBE170-7D16-49DD-88A3-BC2170E0592B@cleverelephant.ca>
References: <30fe546d0901070850s6e98f19fhf3aec8d896f9c522@mail.gmail.com>	<4965328B.3020901@siriusit.co.uk>	<30fe546d0901071525g4d9a275ay98a656a17db6abd6@mail.gmail.com>	<496B0D75.9020708@siriusit.co.uk>	<10D8D423-B17A-4790-B12A-AF27AA82B5A3@opengeo.org>	<496B8302.1050609@siriusit.co.uk>	<1A5D60E7-AE13-4605-8B6B-5065D58A03BD@cleverelephant.ca>
	<DEDBE170-7D16-49DD-88A3-BC2170E0592B@cleverelephant.ca>
Message-ID: <496C5801.4080401@siriusit.co.uk>

Paul Ramsey wrote:

> Found and removed from trunk. I had found it before in OS/X. There's an 
> uninitialized &bbox getting passed around. I just changed it to a NULL, 
> since it's never used.

/me goes and looks at the patch...

Ah I see. While the constructors allow a pointer to a BBOX to be passed 
into in, the free/release destructors assume that these pointers have 
been manually allocated with lwalloc(). One for the documentation 
methinks...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Tue Jan 13 04:01:45 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 13 Jan 2009 12:01:45 +0000
Subject: [postgis-devel] Issue 97 in postgis: Rename LWCURVE to LWCIRCSTRING
Message-ID: <0016361e86aec2a50504605bfc02@google.com>

Updates:
	Status: Testing

Comment #3 on issue 97 by mark.cav... at siriusit.co.uk: Rename LWCURVE to  
LWCIRCSTRING
http://code.google.com/p/postgis/issues/detail?id=97

All done.

Please test to ensure that I didn't break too much :)


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Tue Jan 13 04:06:48 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 13 Jan 2009 12:06:48 +0000
Subject: [postgis-devel] Issue 85 in postgis: ST_Distance crashes on
	Circular String
Message-ID: <0015174ff5d6d41bf904605c0eb9@google.com>

Updates:
	Status: Fixed

Comment #5 on issue 85 by mark.cav... at siriusit.co.uk: ST_Distance crashes  
on Circular String
http://code.google.com/p/postgis/issues/detail?id=85

AFAICT the tests all pass with this in place, and so I'm moving it to fixed.


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From robe.dnd at cityofboston.gov  Tue Jan 13 05:21:59 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 13 Jan 2009 08:21:59 -0500
Subject: [postgis-devel] GeoJSON failing on 1.4
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>

I remember the KML failing for me on OpenSUSE, but don't remember the
geojson failing as well.  Is this normal?

-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From olivier.courtin at camptocamp.com  Tue Jan 13 05:25:12 2009
From: olivier.courtin at camptocamp.com (Courtin Olivier)
Date: Tue, 13 Jan 2009 14:25:12 +0100
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>
Message-ID: <021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com>


On Jan 13, 2009, at 2:21 PM, Obe, Regina wrote:

Regina,

> I remember the KML failing for me on OpenSUSE, but don't remember the
> geojson failing as well.  Is this normal?

It should not ;)
What kind of failure behaviour do you have ?

--
Olivier


From robe.dnd at cityofboston.gov  Tue Jan 13 05:33:09 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 13 Jan 2009 08:33:09 -0500
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>
	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>

Attached is my diff.  I'm not good at making sense of diffs.  but looks
to me like a bug in our regression test.  i had wiped out my 1.4 svn and
repulled down and compiled.

I'm assuming the diff is telling me that what is expected is

ERROR:  GeoJson: 'Curve' geometry type not supported.

and what is coming back is
ERROR:  GeoJson: 'CircularString' geometry type not supported.

 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Courtin Olivier
Sent: Tuesday, January 13, 2009 8:25 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] GeoJSON failing on 1.4


On Jan 13, 2009, at 2:21 PM, Obe, Regina wrote:

Regina,

> I remember the KML failing for me on OpenSUSE, but don't remember the
> geojson failing as well.  Is this normal?

It should not ;)
What kind of failure behaviour do you have ?

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


-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_34_diff
Type: application/octet-stream
Size: 14148 bytes
Desc: test_34_diff
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090113/d51fed39/attachment.obj>

From mark.cave-ayland at siriusit.co.uk  Tue Jan 13 05:52:37 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 13 Jan 2009 13:52:37 +0000
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>
Message-ID: <496C9CA5.5000607@siriusit.co.uk>

Obe, Regina wrote:

> Attached is my diff.  I'm not good at making sense of diffs.  but looks
> to me like a bug in our regression test.  i had wiped out my 1.4 svn and
> repulled down and compiled.
> 
> I'm assuming the diff is telling me that what is expected is
> 
> ERROR:  GeoJson: 'Curve' geometry type not supported.
> 
> and what is coming back is
> ERROR:  GeoJson: 'CircularString' geometry type not supported.

Ooops - that was me from this morning's commit :)  For some reason this 
didn't show up for me until I did a "make clean" several times in all 
the different directories which is why I missed it.

Will fix.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 13 06:11:27 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 13 Jan 2009 14:11:27 +0000
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>
Message-ID: <496CA10F.4020601@siriusit.co.uk>

Obe, Regina wrote:

> Attached is my diff.  I'm not good at making sense of diffs.  but looks
> to me like a bug in our regression test.  i had wiped out my 1.4 svn and
> repulled down and compiled.
> 
> I'm assuming the diff is telling me that what is expected is
> 
> ERROR:  GeoJson: 'Curve' geometry type not supported.
> 
> and what is coming back is
> ERROR:  GeoJson: 'CircularString' geometry type not supported.

Okay I think I'm done. Can you "svn up" and try again?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Tue Jan 13 06:14:52 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 13 Jan 2009 09:14:52 -0500
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <496CA10F.4020601@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com><53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>
	<496CA10F.4020601@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FF41@ZDND.DND.boston.cob>

Yap works now for both geojson and kml so its still just that nagging
regress_bdpoly which I guess we haven't resolved yet. 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 13, 2009 9:11 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] GeoJSON failing on 1.4

Obe, Regina wrote:

> Attached is my diff.  I'm not good at making sense of diffs.  but
looks
> to me like a bug in our regression test.  i had wiped out my 1.4 svn
and
> repulled down and compiled.
> 
> I'm assuming the diff is telling me that what is expected is
> 
> ERROR:  GeoJson: 'Curve' geometry type not supported.
> 
> and what is coming back is
> ERROR:  GeoJson: 'CircularString' geometry type not supported.

Okay I think I'm done. Can you "svn up" and try again?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From robe.dnd at cityofboston.gov  Tue Jan 13 06:40:13 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 13 Jan 2009 09:40:13 -0500
Subject: [postgis-devel] Can't compile Geos 3.1 under OpenSUSE anymore
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FFD5@ZDND.DND.boston.cob>

I assume this is because of the recent changes.  I did an svn up and a
reconfigure and then compile under OpenSUSE.

I get this error

 g++ -DHAVE_CONFIG_H -I. -I../source/headers -I../source/headers/geos
-I../source/headers -DGEOS_CAPI_VERSION=\"3.1.0-CAPI-1.5.0\"
-DGEOS_JTS_PORT=\"1.7.1\" -g -O2 -DGEOS_INLINE -Wall -ansi -pedantic
-Wno-long-long -MT libgeos_c_la-geos_c.lo -MD -MP -MF
.deps/libgeos_c_la-geos_c.Tpo -c geos_c.cpp -o libgeos_c_la-geos_c.o
>/dev/null 2>&1
mv -f .deps/libgeos_c_la-geos_c.Tpo .deps/libgeos_c_la-geos_c.Plo
make[1]: *** No rule to make target `geos_ts_c.cpp', needed by
`libgeos_c_la-geos_ts_c.lo'.  Stop.
make[1]: Leaving directory `/projects/geos-3.1.0SVN/capi'
make: *** [all-recursive] Error 1

Am I missing something?

Thanks,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Tue Jan 13 06:41:10 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 13 Jan 2009 14:41:10 +0000
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FF41@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com><53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>	<496CA10F.4020601@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20546FF41@ZDND.DND.boston.cob>
Message-ID: <496CA806.4070009@siriusit.co.uk>

Obe, Regina wrote:

> Yap works now for both geojson and kml so its still just that nagging
> regress_bdpoly which I guess we haven't resolved yet. 

It actually comes down to your current discussion on the GEOS list about 
the Z coordinate: 
http://lists.osgeo.org/pipermail/geos-devel/2009-January/003839.html.

For some reason, ST_BuildArea() returns the wrong Z coordinate for the 
regression tests which causes the returned polygon to have an unclosed 
ring if you consider 3 dimensions. You can clearly see this from the 
following output on 1.3:


postgis13=# select st_asewkt(st_geomfromtext('SRID=2;LINESTRING(0 0 2, 
10 0 4, 10 10 6, 0 10 8, 0 0 10)'));
WARNING:  OGC WKT expected, EWKT provided - use GeomFromEWKT() for this
CONTEXT:  SQL function "st_geomfromtext" statement 1
                        st_asewkt
-------------------------------------------------------
  SRID=2;LINESTRING(0 0 2,10 0 4,10 10 6,0 10 8,0 0 10)
(1 row)

postgis13=# select 
st_asewkt(st_buildarea(st_geomfromtext('SRID=2;LINESTRING(0 0 2, 10 0 4, 
10 10 6, 0 10 8, 0 0 10)')));
WARNING:  OGC WKT expected, EWKT provided - use GeomFromEWKT() for this
CONTEXT:  SQL function "st_geomfromtext" statement 1
                       st_asewkt
------------------------------------------------------
  SRID=2;POLYGON((0 0 10,0 10 8,10 10 6,10 0 4,0 0 2))
(1 row)


Since 1.4 nicely unifies the parser/unparser code, the back-conversion 
from GEOS to EWKT now trips the closed ring check which is why we now 
see the error.

I think the issue on hand is how closure is defined in the spec for 
geometries with > 2 dimensions, and hence whether the bug lies within 
GEOS or not. Martin, any comments?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 13 06:45:10 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 13 Jan 2009 14:45:10 +0000
Subject: [postgis-devel] Can't compile Geos 3.1 under OpenSUSE anymore
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FFD5@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FFD5@ZDND.DND.boston.cob>
Message-ID: <496CA8F6.8050900@siriusit.co.uk>

Obe, Regina wrote:

> I assume this is because of the recent changes.  I did an svn up and a
> reconfigure and then compile under OpenSUSE.
> 
> I get this error
> 
>  g++ -DHAVE_CONFIG_H -I. -I../source/headers -I../source/headers/geos
> -I../source/headers -DGEOS_CAPI_VERSION=\"3.1.0-CAPI-1.5.0\"
> -DGEOS_JTS_PORT=\"1.7.1\" -g -O2 -DGEOS_INLINE -Wall -ansi -pedantic
> -Wno-long-long -MT libgeos_c_la-geos_c.lo -MD -MP -MF
> .deps/libgeos_c_la-geos_c.Tpo -c geos_c.cpp -o libgeos_c_la-geos_c.o
>> /dev/null 2>&1
> mv -f .deps/libgeos_c_la-geos_c.Tpo .deps/libgeos_c_la-geos_c.Plo
> make[1]: *** No rule to make target `geos_ts_c.cpp', needed by
> `libgeos_c_la-geos_ts_c.lo'.  Stop.
> make[1]: Leaving directory `/projects/geos-3.1.0SVN/capi'
> make: *** [all-recursive] Error 1
> 
> Am I missing something?
> 
> Thanks,
> Regina

Hmmm the "ts" part implies this is something to do with the thread-safe 
API patch. Perhaps you need to re-run autogen.sh so that it picks up the 
new files? Failing that does a brand new checkout work?


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Tue Jan 13 07:02:15 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 13 Jan 2009 10:02:15 -0500
Subject: [postgis-devel] Can't compile Geos 3.1 under OpenSUSE anymore
In-Reply-To: <496CA8F6.8050900@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FFD5@ZDND.DND.boston.cob>
	<496CA8F6.8050900@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D205470051@ZDND.DND.boston.cob>

Mark,

Good thought.  I can't remember if I did an autogen or not, but just did
and my OpenSUSE is still compiling.

My MingW install which I did do an sh autogen.sh , configure, make
clean, make is failing with the same error

 g++ -DHAVE_CONFIG_H -I. -I. -I../source/headers
-I../source/headers/geos -I../source/headers
-DGEOS_CAPI_VERSION=\"3.1.0-CAPI-1.5.0\" -DGEOS_JTS_PORT=\"1.7.1\" -g
-O2 -DGEOS_INLINE -Wall -ansi -pedantic -Wno-long-long -MT
libgeos_c_la-geos_c.lo -MD -MP -MF .deps/libgeos_c_la-geos_c.Tpo -c
geos_c.cpp  -DDLL_EXPORT -DPIC -o .libs/libgeos_c_la-geos_c.o
 g++ -DHAVE_CONFIG_H -I. -I. -I../source/headers
-I../source/headers/geos -I../source/headers
-DGEOS_CAPI_VERSION=\"3.1.0-CAPI-1.5.0\" -DGEOS_JTS_PORT=\"1.7.1\" -g
-O2 -DGEOS_INLINE -Wall -ansi -pedantic -Wno-long-long -MT
libgeos_c_la-geos_c.lo -MD -MP -MF .deps/libgeos_c_la-geos_c.Tpo -c
geos_c.cpp -o libgeos_c_la-geos_c.o >/dev/null 2>&1
make[1]: *** No rule to make target `geos_ts_c.cpp', needed by
`libgeos_c_la-geos_ts_c.lo'.  Stop.
make[1]: Leaving directory `/D/SVNProjects/geos/trunk/capi'
make: *** [all-recursive] Error 1


Have you tried the latest one?

My next step is to blow out my geos source and start from scratch.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 13, 2009 9:45 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Can't compile Geos 3.1 under OpenSUSE
anymore

Obe, Regina wrote:

> I assume this is because of the recent changes.  I did an svn up and a
> reconfigure and then compile under OpenSUSE.
> 
> I get this error
> 
>  g++ -DHAVE_CONFIG_H -I. -I../source/headers -I../source/headers/geos
> -I../source/headers -DGEOS_CAPI_VERSION=\"3.1.0-CAPI-1.5.0\"
> -DGEOS_JTS_PORT=\"1.7.1\" -g -O2 -DGEOS_INLINE -Wall -ansi -pedantic
> -Wno-long-long -MT libgeos_c_la-geos_c.lo -MD -MP -MF
> .deps/libgeos_c_la-geos_c.Tpo -c geos_c.cpp -o libgeos_c_la-geos_c.o
>> /dev/null 2>&1
> mv -f .deps/libgeos_c_la-geos_c.Tpo .deps/libgeos_c_la-geos_c.Plo
> make[1]: *** No rule to make target `geos_ts_c.cpp', needed by
> `libgeos_c_la-geos_ts_c.lo'.  Stop.
> make[1]: Leaving directory `/projects/geos-3.1.0SVN/capi'
> make: *** [all-recursive] Error 1
> 
> Am I missing something?
> 
> Thanks,
> Regina

Hmmm the "ts" part implies this is something to do with the thread-safe 
API patch. Perhaps you need to re-run autogen.sh so that it picks up the

new files? Failing that does a brand new checkout work?


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From Pierre.Racine at sbf.ulaval.ca  Tue Jan 13 14:31:52 2009
From: Pierre.Racine at sbf.ulaval.ca (Pierre Racine)
Date: Tue, 13 Jan 2009 17:31:52 -0500
Subject: [postgis-devel] Toronto Code Sprint
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F4119@exch-be03.ulaval.ca>
Message-ID: <D58FF82475EA0A4A9347D3CE16B46E5F6F411A@exch-be03.ulaval.ca>

Will there be time for new project presentations?

I would love to present WKT Raster...

http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage

Pierre

>-----Message d'origine-----
>De : Pierre Racine 
>Envoyé : 13 janvier 2009 17:30
>À : Pierre Racine
>Objet : [postgis-devel] Toronto Code Sprint
>
>
>The 2009 Toronto Code Sprint is now set for March 7-10 at the Bond
>Place Hotel in Toronto, Canada.
>
>  http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
>
>We hope you will consider joining us for a worthy weekend of sprinting
>and getting connected.
>
>We are now looking for sponsors to cover venue and lunches during the
>sprint. If your organization wants to curry favor with a couple dozen
>influential geospatial programmers, this is a great chance. We are
>looking for just four sponsors at $500 each, please get in touch with
>me if you are interested in sponsoring this event.
>
>Thanks!
>
>Paul
>


From strk at keybit.net  Wed Jan 14 01:36:37 2009
From: strk at keybit.net (strk)
Date: Wed, 14 Jan 2009 10:36:37 +0100
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
Message-ID: <20090114093637.GD87941@keybit.net>

Hello hackers!
You might have read I'm in the process of starting
up with the RASTER type support for postgis.

I'd like to pick your minds about where you think
is more appropriate to develope the new code.

We have the CHIP type which is the closest already
available code to what we need to do in the initial
step. The CHIP functionality isn't documented at all
so maybe there aren't users out there and we could
modify it to add the additional support we need
(multiband, additional pixel types).

The advantage would be we'd already have some
drawing primitives.

Actually I asked if there was any user in 2006 and
got no answer back:
http://postgis.refractions.net/pipermail/postgis-devel/2006-May/002123.html

So, is it ok to you to drop support for CHIP and replace
it with RASTER ? Or do you prefer to see it cohexist ?
Note that RASTER would be a superset of CHIP anyway so if
both exists seems a waste of library size and stored procedures
to me.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From robe.dnd at cityofboston.gov  Wed Jan 14 03:55:48 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 14 Jan 2009 06:55:48 -0500
Subject: [postgis-devel] Toronto Code Sprint
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F411A@exch-be03.ulaval.ca>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F4119@exch-be03.ulaval.ca>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F411A@exch-be03.ulaval.ca>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D205470843@ZDND.DND.boston.cob>

I would hope so.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Pierre Racine
Sent: Tuesday, January 13, 2009 5:32 PM
To: postgis-devel at postgis.refractions.net
Subject: RE: [postgis-devel] Toronto Code Sprint

Will there be time for new project presentations?

I would love to present WKT Raster...

http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage

Pierre

>-----Message d'origine-----
>De : Pierre Racine 
>Envoyé : 13 janvier 2009 17:30
>À : Pierre Racine
>Objet : [postgis-devel] Toronto Code Sprint
>
>
>The 2009 Toronto Code Sprint is now set for March 7-10 at the Bond
>Place Hotel in Toronto, Canada.
>
>  http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
>
>We hope you will consider joining us for a worthy weekend of sprinting
>and getting connected.
>
>We are now looking for sponsors to cover venue and lunches during the
>sprint. If your organization wants to curry favor with a couple dozen
>influential geospatial programmers, this is a great chance. We are
>looking for just four sponsors at $500 each, please get in touch with
>me if you are interested in sponsoring this event.
>
>Thanks!
>
>Paul
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Thu Jan 15 02:41:08 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 15 Jan 2009 10:41:08 +0000
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <20090114093637.GD87941@keybit.net>
References: <20090114093637.GD87941@keybit.net>
Message-ID: <496F12C4.5020100@siriusit.co.uk>

strk wrote:

> Hello hackers!
> You might have read I'm in the process of starting
> up with the RASTER type support for postgis.
> 
> I'd like to pick your minds about where you think
> is more appropriate to develope the new code.
> 
> We have the CHIP type which is the closest already
> available code to what we need to do in the initial
> step. The CHIP functionality isn't documented at all
> so maybe there aren't users out there and we could
> modify it to add the additional support we need
> (multiband, additional pixel types).
> 
> The advantage would be we'd already have some
> drawing primitives.
> 
> Actually I asked if there was any user in 2006 and
> got no answer back:
> http://postgis.refractions.net/pipermail/postgis-devel/2006-May/002123.html
> 
> So, is it ok to you to drop support for CHIP and replace
> it with RASTER ? Or do you prefer to see it cohexist ?
> Note that RASTER would be a superset of CHIP anyway so if
> both exists seems a waste of library size and stored procedures
> to me.
> 
> --strk;


Hi strk,

AIUI from the wiki page at 
http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage, 
WKTRaster is being developed/hosted as a completely independent project 
with the aim being to merge into PostGIS as a later date - so my take 
would be to leave CHIP as it is until the project is stable enough to 
merge into PostGIS.

Since it is not mentioned at all in the standard documentation, I doubt 
it has that many users but it seems unfair to drop the CHIP support 
without having a well-tested replacement. I think that when WKTRaster 
puts out its first stable release is the right time to announce the 
deprecation of CHIP.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Thu Jan 15 09:59:18 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 15 Jan 2009 17:59:18 +0000
Subject: [postgis-devel] Issue 94 in postgis: Rename folders/files to be
	more consistent
Message-ID: <0016e644ddec25949504608937bf@google.com>


Comment #5 on issue 94 by mark.cav... at siriusit.co.uk: Rename folders/files  
to be more consistent
http://code.google.com/p/postgis/issues/detail?id=94

Okay, I've just committed the rename of lwpostgis.sql to postgis.sql, and  
the
embedding of the version number in the resulting .so/DLL file. It seems to  
work for
me, but let me know if I accidentally broken anything.

Next, I'll come along and rename the lwgeom/ directory to postgis.


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Thu Jan 15 15:37:13 2009
From: strk at keybit.net (strk)
Date: Fri, 16 Jan 2009 00:37:13 +0100
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <496F12C4.5020100@siriusit.co.uk>
References: <20090114093637.GD87941@keybit.net>
	<496F12C4.5020100@siriusit.co.uk>
Message-ID: <20090115233713.GG30648@keybit.net>

On Thu, Jan 15, 2009 at 10:41:08AM +0000, Mark Cave-Ayland wrote:

> AIUI from the wiki page at 
> http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage, 
> WKTRaster is being developed/hosted as a completely independent project 
> with the aim being to merge into PostGIS as a later date - so my take 
> would be to leave CHIP as it is until the project is stable enough to 
> merge into PostGIS.

Fair enough.
What about hosting it under the extras/ dir ?

--strk;


From mark.cave-ayland at siriusit.co.uk  Fri Jan 16 06:19:54 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 16 Jan 2009 14:19:54 +0000
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <20090115233713.GG30648@keybit.net>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk>
	<20090115233713.GG30648@keybit.net>
Message-ID: <4970978A.40806@siriusit.co.uk>

strk wrote:

> Fair enough.
> What about hosting it under the extras/ dir ?
> 
> --strk;

The main issue I can see is that we are trying to work hard to stabilise 
PostGIS by enforcing a policy of no API changes in point releases, and I 
think committing the WKTRaster work directly into the PostGIS will break 
what we are trying to achieve.

Since development is so new, I can see APIs changing rapidly and hence I 
think it would actually hold WKTRaster progress back by being restricted 
to the PostGIS release schedule. Otherwise you would be on the hook for 
bug fixing existing releases, and API changes would have to wait until 
the next minor release which could be a long time.

I honestly think that WKTRaster would be better hosted as a separate 
project until it reaches some form of maturity, since then you are free 
from any of these restrictions. Maybe a separate branch in the PostGIS 
repo would also work, although it would put a lot more work on your 
shoulders to correct the merge conflicts. I have absolutely no problem 
with discussions related to the project/release announcements appearing 
on the project mailing lists either.

What I believe will happen is that as the project progresses, it will 
soon mature to a steady state which should easily be determined by 
feedback on the -users mailing lists. This is then the right time to 
merge the code directly into the PostGIS codebase.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From Pierre.Racine at sbf.ulaval.ca  Fri Jan 16 06:58:39 2009
From: Pierre.Racine at sbf.ulaval.ca (Pierre Racine)
Date: Fri, 16 Jan 2009 09:58:39 -0500
Subject: [postgis-devel]Enabling Tables or HTML in the PostGIS Wiki] 
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F430E@exch-be03.ulaval.ca>
Message-ID: <D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca>

Kevin,

Any news on this? The wiki is very limited (no images, no files, no tables). We won't be able to construct a real contributor community with those limitations.

Pierre

>-----Message d'origine-----
>De : Pierre Racine 
>Envoyé : 15 janvier 2009 15:13
>À : Pierre Racine
>Objet : 
>
>I put in another request to our IT department to have this looked at.
>-- Kevin
>
>Obe, Regina wrote:
>> I'd be all for this.  Trying to write documentation in wiki format is
>> terribly annoying though I understand the concern of html
>> injection/defamation.
>> 
>> Alternatively I guess for now he could just post a link. 
>> 
>> 
>> If we could give out special accounts and let those accounts 
>be able to
>> post in HTML, I think that would be ideal.  Can we have both html and
>> wiki style controlled by account? So the generic account 
>wiki can only
>> post in wiki style and special accounts can post in HTML?
>> 
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On 
>Behalf Of strk
>> Sent: Friday, January 09, 2009 5:02 AM
>> To: postgis-devel at postgis.refractions.net
>> Subject: [postgis-devel] [Pierre.Racine at sbf.ulaval.ca:
>> [postgis-users]Enabling Tables or HTML in the PostGIS Wiki]
>> 
>> Any chance to fix this ?
>> Pierre is trying to use the postgis wiki as the central web 
>page for th
>> WKTRaster...
>> 
>> --strk;
>> 
>> ----- Forwarded message from Pierre Racine <Pierre.Racine at 
>sbf.ulaval.ca>
>> -----
>> 
>> Date: Mon, 5 Jan 2009 14:02:34 -0500
>> From: "Pierre Racine" <Pierre.Racine at sbf.ulaval.ca>
>> Subject: [postgis-users] Enabling Tables or HTML in the PostGIS Wiki 
>> Reply-To: PostGIS Users Discussion
>> <postgis-users at postgis.refractions.net>
>> To: <postgis-users at postgis.refractions.net>
>> X-BeenThere: postgis-users at postgis.refractions.net
>> 
>> Hi, 
>> 
>> I was trying to make a table in a page of the PostGIS wiki without
>> success. I could find that the wiki engine is PhpWiki and 
>had a look at
>> its documentation
>> (http://www.nvg.ntnu.no/phpwiki/index.php/TextFormattingRules). It's
>> normally possible to insert tables but it does not work in 
>the PostGIS
>> wiki. 
>> 
>> Otherwise it seems possible to enable HTML tag in the PhpWiki
>> configuration (look at the last phrase of this page
>> 
>(http://postgis.refractions.net/support/wiki/index.php?TextForm
>attingRul
>> es)). This must be done by the wiki administrator. Who is the
>> administrator? 
>> 
>> Enabling HTML would allow us to build much more 
>attractive/comprehensive
>> pages... 
>> 
>> Thanks, 
>> 
>> Pierre
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> 
>> ----- End forwarded message -----
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From strk at keybit.net  Fri Jan 16 07:11:37 2009
From: strk at keybit.net (strk)
Date: Fri, 16 Jan 2009 16:11:37 +0100
Subject: [postgis-devel]Enabling Tables or HTML in the PostGIS Wiki]
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F430E@exch-be03.ulaval.ca>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca>
Message-ID: <20090116151137.GF44057@keybit.net>

On Fri, Jan 16, 2009 at 09:58:39AM -0500, Pierre Racine wrote:
> Kevin,
> 
> Any news on this? The wiki is very limited (no images, no files, no tables). We won't be able to construct a real contributor community with those limitations.

I suggest you register the project on http://savannah.nongnu.org.
It takes time so the earlier the better.
Not that it provides a wiki actually, but it has RCS and trackers,
and web space (under cvs).

--strk;


From pramsey at cleverelephant.ca  Fri Jan 16 08:08:35 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 16 Jan 2009 08:08:35 -0800
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <4970978A.40806@siriusit.co.uk>
References: <20090114093637.GD87941@keybit.net>
	<496F12C4.5020100@siriusit.co.uk> <20090115233713.GG30648@keybit.net>
	<4970978A.40806@siriusit.co.uk>
Message-ID: <30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>

Branches are cheap. We had the raster GSOC project in a branch, no
reason not to have that one there. Once it reaches the functionality
level of "does something people might find useful" we can debate
whether the API is stable enough to move it into mainline releases.

P.

On Fri, Jan 16, 2009 at 6:19 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> strk wrote:
>
>> Fair enough.
>> What about hosting it under the extras/ dir ?
>>
>> --strk;
>
> The main issue I can see is that we are trying to work hard to stabilise
> PostGIS by enforcing a policy of no API changes in point releases, and I
> think committing the WKTRaster work directly into the PostGIS will break
> what we are trying to achieve.
>
> Since development is so new, I can see APIs changing rapidly and hence I
> think it would actually hold WKTRaster progress back by being restricted to
> the PostGIS release schedule. Otherwise you would be on the hook for bug
> fixing existing releases, and API changes would have to wait until the next
> minor release which could be a long time.
>
> I honestly think that WKTRaster would be better hosted as a separate project
> until it reaches some form of maturity, since then you are free from any of
> these restrictions. Maybe a separate branch in the PostGIS repo would also
> work, although it would put a lot more work on your shoulders to correct the
> merge conflicts. I have absolutely no problem with discussions related to
> the project/release announcements appearing on the project mailing lists
> either.
>
> What I believe will happen is that as the project progresses, it will soon
> mature to a steady state which should easily be determined by feedback on
> the -users mailing lists. This is then the right time to merge the code
> directly into the PostGIS codebase.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From kneufeld at refractions.net  Fri Jan 16 09:07:12 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 16 Jan 2009 09:07:12 -0800
Subject: [postgis-devel]Enabling Tables or HTML in the PostGIS Wiki]
In-Reply-To: <20090116151137.GF44057@keybit.net>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F430E@exch-be03.ulaval.ca>	<D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca>
	<20090116151137.GF44057@keybit.net>
Message-ID: <4970BEC0.50701@refractions.net>

If that works...

Sorry guys this is taking so long.  I keep bugging the high-ups to allocate some resources to address this.  I know 
we're swamped right now making several fiscal-end deliveries which probably plays part to the delay.

-- Kevin

strk wrote:
> On Fri, Jan 16, 2009 at 09:58:39AM -0500, Pierre Racine wrote:
>> Kevin,
>>
>> Any news on this? The wiki is very limited (no images, no files, no tables). We won't be able to construct a real contributor community with those limitations.
> 
> I suggest you register the project on http://savannah.nongnu.org.
> It takes time so the earlier the better.
> Not that it provides a wiki actually, but it has RCS and trackers,
> and web space (under cvs).
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From kneufeld at refractions.net  Fri Jan 16 09:16:15 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 16 Jan 2009 09:16:15 -0800
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk>
	<20090115233713.GG30648@keybit.net>	<4970978A.40806@siriusit.co.uk>
	<30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>
Message-ID: <4970C0DF.1030407@refractions.net>

Playing the devil's advocate here, but ...

Paul Ramsey wrote:
> Branches are cheap. 

Seriously?  I always thought back-patching and maintaining a current branch (autobuilds, website, documentation, etc) 
take up considerable resources.

-- Kevin


From robe.dnd at cityofboston.gov  Fri Jan 16 09:22:01 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 16 Jan 2009 12:22:01 -0500
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <4970C0DF.1030407@refractions.net>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk><20090115233713.GG30648@keybit.net>	<4970978A.40806@siriusit.co.uk><30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>
	<4970C0DF.1030407@refractions.net>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>

Playing devlis advocate to Kevin's devils advocate.

I personally think its fine and am with Paul on this.

1) WKT Raster has to live somewhere and it should live in the same
repository with PostGIS because that is the most likely place people
will expect to find it.

2) It is going to have to be back-patched at some point whether it lives
in its own branch in PostGIS repository or someplace else in the world.
So I consider the whole discussion about the difficulty of back-patching
moot.

Thanks,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Kevin Neufeld
Sent: Friday, January 16, 2009 12:16 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] WKTRaster: RASTER and CHIP

Playing the devil's advocate here, but ...

Paul Ramsey wrote:
> Branches are cheap. 

Seriously?  I always thought back-patching and maintaining a current
branch (autobuilds, website, documentation, etc) 
take up considerable resources.

-- Kevin
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From kneufeld at refractions.net  Fri Jan 16 09:25:33 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 16 Jan 2009 09:25:33 -0800
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk><20090115233713.GG30648@keybit.net>	<4970978A.40806@siriusit.co.uk><30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>	<4970C0DF.1030407@refractions.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
Message-ID: <4970C30D.6010100@refractions.net>

:)  Oh don't get me wrong, I agree it's probably the best course of action too.  I just thought the statement was funny.
-- Kevin

Obe, Regina wrote:
> Playing devlis advocate to Kevin's devils advocate.
> 
> I personally think its fine and am with Paul on this.
> 
> 1) WKT Raster has to live somewhere and it should live in the same
> repository with PostGIS because that is the most likely place people
> will expect to find it.
> 
> 2) It is going to have to be back-patched at some point whether it lives
> in its own branch in PostGIS repository or someplace else in the world.
> So I consider the whole discussion about the difficulty of back-patching
> moot.
> 
> Thanks,
> Regina 
> 
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
> Kevin Neufeld
> Sent: Friday, January 16, 2009 12:16 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] WKTRaster: RASTER and CHIP
> 
> Playing the devil's advocate here, but ...
> 
> Paul Ramsey wrote:
>> Branches are cheap. 
> 
> Seriously?  I always thought back-patching and maintaining a current
> branch (autobuilds, website, documentation, etc) 
> take up considerable resources.
> 
> -- Kevin
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mark.cave-ayland at siriusit.co.uk  Fri Jan 16 09:31:58 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 16 Jan 2009 17:31:58 +0000
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk><20090115233713.GG30648@keybit.net>	<4970978A.40806@siriusit.co.uk><30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>	<4970C0DF.1030407@refractions.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
Message-ID: <4970C48E.7010409@siriusit.co.uk>

Obe, Regina wrote:

> Playing devlis advocate to Kevin's devils advocate.
> 
> I personally think its fine and am with Paul on this.
> 
> 1) WKT Raster has to live somewhere and it should live in the same
> repository with PostGIS because that is the most likely place people
> will expect to find it.

This isn't necessarily the case; think pgrouting for an example of this 
type of project.

> 2) It is going to have to be back-patched at some point whether it lives
> in its own branch in PostGIS repository or someplace else in the world.
> So I consider the whole discussion about the difficulty of back-patching
> moot.

I think Paul summarised in his email what I was saying but in much fewer 
words; working in a branch is kinda okay as long as the WKTRaster 
developers don't mind constant merging from trunk/fixing things based on 
changes to the PostGIS core. Although my feeling is for the initial cut, 
it may be less work to host the project independently and do a first 
merge when it reaches a relatively stable point.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From strk at keybit.net  Fri Jan 16 09:40:13 2009
From: strk at keybit.net (strk)
Date: Fri, 16 Jan 2009 18:40:13 +0100
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
References: <20090114093637.GD87941@keybit.net>
	<4970C0DF.1030407@refractions.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
Message-ID: <20090116174013.GN44057@keybit.net>

On Fri, Jan 16, 2009 at 12:22:01PM -0500, Obe, Regina wrote:

> 2) It is going to have to be back-patched at some point whether it lives
> in its own branch in PostGIS repository or someplace else in the world.
> So I consider the whole discussion about the difficulty of back-patching
> moot.

I've mixed toughts about the plan.
On one hand being completely isolated might help making liblwgeom
better by actually exploiting its use.
On the other being in trunk feels like home.

A separate branch has a costs for the learning curve of merging with
SVN, but as long as the code is separated there shouldn't be any conflict
so only takes some help from whoever has done svn merging before.

--strk;


From robe.dnd at cityofboston.gov  Fri Jan 16 11:19:43 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 16 Jan 2009 14:19:43 -0500
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <4970C48E.7010409@siriusit.co.uk>
References: <20090114093637.GD87941@keybit.net>	<496F12C4.5020100@siriusit.co.uk><20090115233713.GG30648@keybit.net>	<4970978A.40806@siriusit.co.uk><30fe546d0901160808u2d883efbu9dbd86f022d9ce4a@mail.gmail.com>	<4970C0DF.1030407@refractions.net><53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
	<4970C48E.7010409@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B880C@ZDND.DND.boston.cob>

 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Friday, January 16, 2009 12:32 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] WKTRaster: RASTER and CHIP

Obe, Regina wrote:

> > Playing devlis advocate to Kevin's devils advocate.
> > 
> > I personally think its fine and am with Paul on this.
> > 
> > 1) WKT Raster has to live somewhere and it should live in the same
> > repository with PostGIS because that is the most likely place people
> > will expect to find it.

> This isn't necessarily the case; think pgrouting for an example of
this 
> type of project.

I don't know I would if I would think it bad if pgrouting were included
in our repository.  Seems a lot of people ask questions about it on this
list anyway.  So I always thought the issue was philosophical more than
logistics.

>> 2) It is going to have to be back-patched at some point whether it
lives
>> in its own branch in PostGIS repository or someplace else in the
world.
>> So I consider the whole discussion about the difficulty of
back-patching
>> moot.

> I think Paul summarised in his email what I was saying but in much
fewer 
> words; working in a branch is kinda okay as long as the WKTRaster 
> developers don't mind constant merging from trunk/fixing things based
on 
> changes to the PostGIS core. Although my feeling is for the initial
cut, 
> it may be less work to host the project independently and do a first 
> merge when it reaches a relatively stable point.

Yes I agree with branch I wasn't talking about integrating it in just
yet with 
our core branches.  I agree it should be a separate branch.
I'm just saying regardless of where it is hosted, you still have a
back-patch 
issue so I don't see how it holds things up having it as part of our
repository and for me personally
would make it a little easier to compare.

-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mbdavis at refractions.net  Mon Jan 19 10:31:10 2009
From: mbdavis at refractions.net (Martin Davis)
Date: Mon, 19 Jan 2009 10:31:10 -0800
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <496CA806.4070009@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com><53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>	<496CA10F.4020601@siriusit.co.uk>	<53F9CF533E1AA14EA1F8C5C08ABC08D20546FF41@ZDND.DND.boston.cob>
	<496CA806.4070009@siriusit.co.uk>
Message-ID: <4974C6EE.5030108@refractions.net>

AFAIK the SFS spec is silent on how "closed" should be defined in the 
Z-dimension.

FWIW JTS (and I assume GEOS) explicitly does not check the Z-ordinate 
when checking whether a ring is closed or not.  But JTS doesn't really 
try to provide full 2.5 D semantics - since you're trying to address 
this in PostGIS, you might want to take a more rigorous approach.

M

Mark Cave-Ayland wrote:
> Obe, Regina wrote:
>
>> Yap works now for both geojson and kml so its still just that nagging
>> regress_bdpoly which I guess we haven't resolved yet. 
>
> It actually comes down to your current discussion on the GEOS list 
> about the Z coordinate: 
> http://lists.osgeo.org/pipermail/geos-devel/2009-January/003839.html.
>
> For some reason, ST_BuildArea() returns the wrong Z coordinate for the 
> regression tests which causes the returned polygon to have an unclosed 
> ring if you consider 3 dimensions. You can clearly see this from the 
> following output on 1.3:
>
>
> postgis13=# select st_asewkt(st_geomfromtext('SRID=2;LINESTRING(0 0 2, 
> 10 0 4, 10 10 6, 0 10 8, 0 0 10)'));
> WARNING:  OGC WKT expected, EWKT provided - use GeomFromEWKT() for this
> CONTEXT:  SQL function "st_geomfromtext" statement 1
>                        st_asewkt
> -------------------------------------------------------
>  SRID=2;LINESTRING(0 0 2,10 0 4,10 10 6,0 10 8,0 0 10)
> (1 row)
>
> postgis13=# select 
> st_asewkt(st_buildarea(st_geomfromtext('SRID=2;LINESTRING(0 0 2, 10 0 
> 4, 10 10 6, 0 10 8, 0 0 10)')));
> WARNING:  OGC WKT expected, EWKT provided - use GeomFromEWKT() for this
> CONTEXT:  SQL function "st_geomfromtext" statement 1
>                       st_asewkt
> ------------------------------------------------------
>  SRID=2;POLYGON((0 0 10,0 10 8,10 10 6,10 0 4,0 0 2))
> (1 row)
>
>
> Since 1.4 nicely unifies the parser/unparser code, the back-conversion 
> from GEOS to EWKT now trips the closed ring check which is why we now 
> see the error.
>
> I think the issue on hand is how closure is defined in the spec for 
> geometries with > 2 dimensions, and hence whether the bug lies within 
> GEOS or not. Martin, any comments?
>
>
> ATB,
>
> Mark.
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



From pramsey at opengeo.org  Mon Jan 19 12:55:39 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 19 Jan 2009 12:55:39 -0800
Subject: [postgis-devel] GUI Version 0
Message-ID: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>

Folks,

I've committed the first draft of the GUI. I did the autoconf work for  
Linux and OS/X to handle GTK, which is either (a) easy or (b)  
completely impossible. I opted for (a), which imposes a requirement of  
having 'pkg-config' on your system, which most Gnome-enabled systems  
have.  For GTK2/GLIB2 it seems pretty standard, but I look forward to  
hearing from you in MinGw world. Of course, even with that  
standardization, I needed to special case OS/X, since I am using the  
native GTK build, which does *not* include pkg-config.

The GUI is on its own build target 'gui', which is enabled if you  
specify --with-gui and the dependencies are all found.

Paul (making ugly code uglier)

--
Paul Ramsey
OpenGeo - http://opengeo.org
Breath in. Breath out. Ahhh. PostGIS.



From pramsey at cleverelephant.ca  Mon Jan 19 15:07:19 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 19 Jan 2009 15:07:19 -0800
Subject: [postgis-devel] 2009 Code Sprint Agenda
Message-ID: <30fe546d0901191507x593fb836j73e47478bbcf5c15@mail.gmail.com>

I've started with some higher level ideas for an agenda. Individual
teams might want to start breaking out their plans into work-by-day as
we get closer.

http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009_Agenda

P.

http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009


From pramsey at opengeo.org  Mon Jan 19 20:43:03 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Mon, 19 Jan 2009 20:43:03 -0800
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
Message-ID: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>

Unfortunately, when we function re-named things for 1.2, things got a  
little out-of-hand, and every single function ended up with an ST_*  
sibling. I'd like to back away from that a bit now, and flip private  
functions into _ST_* space.  Some examples are st_geom_accum,  
st_unite_garray, etc.  I'd like to do it without leaving the old  
variants around. This is "breaking", but since the functions are  
private, hopefully not actually breaking.

P.

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From robe.dnd at cityofboston.gov  Mon Jan 19 20:49:46 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Mon, 19 Jan 2009 23:49:46 -0500
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob>

hmm I use those functions in some code I have.  So that would be kind of breaking in a major way for me.

Besides there is no counterpart to those particular functions in an obvious sense like _ST_Intersects
so some of those functions I consider a bit fuzzy as to whether they should be considered private except they are not documented.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Mon 1/19/2009 11:43 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
 
Unfortunately, when we function re-named things for 1.2, things got a  
little out-of-hand, and every single function ended up with an ST_*  
sibling. I'd like to back away from that a bit now, and flip private  
functions into _ST_* space.  Some examples are st_geom_accum,  
st_unite_garray, etc.  I'd like to do it without leaving the old  
variants around. This is "breaking", but since the functions are  
private, hopefully not actually breaking.

P.

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".

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



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090119/78f2c683/attachment.html>

From pramsey at cleverelephant.ca  Mon Jan 19 21:03:12 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 19 Jan 2009 21:03:12 -0800
Subject: [postgis-devel] Toronto Code Sprint
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D205470843@ZDND.DND.boston.cob>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F4119@exch-be03.ulaval.ca>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F411A@exch-be03.ulaval.ca>
	<53F9CF533E1AA14EA1F8C5C08ABC08D205470843@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901192103x4584126cy4a600658223a0645@mail.gmail.com>

Pierre,

I'm not sure what you mean by "presentations", but with me, Regina and
Mark in the same room, it is a unparalleled chance to talk about
ideas.

P.

On Wed, Jan 14, 2009 at 3:55 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> I would hope so.
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Pierre Racine
> Sent: Tuesday, January 13, 2009 5:32 PM
> To: postgis-devel at postgis.refractions.net
> Subject: RE: [postgis-devel] Toronto Code Sprint
>
> Will there be time for new project presentations?
>
> I would love to present WKT Raster...
>
> http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage
>
> Pierre
>
>>-----Message d'origine-----
>>De : Pierre Racine
>>Envoyé : 13 janvier 2009 17:30
>>À : Pierre Racine
>>Objet : [postgis-devel] Toronto Code Sprint
>>
>>
>>The 2009 Toronto Code Sprint is now set for March 7-10 at the Bond
>>Place Hotel in Toronto, Canada.
>>
>>  http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
>>
>>We hope you will consider joining us for a worthy weekend of sprinting
>>and getting connected.
>>
>>We are now looking for sponsors to cover venue and lunches during the
>>sprint. If your organization wants to curry favor with a couple dozen
>>influential geospatial programmers, this is a great chance. We are
>>looking for just four sponsors at $500 each, please get in touch with
>>me if you are interested in sponsoring this event.
>>
>>Thanks!
>>
>>Paul
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From robe.dnd at cityofboston.gov  Mon Jan 19 21:08:01 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 00:08:01 -0500
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob>

Well actually I should elaborate.  If you are building your own aggregate functions or doing something like

SELECT ST_Unite_garray(ARRAY(SELECT the_geom FROM foo))
FROM foo2

Is often times much more efficient than using ST_Union.  Aside from you can't easily use ST_Union with something like the above.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
Sent: Mon 1/19/2009 11:49 PM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Public/Private API, ST_*/_ST_*
 
hmm I use those functions in some code I have.  So that would be kind of breaking in a major way for me.

Besides there is no counterpart to those particular functions in an obvious sense like _ST_Intersects
so some of those functions I consider a bit fuzzy as to whether they should be considered private except they are not documented.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Mon 1/19/2009 11:43 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
 
Unfortunately, when we function re-named things for 1.2, things got a  
little out-of-hand, and every single function ended up with an ST_*  
sibling. I'd like to back away from that a bit now, and flip private  
functions into _ST_* space.  Some examples are st_geom_accum,  
st_unite_garray, etc.  I'd like to do it without leaving the old  
variants around. This is "breaking", but since the functions are  
private, hopefully not actually breaking.

P.

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".

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



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090120/584df001/attachment.html>

From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 01:32:09 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 09:32:09 +0000
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>
Message-ID: <49759A19.6070406@siriusit.co.uk>

Paul Ramsey wrote:

> Unfortunately, when we function re-named things for 1.2, things got a 
> little out-of-hand, and every single function ended up with an ST_* 
> sibling. I'd like to back away from that a bit now, and flip private 
> functions into _ST_* space.  Some examples are st_geom_accum, 
> st_unite_garray, etc.  I'd like to do it without leaving the old 
> variants around. This is "breaking", but since the functions are 
> private, hopefully not actually breaking.
> 
> P.

Yeah, the renaming was a little bit hit and miss. The main issue here is 
that ST_geom_accum and ST_unite_garray are actually part of the 
aggregates API and should not be called directly, since if this changes 
then everything will break. I would suggest creating some new functions 
names and aliasing them onto the old ones for the time-being.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 01:38:25 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 09:38:25 +0000
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob>
Message-ID: <49759B91.2070700@siriusit.co.uk>

Obe, Regina wrote:

> hmm I use those functions in some code I have.  So that would be kind of 
> breaking in a major way for me.
> 
> Besides there is no counterpart to those particular functions in an 
> obvious sense like _ST_Intersects
> so some of those functions I consider a bit fuzzy as to whether they 
> should be considered private except they are not documented.

Well, I know we wish to maintain compatibility as far as possible to 
encourage people to move from 1.3 to 1.4 when it comes out but there are 
already a couple of breaking changes in the pipeline such as GBT#93/96. 
As long as the changes are minor and well-documented (and we provide 
alternative functions for you to use) then I don't have an issue with 
this. Anyone upgrading to a new minor release should accept that the 
version number indicates small changes and should read the notes 
accordingly.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 01:40:49 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 09:40:49 +0000
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob>
Message-ID: <49759C21.6040108@siriusit.co.uk>

Obe, Regina wrote:

> Well actually I should elaborate.  If you are building your own 
> aggregate functions or doing something like
> 
> SELECT ST_Unite_garray(ARRAY(SELECT the_geom FROM foo))
> FROM foo2
> 
> Is often times much more efficient than using ST_Union.  Aside from you 
> can't easily use ST_Union with something like the above.

I think it would make sense if Paul posts a complete list of changes for 
comment before committing anything to SVN. Then we can work out which 
functions will cause issues if they are renamed, and decide on a 
suitable course of action.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 01:47:00 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 09:47:00 +0000
Subject: [postgis-devel] GUI Version 0
In-Reply-To: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
References: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
Message-ID: <49759D94.3030601@siriusit.co.uk>

Paul Ramsey wrote:

> Folks,
> 
> I've committed the first draft of the GUI. I did the autoconf work for 
> Linux and OS/X to handle GTK, which is either (a) easy or (b) completely 
> impossible. I opted for (a), which imposes a requirement of having 
> 'pkg-config' on your system, which most Gnome-enabled systems have.  For 
> GTK2/GLIB2 it seems pretty standard, but I look forward to hearing from 
> you in MinGw world. Of course, even with that standardization, I needed 
> to special case OS/X, since I am using the native GTK build, which does 
> *not* include pkg-config.
> 
> The GUI is on its own build target 'gui', which is enabled if you 
> specify --with-gui and the dependencies are all found.
> 
> Paul (making ugly code uglier)

Yeah, a quick glance at the autoconf code shows it needs some work. The 
biggest problem is that hard-coding paths in autoconf scripts should be 
an absolute no-no for C code, since the shell and the compiler both have 
different ideas of where to find things.

According to the documentation, GTK comes with a macro called 
AM_PATH_GTK which can be used to find the headers and libraries used for 
GTK. I would suggest installing it into the macros/ directory and using 
it in configure.ac instead. Chances are that you will find it "just works".


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 01:47:57 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 09:47:57 +0000
Subject: [postgis-devel] GeoJSON failing on 1.4
In-Reply-To: <4974C6EE.5030108@refractions.net>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D20546FEC5@ZDND.DND.boston.cob>	<021EB06C-CC1C-45C3-9805-F04675AE2D07@camptocamp.com><53F9CF533E1AA14EA1F8C5C08ABC08D20546FED3@ZDND.DND.boston.cob>	<496CA10F.4020601@siriusit.co.uk>	<53F9CF533E1AA14EA1F8C5C08ABC08D20546FF41@ZDND.DND.boston.cob>	<496CA806.4070009@siriusit.co.uk>
	<4974C6EE.5030108@refractions.net>
Message-ID: <49759DCD.9090103@siriusit.co.uk>

Martin Davis wrote:

> AFAIK the SFS spec is silent on how "closed" should be defined in the 
> Z-dimension.
> 
> FWIW JTS (and I assume GEOS) explicitly does not check the Z-ordinate 
> when checking whether a ring is closed or not.  But JTS doesn't really 
> try to provide full 2.5 D semantics - since you're trying to address 
> this in PostGIS, you might want to take a more rigorous approach.
> 
> M

Thanks Martin.

So folks, is this a GEOS bug?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Tue Jan 20 03:56:23 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 06:56:23 -0500
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <49759C21.6040108@siriusit.co.uk>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob>
	<49759C21.6040108@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABA@ZDND.DND.boston.cob>

Yes agreed.  I'll accept if they need to be renamed but then again if
I'm going to depend on them, and you consider them just glue code now
that is a more serious problem.  Just thought I'd bring it up as a
potential issue and somewhat grey area in that they have great use apart
from their intended.

If we are adding stuff to the list that hmm should be hidden - here is a
few that come to mind if Paul hasn't thought about them already (I can't
think of why I would ever use these directly instead of their
operator/other forms)

st_create_histogram2d (do we even do these things by hand anymore?)
st_histogram2d_in
st_histogram2d_out
st_box2d_contain
st_box2d_contained
st_box2d_in
st_box2d_intersects
st_box2d_left
st_box2d_out
st_box2d_overlap
st_box2d_overleft
st_box2d_overright
st_box2d_right
st_box2d_same
st_box3d
st_box3d
st_box3d_in
st_box3d_out
st_chip_in
st_chip_out
st_spheroid_in
st_spheroid_out


I would prefer you leave my friends alone though :).

Thanks,
Regina
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 20, 2009 4:41 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Public/Private API, ST_*/_ST_*

Obe, Regina wrote:

> Well actually I should elaborate.  If you are building your own 
> aggregate functions or doing something like
> 
> SELECT ST_Unite_garray(ARRAY(SELECT the_geom FROM foo))
> FROM foo2
> 
> Is often times much more efficient than using ST_Union.  Aside from
you 
> can't easily use ST_Union with something like the above.

I think it would make sense if Paul posts a complete list of changes for

comment before committing anything to SVN. Then we can work out which 
functions will cause issues if they are renamed, and decide on a 
suitable course of action.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From robe.dnd at cityofboston.gov  Tue Jan 20 04:07:08 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 07:07:08 -0500
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABA@ZDND.DND.boston.cob>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob><49759C21.6040108@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABA@ZDND.DND.boston.cob>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABB@ZDND.DND.boston.cob>

On the topic of stuff that shouldn't be exposed.  I always thought the
geom operators cast to box checks.  So what are these things used for?
They seem to call different lwgeom functions than the box ones do.

st_geometry_above
st_geometry_analyze
st_geometry_below
st_geometry_cmp
st_geometry_contain
st_geometry_contained
st_geometry_eq
st_geometry_ge
st_geometry_gt
st_geometry_in
st_geometry_le
st_geometry_left
st_geometry_lt
st_geometry_out
st_geometry_overabove
st_geometry_overbelow
st_geometry_overlap
st_geometry_overleft
st_geometry_overright
st_geometry_recv
st_geometry_right
st_geometry_same
st_geometry_send 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Obe,
Regina
Sent: Tuesday, January 20, 2009 6:56 AM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Public/Private API, ST_*/_ST_*

Yes agreed.  I'll accept if they need to be renamed but then again if
I'm going to depend on them, and you consider them just glue code now
that is a more serious problem.  Just thought I'd bring it up as a
potential issue and somewhat grey area in that they have great use apart
from their intended.

If we are adding stuff to the list that hmm should be hidden - here is a
few that come to mind if Paul hasn't thought about them already (I can't
think of why I would ever use these directly instead of their
operator/other forms)

st_create_histogram2d (do we even do these things by hand anymore?)
st_histogram2d_in
st_histogram2d_out
st_box2d_contain
st_box2d_contained
st_box2d_in
st_box2d_intersects
st_box2d_left
st_box2d_out
st_box2d_overlap
st_box2d_overleft
st_box2d_overright
st_box2d_right
st_box2d_same
st_box3d
st_box3d
st_box3d_in
st_box3d_out
st_chip_in
st_chip_out
st_spheroid_in
st_spheroid_out


I would prefer you leave my friends alone though :).

Thanks,
Regina
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 20, 2009 4:41 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Public/Private API, ST_*/_ST_*

Obe, Regina wrote:

> Well actually I should elaborate.  If you are building your own 
> aggregate functions or doing something like
> 
> SELECT ST_Unite_garray(ARRAY(SELECT the_geom FROM foo))
> FROM foo2
> 
> Is often times much more efficient than using ST_Union.  Aside from
you 
> can't easily use ST_Union with something like the above.

I think it would make sense if Paul posts a complete list of changes for

comment before committing anything to SVN. Then we can work out which 
functions will cause issues if they are renamed, and decide on a 
suitable course of action.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 04:18:53 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 12:18:53 +0000
Subject: [postgis-devel] Public/Private API, ST_*/_ST_*
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABB@ZDND.DND.boston.cob>
References: <0C4F9E3D-2189-4645-B40E-A9A5F828EA7E@opengeo.org>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10A@ZDND.DND.boston.cob><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F10B@ZDND.DND.boston.cob><49759C21.6040108@siriusit.co.uk>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABA@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8ABB@ZDND.DND.boston.cob>
Message-ID: <4975C12D.4040708@siriusit.co.uk>

Obe, Regina wrote:

> On the topic of stuff that shouldn't be exposed.  I always thought the
> geom operators cast to box checks.  So what are these things used for?
> They seem to call different lwgeom functions than the box ones do.
> 
> st_geometry_above
> st_geometry_analyze
> st_geometry_below
> st_geometry_cmp
> st_geometry_contain
> st_geometry_contained
> st_geometry_eq
> st_geometry_ge
> st_geometry_gt
> st_geometry_in
> st_geometry_le
> st_geometry_left
> st_geometry_lt
> st_geometry_out
> st_geometry_overabove
> st_geometry_overbelow
> st_geometry_overlap
> st_geometry_overleft
> st_geometry_overright
> st_geometry_recv
> st_geometry_right
> st_geometry_same
> st_geometry_send 

Yuck. On first glance I think that all of these are internal functions 
related to the geometry types/index opclass and should never be exposed 
to the user. I'd suggest changing them to match the underlying C 
function names to make finding one from the other much easier.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From Pierre.Racine at sbf.ulaval.ca  Tue Jan 20 05:15:09 2009
From: Pierre.Racine at sbf.ulaval.ca (Pierre Racine)
Date: Tue, 20 Jan 2009 08:15:09 -0500
Subject: [postgis-devel] Toronto Code Sprint
In-Reply-To: <30fe546d0901192103x4584126cy4a600658223a0645@mail.gmail.com>
Message-ID: <D58FF82475EA0A4A9347D3CE16B46E5F6F4588@exch-be03.ulaval.ca>

I mean a PowerPoint presentation. I'll be there anyway.

Pierre

>-----Message d'origine-----
>De : postgis-devel-bounces at postgis.refractions.net 
>[mailto:postgis-devel-bounces at postgis.refractions.net] De la 
>part de Paul Ramsey
>Envoyé : 20 janvier 2009 00:03
>À : PostGIS Development Discussion
>Objet : Re: [postgis-devel] Toronto Code Sprint
>
>Pierre,
>
>I'm not sure what you mean by "presentations", but with me, Regina and
>Mark in the same room, it is a unparalleled chance to talk about
>ideas.
>
>P.
>
>On Wed, Jan 14, 2009 at 3:55 AM, Obe, Regina 
><robe.dnd at cityofboston.gov> wrote:
>> I would hope so.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net 
>[mailto:postgis-devel-bounces at postgis.refractions.net] On 
>Behalf Of Pierre Racine
>> Sent: Tuesday, January 13, 2009 5:32 PM
>> To: postgis-devel at postgis.refractions.net
>> Subject: RE: [postgis-devel] Toronto Code Sprint
>>
>> Will there be time for new project presentations?
>>
>> I would love to present WKT Raster...
>>
>> 
>http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage
>>
>> Pierre
>>
>>>-----Message d'origine-----
>>>De : Pierre Racine
>>>Envoyé : 13 janvier 2009 17:30
>>>À : Pierre Racine
>>>Objet : [postgis-devel] Toronto Code Sprint
>>>
>>>
>>>The 2009 Toronto Code Sprint is now set for March 7-10 at the Bond
>>>Place Hotel in Toronto, Canada.
>>>
>>>  http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
>>>
>>>We hope you will consider joining us for a worthy weekend of 
>sprinting
>>>and getting connected.
>>>
>>>We are now looking for sponsors to cover venue and lunches during the
>>>sprint. If your organization wants to curry favor with a couple dozen
>>>influential geospatial programmers, this is a great chance. We are
>>>looking for just four sponsors at $500 each, please get in touch with
>>>me if you are interested in sponsoring this event.
>>>
>>>Thanks!
>>>
>>>Paul
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From robe.dnd at cityofboston.gov  Tue Jan 20 05:33:41 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 08:33:41 -0500
Subject: [postgis-devel] Slightly embarassing question on Ports
In-Reply-To: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
References: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8AF3@ZDND.DND.boston.cob>

I think Mark told me how to do this before.  I was trying to test out
the EnterpriseDb 8.4 snapshots

http://www.enterprisedb.com/products/pgdevdownload.do


Against 1.4 and I have this not running on the standard 5432.

I know Mark told this to me before but can't find the email.  How do I
force make check to use my 8.4 ports port?

Thanks,
Regina


-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From pramsey at cleverelephant.ca  Tue Jan 20 07:43:53 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 20 Jan 2009 07:43:53 -0800
Subject: [postgis-devel] Slightly embarassing question on Ports
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B8AF3@ZDND.DND.boston.cob>
References: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8AF3@ZDND.DND.boston.cob>
Message-ID: <10C4CFE4-3C7A-40DB-BC5D-24B913508234@cleverelephant.ca>

Perhaps with an environment variable ?  PGPORT?

P

Sent from my iPod

On 20-Jan-09, at 5:33 AM, "Obe, Regina" <robe.dnd at cityofboston.gov>  
wrote:

> I think Mark told me how to do this before.  I was trying to test out
> the EnterpriseDb 8.4 snapshots
>
> http://www.enterprisedb.com/products/pgdevdownload.do
>
>
> Against 1.4 and I have this not running on the standard 5432.
>
> I know Mark told this to me before but can't find the email.  How do I
> force make check to use my 8.4 ports port?
>
> Thanks,
> Regina
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From pramsey at cleverelephant.ca  Tue Jan 20 08:52:12 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 20 Jan 2009 08:52:12 -0800
Subject: [postgis-devel] GUI Version 0
In-Reply-To: <49759D94.3030601@siriusit.co.uk>
References: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>
	<49759D94.3030601@siriusit.co.uk>
Message-ID: <30fe546d0901200852n4dc5ff15xaeecd7fcdb66b577@mail.gmail.com>

For all my hunting the internet and searching Google Code for an
appropriate m4 to do GTK checking, it never once entered my pea-brain
to actually look in the GTK source itself! I've taken a macro from
there, it looks like it just does a more thorough job using
pkg-config.

However, the hard-coded paths for OS/X are going to have to remain
until there is some more subtle macro script available to find them.
For unknown reasons, those frameworks don't include a pkg-config, so
the same tricks don't work with them.

P.

On Tue, Jan 20, 2009 at 1:47 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>
>> Folks,
>>
>> I've committed the first draft of the GUI. I did the autoconf work for
>> Linux and OS/X to handle GTK, which is either (a) easy or (b) completely
>> impossible. I opted for (a), which imposes a requirement of having
>> 'pkg-config' on your system, which most Gnome-enabled systems have.  For
>> GTK2/GLIB2 it seems pretty standard, but I look forward to hearing from you
>> in MinGw world. Of course, even with that standardization, I needed to
>> special case OS/X, since I am using the native GTK build, which does *not*
>> include pkg-config.
>>
>> The GUI is on its own build target 'gui', which is enabled if you specify
>> --with-gui and the dependencies are all found.
>>
>> Paul (making ugly code uglier)
>
> Yeah, a quick glance at the autoconf code shows it needs some work. The
> biggest problem is that hard-coding paths in autoconf scripts should be an
> absolute no-no for C code, since the shell and the compiler both have
> different ideas of where to find things.
>
> According to the documentation, GTK comes with a macro called AM_PATH_GTK
> which can be used to find the headers and libraries used for GTK. I would
> suggest installing it into the macros/ directory and using it in
> configure.ac instead. Chances are that you will find it "just works".
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 09:30:00 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 17:30:00 +0000
Subject: [postgis-devel] GUI Version 0
In-Reply-To: <30fe546d0901200852n4dc5ff15xaeecd7fcdb66b577@mail.gmail.com>
References: <53FE4B5F-0E2B-4626-883D-5DC378D7F4C5@opengeo.org>	<49759D94.3030601@siriusit.co.uk>
	<30fe546d0901200852n4dc5ff15xaeecd7fcdb66b577@mail.gmail.com>
Message-ID: <49760A18.6030106@siriusit.co.uk>

Paul Ramsey wrote:

> For all my hunting the internet and searching Google Code for an
> appropriate m4 to do GTK checking, it never once entered my pea-brain
> to actually look in the GTK source itself! I've taken a macro from
> there, it looks like it just does a more thorough job using
> pkg-config.

Cool. Don't forget to add /usr/share/aclocal/gtk-2.0.m4 to the macros/ 
directory. The only reason it's automatically present is because the 
libgtk-dev packages have been installed on the computer running 
autogen.sh, and it's being automatically pulled from the automake 
repository.

> However, the hard-coded paths for OS/X are going to have to remain
> until there is some more subtle macro script available to find them.
> For unknown reasons, those frameworks don't include a pkg-config, so
> the same tricks don't work with them.

Hmmm. Might be worth asking on IRC/GTK mailing list to see if there is a 
similar macro for Apple. I can't believe that no-one hasn't come across 
this before....


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Tue Jan 20 13:11:29 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 20 Jan 2009 13:11:29 -0800
Subject: [postgis-devel] CascadedUnion Early Results
Message-ID: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>

Looks good so far. Still chasing down an issue with GEOS before I can  
commit, but here's the current results:


uniontest=# select st_area(st_union(the_geom)) from counties where  
state_name = 'Texas';
      st_area
------------------
  65.0596422159988
(1 row)

Time: 702.491 ms

uniontest=# select st_area(st_union_fast(the_geom)) from counties  
where state_name = 'Texas';
      st_area
------------------
  65.0596422159988
(1 row)

Time: 216.526 ms

In the final commit there will just be one st_union() that does the  
right thing. I made two so I could do comparisons like the above more  
easily. Perhaps I should leave in a legacy st_union_slow() for people  
to compare with...

--
Paul Ramsey
OpenGeo - http://opengeo.org
Putting the "Po" in "PostGIS".



From pramsey at cleverelephant.ca  Tue Jan 20 13:15:47 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 20 Jan 2009 13:15:47 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
Message-ID: <A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>

For completeness, the whole table, about 4x faster:

uniontest=# select count(*) from counties;
  count
-------
   3140
(1 row)

uniontest=# select st_area(st_union(the_geom)) from counties;      
st_area
------------------
  1095.88034519544
(1 row)

Time: 42352.399 ms

uniontest=# select st_area(st_union_fast(the_geom)) from counties;
      st_area
------------------
  1095.88034519544
(1 row)

Time: 11493.832 ms

On Jan 20, 2009, at 1:11 PM, Paul Ramsey wrote:

> Looks good so far. Still chasing down an issue with GEOS before I  
> can commit, but here's the current results:
>
>
> uniontest=# select st_area(st_union(the_geom)) from counties where  
> state_name = 'Texas';
>     st_area
> ------------------
> 65.0596422159988
> (1 row)
>
> Time: 702.491 ms
>
> uniontest=# select st_area(st_union_fast(the_geom)) from counties  
> where state_name = 'Texas';
>     st_area
> ------------------
> 65.0596422159988
> (1 row)
>
> Time: 216.526 ms
>
> In the final commit there will just be one st_union() that does the  
> right thing. I made two so I could do comparisons like the above  
> more easily. Perhaps I should leave in a legacy st_union_slow() for  
> people to compare with...
>
> --
> Paul Ramsey
> OpenGeo - http://opengeo.org
> Putting the "Po" in "PostGIS".
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From kneufeld at refractions.net  Tue Jan 20 13:22:23 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Tue, 20 Jan 2009 13:22:23 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
	<A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
Message-ID: <4976408F.9020203@refractions.net>

That's impressive.  Good work Paul!
-- Kevin

Paul Ramsey wrote:
> For completeness, the whole table, about 4x faster:
> 
> uniontest=# select count(*) from counties;
>  count
> -------
>   3140
> (1 row)
> 
> uniontest=# select st_area(st_union(the_geom)) from counties;     st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 42352.399 ms
> 
> uniontest=# select st_area(st_union_fast(the_geom)) from counties;
>      st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 11493.832 ms
> 
> On Jan 20, 2009, at 1:11 PM, Paul Ramsey wrote:
> 
>> Looks good so far. Still chasing down an issue with GEOS before I can 
>> commit, but here's the current results:
>>
>>
>> uniontest=# select st_area(st_union(the_geom)) from counties where 
>> state_name = 'Texas';
>>     st_area
>> ------------------
>> 65.0596422159988
>> (1 row)
>>
>> Time: 702.491 ms
>>
>> uniontest=# select st_area(st_union_fast(the_geom)) from counties 
>> where state_name = 'Texas';
>>     st_area
>> ------------------
>> 65.0596422159988
>> (1 row)
>>
>> Time: 216.526 ms
>>
>> In the final commit there will just be one st_union() that does the 
>> right thing. I made two so I could do comparisons like the above more 
>> easily. Perhaps I should leave in a legacy st_union_slow() for people 
>> to compare with...
>>
>> -- 
>> Paul Ramsey
>> OpenGeo - http://opengeo.org
>> Putting the "Po" in "PostGIS".
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
> 
> -- 
> Paul Ramsey
> pramsey at cleverelephant.ca
> +1 250 885 0632
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mark.cave-ayland at siriusit.co.uk  Tue Jan 20 13:34:18 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Tue, 20 Jan 2009 21:34:18 +0000
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
	<A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
Message-ID: <4976435A.9080902@siriusit.co.uk>

Paul Ramsey wrote:

> For completeness, the whole table, about 4x faster:
> 
> uniontest=# select count(*) from counties;
>  count
> -------
>   3140
> (1 row)
> 
> uniontest=# select st_area(st_union(the_geom)) from counties;     st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 42352.399 ms
> 
> uniontest=# select st_area(st_union_fast(the_geom)) from counties;
>      st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 11493.832 ms

Fascinating. What would be really interesting would be to compare the 
times with the same dataset in JTS so we can get a feel as to whether 
there is any more overhead in the array_accum/GEOS conversion code.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Tue Jan 20 13:42:35 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 16:42:35 -0500
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <4976435A.9080902@siriusit.co.uk>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org><A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
	<4976435A.9080902@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>

Paul, 

I think we can do better. 

As I recall with my cascade union tests I was getting comparable speed
and JTS was about 2-10 times faster.


Can you test the attached data set out.  Then it will be a closer
comparison.  I think for this set JTS was about 20 seconds.

Below is the link to my results on this way back.

http://postgis.refractions.net/support/wiki/index.php?PL%2FPGSQL%20Pseud
o%20Cascade%20Union%20Aggregate%20Function


(though I don't have the JTS one listed there)

Damn I hope this is the right dataset.  I'll retest on my other box but
I have so many of these lying around.

Would also be interesting to repeat Kevin's original test that started
this all out.  I can send you that dataset off list.

Thanks,
Regina




-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 20, 2009 4:34 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] CascadedUnion Early Results

Paul Ramsey wrote:

> For completeness, the whole table, about 4x faster:
> 
> uniontest=# select count(*) from counties;
>  count
> -------
>   3140
> (1 row)
> 
> uniontest=# select st_area(st_union(the_geom)) from counties;
st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 42352.399 ms
> 
> uniontest=# select st_area(st_union_fast(the_geom)) from counties;
>      st_area
> ------------------
>  1095.88034519544
> (1 row)
> 
> Time: 11493.832 ms

Fascinating. What would be really interesting would be to compare the 
times with the same dataset in JTS so we can get a feel as to whether 
there is any more overhead in the array_accum/GEOS conversion code.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usstatebounds.zip
Type: application/x-zip-compressed
Size: 2415227 bytes
Desc: usstatebounds.zip
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090120/0bb8bf90/attachment.bin>

From codesite-noreply at google.com  Tue Jan 20 14:00:32 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 20 Jan 2009 22:00:32 +0000
Subject: [postgis-devel] Issue 100 in postgis: postgis_restore.pl createdb
	option wrong usage
Message-ID: <001485f9143a0d58f80460f12b58@google.com>

Status: New
Owner: ----

New issue 100 by htmledit: postgis_restore.pl createdb option wrong usage
http://code.google.com/p/postgis/issues/detail?id=100

In the Postgis 1.3.5 release, the 'postgis_restore.pl' contrib file allow
the user to specify createdb options.

In a recent issue (#45 :
http://code.google.com/p/postgis/issues/detail?id=45&can=1&q=postgis_restore.pl),
the createdb option was extended to createlang ans psql commands.

Though, createdb/createlang/psql do not accept the same options !

For example if you specify --encoding=LATIN9 for createdb, an error occurs
while executing "createlang --encoding=LATIN9" and "psql  
--encoding=LATIN9"...


Maybe we should add more options arguments specific to createlang and psql.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From pramsey at opengeo.org  Tue Jan 20 14:08:24 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 20 Jan 2009 14:08:24 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
	<A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
	<4976435A.9080902@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901201408h4f017085ycfd1db22eb794954@mail.gmail.com>

Here's your test, slightly modified. Shows about 30-times improvement
over traditional union.

  SELECT state,
   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
     ST_NPoints(ST_Union(the_geom)) As numpointsafter
   FROM usstatebounds
   GROUP BY state
   ORDER BY state;

Time: 579121.791 ms

  SELECT state,
   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
     ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
   FROM usstatebounds
   GROUP BY state
   ORDER BY state;

Time: 21145.717 ms


On Tue, Jan 20, 2009 at 1:42 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
>
> I think we can do better.
>
> As I recall with my cascade union tests I was getting comparable speed
> and JTS was about 2-10 times faster.
>
>
> Can you test the attached data set out.  Then it will be a closer
> comparison.  I think for this set JTS was about 20 seconds.
>
> Below is the link to my results on this way back.
>
> http://postgis.refractions.net/support/wiki/index.php?PL%2FPGSQL%20Pseud
> o%20Cascade%20Union%20Aggregate%20Function
>
>
> (though I don't have the JTS one listed there)
>
> Damn I hope this is the right dataset.  I'll retest on my other box but
> I have so many of these lying around.
>
> Would also be interesting to repeat Kevin's original test that started
> this all out.  I can send you that dataset off list.
>
> Thanks,
> Regina
>
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
> Cave-Ayland
> Sent: Tuesday, January 20, 2009 4:34 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] CascadedUnion Early Results
>
> Paul Ramsey wrote:
>
>> For completeness, the whole table, about 4x faster:
>>
>> uniontest=# select count(*) from counties;
>>  count
>> -------
>>   3140
>> (1 row)
>>
>> uniontest=# select st_area(st_union(the_geom)) from counties;
> st_area
>> ------------------
>>  1095.88034519544
>> (1 row)
>>
>> Time: 42352.399 ms
>>
>> uniontest=# select st_area(st_union_fast(the_geom)) from counties;
>>      st_area
>> ------------------
>>  1095.88034519544
>> (1 row)
>>
>> Time: 11493.832 ms
>
> Fascinating. What would be really interesting would be to compare the
> times with the same dataset in JTS so we can get a feel as to whether
> there is any more overhead in the array_accum/GEOS conversion code.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From robe.dnd at cityofboston.gov  Tue Jan 20 14:13:31 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Tue, 20 Jan 2009 17:13:31 -0500
Subject: [postgis-devel] CascadedUnion Early Results
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org><A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca><4976435A.9080902@siriusit.co.uk><53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>
	<30fe546d0901201408h4f017085ycfd1db22eb794954@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F114@ZDND.DND.boston.cob>


Ah okay that looks good.  I think the numbers look like about what I got on JTS.

I have to dig up that set Kevin had given me way back when.  Kevin you don't still happen to have that do you?  I think it was named sample_poly.zip



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Tue 1/20/2009 5:08 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] CascadedUnion Early Results
 
Here's your test, slightly modified. Shows about 30-times improvement
over traditional union.

  SELECT state,
   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
     ST_NPoints(ST_Union(the_geom)) As numpointsafter
   FROM usstatebounds
   GROUP BY state
   ORDER BY state;

Time: 579121.791 ms

  SELECT state,
   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
     ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
   FROM usstatebounds
   GROUP BY state
   ORDER BY state;

Time: 21145.717 ms


On Tue, Jan 20, 2009 at 1:42 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
>
> I think we can do better.
>
> As I recall with my cascade union tests I was getting comparable speed
> and JTS was about 2-10 times faster.
>
>
> Can you test the attached data set out.  Then it will be a closer
> comparison.  I think for this set JTS was about 20 seconds.
>
> Below is the link to my results on this way back.
>
> http://postgis.refractions.net/support/wiki/index.php?PL%2FPGSQL%20Pseud
> o%20Cascade%20Union%20Aggregate%20Function
>
>
> (though I don't have the JTS one listed there)
>
> Damn I hope this is the right dataset.  I'll retest on my other box but
> I have so many of these lying around.
>
> Would also be interesting to repeat Kevin's original test that started
> this all out.  I can send you that dataset off list.
>
> Thanks,
> Regina
>
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
> Cave-Ayland
> Sent: Tuesday, January 20, 2009 4:34 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] CascadedUnion Early Results
>
> Paul Ramsey wrote:
>
>> For completeness, the whole table, about 4x faster:
>>
>> uniontest=# select count(*) from counties;
>>  count
>> -------
>>   3140
>> (1 row)
>>
>> uniontest=# select st_area(st_union(the_geom)) from counties;
> st_area
>> ------------------
>>  1095.88034519544
>> (1 row)
>>
>> Time: 42352.399 ms
>>
>> uniontest=# select st_area(st_union_fast(the_geom)) from counties;
>>      st_area
>> ------------------
>>  1095.88034519544
>> (1 row)
>>
>> Time: 11493.832 ms
>
> Fascinating. What would be really interesting would be to compare the
> times with the same dataset in JTS so we can get a feel as to whether
> there is any more overhead in the array_accum/GEOS conversion code.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090120/824507c7/attachment.html>

From kneufeld at refractions.net  Tue Jan 20 14:29:25 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Tue, 20 Jan 2009 14:29:25 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F114@ZDND.DND.boston.cob>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org><A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca><4976435A.9080902@siriusit.co.uk><53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>	<30fe546d0901201408h4f017085ycfd1db22eb794954@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F114@ZDND.DND.boston.cob>
Message-ID: <49765045.8020306@refractions.net>

Yup, already forwarded it to you.

Yes, it looks much better.  It obviously depends greatly on the dataset being used ... just how much the dataset overlaps.

Paul, out of curiosity, how does this method compare when trying to use a set of completely disjoint polygons?  Since 
there is nothing to gain by using a cascaded methodology in such a case, is there an overhead to using the function?

Cheers,
Kevin

Obe, Regina wrote:
> 
> Ah okay that looks good.  I think the numbers look like about what I got 
> on JTS.
> 
> I have to dig up that set Kevin had given me way back when.  Kevin you 
> don't still happen to have that do you?  I think it was named 
> sample_poly.zip
> 
> 
> 
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Tue 1/20/2009 5:08 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] CascadedUnion Early Results
> 
> Here's your test, slightly modified. Shows about 30-times improvement
> over traditional union.
> 
>   SELECT state,
>    SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>      ST_NPoints(ST_Union(the_geom)) As numpointsafter
>    FROM usstatebounds
>    GROUP BY state
>    ORDER BY state;
> 
> Time: 579121.791 ms
> 
>   SELECT state,
>    SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>      ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
>    FROM usstatebounds
>    GROUP BY state
>    ORDER BY state;
> 
> Time: 21145.717 ms
> 
> 


From mbdavis at refractions.net  Tue Jan 20 14:37:24 2009
From: mbdavis at refractions.net (Martin Davis)
Date: Tue, 20 Jan 2009 14:37:24 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <49765045.8020306@refractions.net>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org><A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca><4976435A.9080902@siriusit.co.uk><53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>	<30fe546d0901201408h4f017085ycfd1db22eb794954@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F114@ZDND.DND.boston.cob>
	<49765045.8020306@refractions.net>
Message-ID: <49765224.3040805@refractions.net>

There should still be an improvement even if the dataset consists of 
disjoint polygons.  The reason is that the total number of union 
operations carried out is fewer, since CascadedUnion ends up clustering 
geometries together and unioning them in batches, rather than adding a 
single geometry at a time to an ever-larger result.

But the performance boost won't be nearly as great as when the 
geometries overlap, when the intermediate unions ends up reducing the 
total number of points which are being handled.

I've experimented with having some up-front checks to detect polygons 
which don't overlap (or more generally disjoint clusters of overlapping 
polygons), but the testing didn't show any great improvement over simply 
running the CascadedUnion directly.  I was a bit disappointed by this, 
since it seems like it should be faster to test disjoint than actually 
carry out a union.  Some more testing might be in order - feel free to 
try and prove me wrong!

Kevin Neufeld wrote:
> Yup, already forwarded it to you.
>
> Yes, it looks much better.  It obviously depends greatly on the 
> dataset being used ... just how much the dataset overlaps.
>
> Paul, out of curiosity, how does this method compare when trying to 
> use a set of completely disjoint polygons?  Since there is nothing to 
> gain by using a cascaded methodology in such a case, is there an 
> overhead to using the function?
>
> Cheers,
> Kevin
>
> Obe, Regina wrote:
>>
>> Ah okay that looks good.  I think the numbers look like about what I 
>> got on JTS.
>>
>> I have to dig up that set Kevin had given me way back when.  Kevin 
>> you don't still happen to have that do you?  I think it was named 
>> sample_poly.zip
>>
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul 
>> Ramsey
>> Sent: Tue 1/20/2009 5:08 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] CascadedUnion Early Results
>>
>> Here's your test, slightly modified. Shows about 30-times improvement
>> over traditional union.
>>
>>   SELECT state,
>>    SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>>      ST_NPoints(ST_Union(the_geom)) As numpointsafter
>>    FROM usstatebounds
>>    GROUP BY state
>>    ORDER BY state;
>>
>> Time: 579121.791 ms
>>
>>   SELECT state,
>>    SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>>      ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
>>    FROM usstatebounds
>>    GROUP BY state
>>    ORDER BY state;
>>
>> Time: 21145.717 ms
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



From pramsey at cleverelephant.ca  Tue Jan 20 15:10:43 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 20 Jan 2009 15:10:43 -0800
Subject: [postgis-devel] CascadedUnion Early Results
In-Reply-To: <49765045.8020306@refractions.net>
References: <B25C34B6-E4A8-439C-962D-95D56DA38EA3@opengeo.org>
	<A10E3F9A-0496-4152-AFD2-7160EAB6179E@cleverelephant.ca>
	<4976435A.9080902@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B907F@ZDND.DND.boston.cob>
	<30fe546d0901201408h4f017085ycfd1db22eb794954@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F114@ZDND.DND.boston.cob>
	<49765045.8020306@refractions.net>
Message-ID: <30fe546d0901201510n5fcf6bcfp6f0d6c3327113fa9@mail.gmail.com>

This test case is taking a *very* long time for the standard function.
No answer yet :)

P

On Tue, Jan 20, 2009 at 2:29 PM, Kevin Neufeld <kneufeld at refractions.net> wrote:
> Yup, already forwarded it to you.
>
> Yes, it looks much better.  It obviously depends greatly on the dataset
> being used ... just how much the dataset overlaps.
>
> Paul, out of curiosity, how does this method compare when trying to use a
> set of completely disjoint polygons?  Since there is nothing to gain by
> using a cascaded methodology in such a case, is there an overhead to using
> the function?
>
> Cheers,
> Kevin
>
> Obe, Regina wrote:
>>
>> Ah okay that looks good.  I think the numbers look like about what I got
>> on JTS.
>>
>> I have to dig up that set Kevin had given me way back when.  Kevin you
>> don't still happen to have that do you?  I think it was named
>> sample_poly.zip
>>
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
>> Ramsey
>> Sent: Tue 1/20/2009 5:08 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] CascadedUnion Early Results
>>
>> Here's your test, slightly modified. Shows about 30-times improvement
>> over traditional union.
>>
>>  SELECT state,
>>   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>>     ST_NPoints(ST_Union(the_geom)) As numpointsafter
>>   FROM usstatebounds
>>   GROUP BY state
>>   ORDER BY state;
>>
>> Time: 579121.791 ms
>>
>>  SELECT state,
>>   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>>     ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
>>   FROM usstatebounds
>>   GROUP BY state
>>   ORDER BY state;
>>
>> Time: 21145.717 ms
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at opengeo.org  Tue Jan 20 15:58:11 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 20 Jan 2009 15:58:11 -0800
Subject: [postgis-devel] More Alignment
Message-ID: <D3AEE08D-11E7-458C-847C-0BDE2D572132@opengeo.org>

I've started writing up some thoughts about aligning the on-disk  
format. There are lots of different trade-offs, so I figure having  
some basic information down before we get together will help focus  
the discussion.

I think my general favored approach now is to scrunch type/srid into  
a single 32-bit space, make srid mandatory, and expand all "length"  
fields (npoints, nrings, ngeoms) to longlong. This keeps the very- 
small features (2d points, 2-vertex lines) still very close to their  
current sizes, and the penalty for larger things is not very large,  
percentage wise.


Paul
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alignment_rfc.txt
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090120/6a120763/attachment.txt>

From dfuhry at acm.org  Tue Jan 20 16:23:05 2009
From: dfuhry at acm.org (David Fuhry)
Date: Tue, 20 Jan 2009 19:23:05 -0500
Subject: [postgis-devel] GUI Time
In-Reply-To: <6264C3B2-B541-4235-A84A-79DC29A464EF@cleverelephant.ca>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>	<4961DE6B.9090203@siriusit.co.uk>	<2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>	<49628999.4030605@siriusit.co.uk>
	<6264C3B2-B541-4235-A84A-79DC29A464EF@cleverelephant.ca>
Message-ID: <49766AE9.7030907@acm.org>

Paul Ramsey wrote:
> Yes, it's GTK+, so we should be 100% cross platform. I'm sure compiling 
> will be an adventure, but... :)

This is a very belated comment, but it would be excellent if the 
shapefile GUI loader could be a plugin to PgAdmin.  In my experience, 
people who would want a GUI shapefile loader are the same sort of people 
likely to already be using a GUI for DBMS management.

Oracle has an analogous MapBuilder GUI tool which can (among other 
things) load shapefiles, and a Spatial add-on for their SqlDeveloper GUI 
management tool, which can view geometries.  Both have some rough edges 
but are overall quite handy.

-Dave


From pramsey at opengeo.org  Tue Jan 20 17:13:26 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 20 Jan 2009 17:13:26 -0800
Subject: [postgis-devel] Alignment Revision
Message-ID: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>

I wonder if I should put this document into SVN? We could start an  
RFC directory for these kinds of discussions. Things like your  
performance testing, Mark, shouldn't be hidden in the mail archive.

(This revision adds two examples for single-part multilinestrings,  
which shows one of the downsides of including a "user-data" 4-byte  
block at the start of the structure. Might be better to just pad the  
PG_LWGEOM an extra four bytes forward (but then you pay in the simple  
point case).)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alignment_rfc.txt
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090120/5a3fe8d8/attachment.txt>
-------------- next part --------------


P.

From pramsey at opengeo.org  Tue Jan 20 21:49:49 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Tue, 20 Jan 2009 21:49:49 -0800
Subject: [postgis-devel] Another Data Point
Message-ID: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>

Using the original sample set from Lee Keel,

With the old style ST_Union, 3 hours, 27 minutes:

uniontest=# select st_area(st_union(the_geom)) from sample_poly;
      st_area
--------------------
 0.0324039850011104
(1 row)

Time: 12419261.819 ms


With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times faster.

uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
      st_area
--------------------
 0.0324039850054305
(1 row)

Time: 271618.181 ms


That's one nasty data set.

P.


From mark.cave-ayland at siriusit.co.uk  Wed Jan 21 02:38:03 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 21 Jan 2009 10:38:03 +0000
Subject: [postgis-devel] Alignment Revision
In-Reply-To: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>
References: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>
Message-ID: <4976FB0B.70000@siriusit.co.uk>

Paul Ramsey wrote:

> I wonder if I should put this document into SVN? We could start an RFC 
> directory for these kinds of discussions. Things like your performance 
> testing, Mark, shouldn't be hidden in the mail archive.
> 
> (This revision adds two examples for single-part multilinestrings, which 
> shows one of the downsides of including a "user-data" 4-byte block at 
> the start of the structure. Might be better to just pad the PG_LWGEOM an 
> extra four bytes forward (but then you pay in the simple point case).)

Nice work Paul. On skim-reading the document, it looks reasonably 
sensible although I'll have to sit down and read it in some detail. 
However, I think that your fundamental statement about LWGEOM is wrong:

'Right now, PG_LWGEOM is just an LWGEOM with an extra 4-bytes of 
information tacked onto the front.'

This is not true. A LWGEOM structure contains the basics about the 
geometry, but does not contain any coordinate information. Think about a 
LWLINE which contains a pointer to a POINTARRAY which itself points to 
an array of doubles which can be anywhere in memory.

In order to get the LWGEOM in/out of PostgreSQL we need to 
serialize/deserialize the geometry. So what we are handed by PostgreSQL 
is actually a *SERIALIZED* LWGEOM and so we must deserialize it into a 
LWGEOM structure that we can actually do something useful with. The most 
interesting part about this is that during the opposite process of 
serialization, we have to iterate through any point arrays within a 
LWGEOM anyway in order to memcpy() them into serialized form ready to 
return to PostgreSQL.

Copying the minimal amount of information from the head of a serialized 
LWGEOM to a LWGEOM will be extremely quick, and so I'm not worried about 
this. Therefore the key is to make the coordinate arrays double-aligned 
within the PostgreSQL Datum so that during the deserialization process, 
we can just point the POINTARRAY straight into the Datum - which is what 
already happens.

Hence all we have to do is:

	- Ensure the double arrays are aligned within the Datum
	- Rewrite any accessor methods to iterate through the
	array pointer directly, rather than through
	getPoint_internal

I'll have a read through the proposed schemes in more detail when I get 
a spare moment :O


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Wed Jan 21 02:40:38 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 21 Jan 2009 10:40:38 +0000
Subject: [postgis-devel] GUI Time
In-Reply-To: <49766AE9.7030907@acm.org>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>	<4961DE6B.9090203@siriusit.co.uk>	<2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>	<49628999.4030605@siriusit.co.uk>	<6264C3B2-B541-4235-A84A-79DC29A464EF@cleverelephant.ca>
	<49766AE9.7030907@acm.org>
Message-ID: <4976FBA6.3030500@siriusit.co.uk>

David Fuhry wrote:

> This is a very belated comment, but it would be excellent if the 
> shapefile GUI loader could be a plugin to PgAdmin.  In my experience, 
> people who would want a GUI shapefile loader are the same sort of people 
> likely to already be using a GUI for DBMS management.
> 
> Oracle has an analogous MapBuilder GUI tool which can (among other 
> things) load shapefiles, and a Spatial add-on for their SqlDeveloper GUI 
> management tool, which can view geometries.  Both have some rough edges 
> but are overall quite handy.
> 
> -Dave

Ooooh that's interesting - I'll CC Dave to get a rough indicator as to 
whether this is possible or not.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From strk at keybit.net  Wed Jan 21 02:53:31 2009
From: strk at keybit.net (strk)
Date: Wed, 21 Jan 2009 11:53:31 +0100
Subject: [postgis-devel] Alignment Revision
In-Reply-To: <4976FB0B.70000@siriusit.co.uk>
References: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>
	<4976FB0B.70000@siriusit.co.uk>
Message-ID: <20090121105331.GB33765@keybit.net>

On Wed, Jan 21, 2009 at 10:38:03AM +0000, Mark Cave-Ayland wrote:

> In order to get the LWGEOM in/out of PostgreSQL we need to 
> serialize/deserialize the geometry. So what we are handed by PostgreSQL 
> is actually a *SERIALIZED* LWGEOM and so we must deserialize it into a 
> LWGEOM structure that we can actually do something useful with.

Correct. We deserialize for covenience, but do not copy actual vertex
data (doubles).

> The most 
> interesting part about this is that during the opposite process of 
> serialization, we have to iterate through any point arrays within a 
> LWGEOM anyway in order to memcpy() them into serialized form ready to 
> return to PostgreSQL.

We don't memcpy each value here (at least we do not need to) but
rather memcpy the whole pointarray data. No copying is required
if the function implements a read-only operation.

> Copying the minimal amount of information from the head of a serialized 
> LWGEOM to a LWGEOM will be extremely quick, and so I'm not worried about 
> this. Therefore the key is to make the coordinate arrays double-aligned 
> within the PostgreSQL Datum so that during the deserialization process, 
> we can just point the POINTARRAY straight into the Datum - which is what 
> already happens.

To rephrase, the key is to make the on-disk coordinate arrays
double-aligned so that during inspection we can just cast every
ordinate pointer to a double w/out incurring in either a performance
penalty (x86) or misread (on architectures that do not allow reading
a double from a non-double aligned memory address).
Correct ?

> Hence all we have to do is:
> 
> 	- Ensure the double arrays are aligned within the Datum
> 	- Rewrite any accessor methods to iterate through the
> 	array pointer directly, rather than through
> 	getPoint_internal

You mean ratehr then through getPoint_p here, as getPoint_internal
is what returns a pointer into the POINTARRAY, which can be or not
aligned depending on where the POINTARRAY comes from.
If you allocated the POINTARRAY yourself it will be aligned, if
it cams from the PostgreSQL Datum, it may or not be depending
on how it was written.

This is an interesting thread as I proceed defining memory structures
to use for holding rasters as in that case we'll have different
alignment constraints based on pixeltype (from 1 to 8 bytes per byte,
so requiring different padding).

--strk;


From mark.cave-ayland at siriusit.co.uk  Wed Jan 21 03:37:53 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 21 Jan 2009 11:37:53 +0000
Subject: [postgis-devel] Alignment Revision
In-Reply-To: <20090121105331.GB33765@keybit.net>
References: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>	<4976FB0B.70000@siriusit.co.uk>
	<20090121105331.GB33765@keybit.net>
Message-ID: <49770911.1020206@siriusit.co.uk>

strk wrote:

>> In order to get the LWGEOM in/out of PostgreSQL we need to 
>> serialize/deserialize the geometry. So what we are handed by PostgreSQL 
>> is actually a *SERIALIZED* LWGEOM and so we must deserialize it into a 
>> LWGEOM structure that we can actually do something useful with.
> 
> Correct. We deserialize for covenience, but do not copy actual vertex
> data (doubles).

Excellent - so I understood this part ;)

>> The most 
>> interesting part about this is that during the opposite process of 
>> serialization, we have to iterate through any point arrays within a 
>> LWGEOM anyway in order to memcpy() them into serialized form ready to 
>> return to PostgreSQL.
> 
> We don't memcpy each value here (at least we do not need to) but
> rather memcpy the whole pointarray data. No copying is required
> if the function implements a read-only operation.

Yup. Only functions that return (modified) geometries require the 
overhead of serialization.

>> Copying the minimal amount of information from the head of a serialized 
>> LWGEOM to a LWGEOM will be extremely quick, and so I'm not worried about 
>> this. Therefore the key is to make the coordinate arrays double-aligned 
>> within the PostgreSQL Datum so that during the deserialization process, 
>> we can just point the POINTARRAY straight into the Datum - which is what 
>> already happens.
> 
> To rephrase, the key is to make the on-disk coordinate arrays
> double-aligned so that during inspection we can just cast every
> ordinate pointer to a double w/out incurring in either a performance
> penalty (x86) or misread (on architectures that do not allow reading
> a double from a non-double aligned memory address).
> Correct ?

Yes. Please see my original post and test harness here: 
http://lists.refractions.net/pipermail/postgis-devel/2009-January/004473.html. 
  Even with a memcpy() from unaligned to aligned space, the speed 
difference is quite impressive.

>> Hence all we have to do is:
>>
>> 	- Ensure the double arrays are aligned within the Datum
>> 	- Rewrite any accessor methods to iterate through the
>> 	array pointer directly, rather than through
>> 	getPoint_internal
> 
> You mean ratehr then through getPoint_p here, as getPoint_internal
> is what returns a pointer into the POINTARRAY, which can be or not
> aligned depending on where the POINTARRAY comes from.
> If you allocated the POINTARRAY yourself it will be aligned, if
> it cams from the PostgreSQL Datum, it may or not be depending
> on how it was written.

Yes.

> This is an interesting thread as I proceed defining memory structures
> to use for holding rasters as in that case we'll have different
> alignment constraints based on pixeltype (from 1 to 8 bytes per byte,
> so requiring different padding).

It may be worth you playing with the testmem.c harness in the above 
email to see whether it has a similar performance effect when accessing 
rasters.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From strk at keybit.net  Wed Jan 21 04:29:40 2009
From: strk at keybit.net (strk)
Date: Wed, 21 Jan 2009 13:29:40 +0100
Subject: [postgis-devel] Alignment Revision
In-Reply-To: <49770911.1020206@siriusit.co.uk>
References: <F14723C3-C3C9-41CD-AF8E-5EA2A4255950@opengeo.org>
	<4976FB0B.70000@siriusit.co.uk> <20090121105331.GB33765@keybit.net>
	<49770911.1020206@siriusit.co.uk>
Message-ID: <20090121122940.GD33765@keybit.net>

On Wed, Jan 21, 2009 at 11:37:53AM +0000, Mark Cave-Ayland wrote:

> Yes. Please see my original post and test harness here: 
> http://lists.refractions.net/pipermail/postgis-devel/2009-January/004473.html. 
>  Even with a memcpy() from unaligned to aligned space, the speed difference 
> is quite impressive.

I suggest you add a test using getPoint_internal on unaligned
memory. The rational here is that IFF the architecture doesn't
required aligned memory, we might still use getPoint_internal
in there w/out changing the structure (and possibly with not-so-big
overhead due to non-aligned reads).

In other words, I'm not convinced that the performance penalty
comes from aligned vs. unaligned, but mostly from the additional
function calls (memcpy) required at each iteration.

> It may be worth you playing with the testmem.c harness in the above 
> email to see whether it has a similar performance effect when accessing 
> rasters.

I guess it really depends on use cases, the accesses could
be optimized based on the operation. For example, if the
function only needs to return a given point (say pointN)
a single memcpy (per value) won't be a big problem, while if
it needs to scan the whole thing a single memcpy (per pointarray)
might not be a big problem.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From robe.dnd at cityofboston.gov  Wed Jan 21 05:17:39 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 08:17:39 -0500
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>

Ah I think JTS was able to do this in about 40-50 seconds.  And my
version was able to beat out Kevin's nested by a small margin.  I'll
retest on mine.

So I think we still need work here.

I'm curious what would happen if I combined the algorithm I wrote with
the new ST_Union how things would fair.  In theory it should fair the
same, but I'm not really using Martin's cascaded union algorithm to the
letter.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Wednesday, January 21, 2009 12:50 AM
To: PostGIS Development Discussion
Cc: lee.keel at uai.com
Subject: [postgis-devel] Another Data Point

Using the original sample set from Lee Keel,

With the old style ST_Union, 3 hours, 27 minutes:

uniontest=# select st_area(st_union(the_geom)) from sample_poly;
      st_area
--------------------
 0.0324039850011104
(1 row)

Time: 12419261.819 ms


With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
faster.

uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
      st_area
--------------------
 0.0324039850054305
(1 row)

Time: 271618.181 ms


That's one nasty data set.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From robe.dnd at cityofboston.gov  Wed Jan 21 06:09:09 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 09:09:09 -0500
Subject: [postgis-devel] GUI Time
In-Reply-To: <49766AE9.7030907@acm.org>
References: <AA53C384-C762-424D-AAEE-2C3E8842F016@opengeo.org>	<4961DE6B.9090203@siriusit.co.uk>	<2596EC25-52B8-48B2-908A-5ED849D85B31@opengeo.org>	<49628999.4030605@siriusit.co.uk><6264C3B2-B541-4235-A84A-79DC29A464EF@cleverelephant.ca>
	<49766AE9.7030907@acm.org>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F1264@ZDND.DND.boston.cob>

Dave,

I was thinking the same myself but thought I'd wait till Paul has it a
bit more polished before I suggested.  Both are GTK based. 

I could ask on the PgAdmin list the possiblity of doing that.  They are
a pretty responsive crowd as is most of PostgreSQL group.

Now all we need is a visual spatial plugin for PgAdmin and then I can
really have all those graphical addicts lapping up PostGIS.

Thanks,
Regina


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
David Fuhry
Sent: Tuesday, January 20, 2009 7:23 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] GUI Time

Paul Ramsey wrote:
> Yes, it's GTK+, so we should be 100% cross platform. I'm sure
compiling 
> will be an adventure, but... :)

This is a very belated comment, but it would be excellent if the 
shapefile GUI loader could be a plugin to PgAdmin.  In my experience, 
people who would want a GUI shapefile loader are the same sort of people

likely to already be using a GUI for DBMS management.

Oracle has an analogous MapBuilder GUI tool which can (among other 
things) load shapefiles, and a Spatial add-on for their SqlDeveloper GUI

management tool, which can view geometries.  Both have some rough edges 
but are overall quite handy.

-Dave
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mbdavis at refractions.net  Wed Jan 21 08:55:12 2009
From: mbdavis at refractions.net (Martin Davis)
Date: Wed, 21 Jan 2009 08:55:12 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
Message-ID: <49775370.2030907@refractions.net>

Go for it, Regina!  The glove is dropped...

Although I suspect this test may simply be running into the slower 
memory performance due to any or all of Postgres, C, GEOS compared to 
good ol' Java...  Hard to beat that tuned JVM memory manager!

Obe, Regina wrote:
> Ah I think JTS was able to do this in about 40-50 seconds.  And my
> version was able to beat out Kevin's nested by a small margin.  I'll
> retest on mine.
>
> So I think we still need work here.
>
> I'm curious what would happen if I combined the algorithm I wrote with
> the new ST_Union how things would fair.  In theory it should fair the
> same, but I'm not really using Martin's cascaded union algorithm to the
> letter.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Wednesday, January 21, 2009 12:50 AM
> To: PostGIS Development Discussion
> Cc: lee.keel at uai.com
> Subject: [postgis-devel] Another Data Point
>
> Using the original sample set from Lee Keel,
>
> With the old style ST_Union, 3 hours, 27 minutes:
>
> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>       st_area
> --------------------
>  0.0324039850011104
> (1 row)
>
> Time: 12419261.819 ms
>
>
> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
> faster.
>
> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>       st_area
> --------------------
>  0.0324039850054305
> (1 row)
>
> Time: 271618.181 ms
>
>
> That's one nasty data set.
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



From pramsey at cleverelephant.ca  Wed Jan 21 09:00:42 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 09:00:42 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <49775370.2030907@refractions.net>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
Message-ID: <30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>

The glove is dropped indeed... why speculate when I have the Shark...
time to see where our time goes...

P

On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net> wrote:
> Go for it, Regina!  The glove is dropped...
>
> Although I suspect this test may simply be running into the slower memory
> performance due to any or all of Postgres, C, GEOS compared to good ol'
> Java...  Hard to beat that tuned JVM memory manager!
>
> Obe, Regina wrote:
>>
>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>> version was able to beat out Kevin's nested by a small margin.  I'll
>> retest on mine.
>>
>> So I think we still need work here.
>>
>> I'm curious what would happen if I combined the algorithm I wrote with
>> the new ST_Union how things would fair.  In theory it should fair the
>> same, but I'm not really using Martin's cascaded union algorithm to the
>> letter.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Wednesday, January 21, 2009 12:50 AM
>> To: PostGIS Development Discussion
>> Cc: lee.keel at uai.com
>> Subject: [postgis-devel] Another Data Point
>>
>> Using the original sample set from Lee Keel,
>>
>> With the old style ST_Union, 3 hours, 27 minutes:
>>
>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>      st_area
>> --------------------
>>  0.0324039850011104
>> (1 row)
>>
>> Time: 12419261.819 ms
>>
>>
>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>> faster.
>>
>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>      st_area
>> --------------------
>>  0.0324039850054305
>> (1 row)
>>
>> Time: 271618.181 ms
>>
>>
>> That's one nasty data set.
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at cleverelephant.ca  Wed Jan 21 09:05:25 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 09:05:25 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
Message-ID: <30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>

Interesting! The Shark only samples for about 20 seconds, so I only
got the first 10% or so of the run, and the biggest user in that time
period memcpy'ing in LWGEOM_accum (postgis) and
advance_transition_function (pgsql). So we are spending a non-trivial
amount of time just accumulating the input...

P

On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> The glove is dropped indeed... why speculate when I have the Shark...
> time to see where our time goes...
>
> P
>
> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net> wrote:
>> Go for it, Regina!  The glove is dropped...
>>
>> Although I suspect this test may simply be running into the slower memory
>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>> Java...  Hard to beat that tuned JVM memory manager!
>>
>> Obe, Regina wrote:
>>>
>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>> retest on mine.
>>>
>>> So I think we still need work here.
>>>
>>> I'm curious what would happen if I combined the algorithm I wrote with
>>> the new ST_Union how things would fair.  In theory it should fair the
>>> same, but I'm not really using Martin's cascaded union algorithm to the
>>> letter.
>>>
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net
>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>>> Ramsey
>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>> To: PostGIS Development Discussion
>>> Cc: lee.keel at uai.com
>>> Subject: [postgis-devel] Another Data Point
>>>
>>> Using the original sample set from Lee Keel,
>>>
>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>
>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>      st_area
>>> --------------------
>>>  0.0324039850011104
>>> (1 row)
>>>
>>> Time: 12419261.819 ms
>>>
>>>
>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>> faster.
>>>
>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>      st_area
>>> --------------------
>>>  0.0324039850054305
>>> (1 row)
>>>
>>> Time: 271618.181 ms
>>>
>>>
>>> That's one nasty data set.
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> -----------------------------------------
>>> The substance of this message, including any attachments, may be
>>> confidential, legally privileged and/or exempt from disclosure
>>> pursuant to Massachusetts law. It is intended
>>> solely for the addressee. If you received this in error, please
>>> contact the sender and delete the material from any computer.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>


From robe.dnd at cityofboston.gov  Wed Jan 21 09:10:43 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 12:10:43 -0500
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>

That is not surprising.  I think much of the benefit of my code was
spoon feeding to postgis so sort of acting as a memory manager within
the PostgreSQL context and my arrays were much smaller -- never ended up
with a single array of yeh big as I recall.  Though its been a while
since I have looked.

Anyrate I'll retest in the next day or so against 3.1.   I would be
curious to see the results.

Yes accumulation when you get in the 1000s is non-trivial because
PostgreSQL has to resize the array.

Which is why a construct such as 

ARRAY(SELECT the_geom FROM sometable)

is faster than 

SELECT ST_Accum(the_geom)
FROM sometable

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Wednesday, January 21, 2009 12:05 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point

Interesting! The Shark only samples for about 20 seconds, so I only
got the first 10% or so of the run, and the biggest user in that time
period memcpy'ing in LWGEOM_accum (postgis) and
advance_transition_function (pgsql). So we are spending a non-trivial
amount of time just accumulating the input...

P

On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:
> The glove is dropped indeed... why speculate when I have the Shark...
> time to see where our time goes...
>
> P
>
> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
<mbdavis at refractions.net> wrote:
>> Go for it, Regina!  The glove is dropped...
>>
>> Although I suspect this test may simply be running into the slower
memory
>> performance due to any or all of Postgres, C, GEOS compared to good
ol'
>> Java...  Hard to beat that tuned JVM memory manager!
>>
>> Obe, Regina wrote:
>>>
>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>> retest on mine.
>>>
>>> So I think we still need work here.
>>>
>>> I'm curious what would happen if I combined the algorithm I wrote
with
>>> the new ST_Union how things would fair.  In theory it should fair
the
>>> same, but I'm not really using Martin's cascaded union algorithm to
the
>>> letter.
>>>
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net
>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Paul
>>> Ramsey
>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>> To: PostGIS Development Discussion
>>> Cc: lee.keel at uai.com
>>> Subject: [postgis-devel] Another Data Point
>>>
>>> Using the original sample set from Lee Keel,
>>>
>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>
>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>      st_area
>>> --------------------
>>>  0.0324039850011104
>>> (1 row)
>>>
>>> Time: 12419261.819 ms
>>>
>>>
>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>> faster.
>>>
>>> uniontest=# select st_area(st_union_fast(the_geom)) from
sample_poly;
>>>      st_area
>>> --------------------
>>>  0.0324039850054305
>>> (1 row)
>>>
>>> Time: 271618.181 ms
>>>
>>>
>>> That's one nasty data set.
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> -----------------------------------------
>>> The substance of this message, including any attachments, may be
>>> confidential, legally privileged and/or exempt from disclosure
>>> pursuant to Massachusetts law. It is intended
>>> solely for the addressee. If you received this in error, please
>>> contact the sender and delete the material from any computer.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mark.cave-ayland at siriusit.co.uk  Wed Jan 21 09:11:07 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Wed, 21 Jan 2009 17:11:07 +0000
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>	<49775370.2030907@refractions.net>	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
Message-ID: <4977572B.4070507@siriusit.co.uk>

Paul Ramsey wrote:

> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
> 
> P

Yeah, I think this came out of some of Regina's observations earlier 
when she was looking at changing the function; constantly accumulating 
onto the end of an array is slow since we repalloc() the memory and 
rebuild the entire type each time through...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at cleverelephant.ca  Wed Jan 21 09:13:43 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 09:13:43 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
Message-ID: <30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>

I got another run in, right near the end, and it showed that
GEOSUnionCascaded took only about 50% of the time in that slice. There
was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
would be as fast as JTS (or faster?).

P.

On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
>
> P
>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> The glove is dropped indeed... why speculate when I have the Shark...
>> time to see where our time goes...
>>
>> P
>>
>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net> wrote:
>>> Go for it, Regina!  The glove is dropped...
>>>
>>> Although I suspect this test may simply be running into the slower memory
>>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>>> Java...  Hard to beat that tuned JVM memory manager!
>>>
>>> Obe, Regina wrote:
>>>>
>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>> retest on mine.
>>>>
>>>> So I think we still need work here.
>>>>
>>>> I'm curious what would happen if I combined the algorithm I wrote with
>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>> same, but I'm not really using Martin's cascaded union algorithm to the
>>>> letter.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>>>> Ramsey
>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>> To: PostGIS Development Discussion
>>>> Cc: lee.keel at uai.com
>>>> Subject: [postgis-devel] Another Data Point
>>>>
>>>> Using the original sample set from Lee Keel,
>>>>
>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>
>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850011104
>>>> (1 row)
>>>>
>>>> Time: 12419261.819 ms
>>>>
>>>>
>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>> faster.
>>>>
>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850054305
>>>> (1 row)
>>>>
>>>> Time: 271618.181 ms
>>>>
>>>>
>>>> That's one nasty data set.
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>> -----------------------------------------
>>>> The substance of this message, including any attachments, may be
>>>> confidential, legally privileged and/or exempt from disclosure
>>>> pursuant to Massachusetts law. It is intended
>>>> solely for the addressee. If you received this in error, please
>>>> contact the sender and delete the material from any computer.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>
>


From robe.dnd at cityofboston.gov  Wed Jan 21 09:20:18 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 12:20:18 -0500
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F15CF@ZDND.DND.boston.cob>

You can try using st_unite_cascade_garray instead of ST_Union aggregate.

I think that would be a closer test to raw GEOSUnionCascaded.  Although
you probably have an easier way of testing this. 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Wednesday, January 21, 2009 12:14 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point

I got another run in, right near the end, and it showed that
GEOSUnionCascaded took only about 50% of the time in that slice. There
was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
would be as fast as JTS (or faster?).

P.

On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:
> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
>
> P
>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey
<pramsey at cleverelephant.ca> wrote:
>> The glove is dropped indeed... why speculate when I have the Shark...
>> time to see where our time goes...
>>
>> P
>>
>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
<mbdavis at refractions.net> wrote:
>>> Go for it, Regina!  The glove is dropped...
>>>
>>> Although I suspect this test may simply be running into the slower
memory
>>> performance due to any or all of Postgres, C, GEOS compared to good
ol'
>>> Java...  Hard to beat that tuned JVM memory manager!
>>>
>>> Obe, Regina wrote:
>>>>
>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>> version was able to beat out Kevin's nested by a small margin.
I'll
>>>> retest on mine.
>>>>
>>>> So I think we still need work here.
>>>>
>>>> I'm curious what would happen if I combined the algorithm I wrote
with
>>>> the new ST_Union how things would fair.  In theory it should fair
the
>>>> same, but I'm not really using Martin's cascaded union algorithm to
the
>>>> letter.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Paul
>>>> Ramsey
>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>> To: PostGIS Development Discussion
>>>> Cc: lee.keel at uai.com
>>>> Subject: [postgis-devel] Another Data Point
>>>>
>>>> Using the original sample set from Lee Keel,
>>>>
>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>
>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850011104
>>>> (1 row)
>>>>
>>>> Time: 12419261.819 ms
>>>>
>>>>
>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>> faster.
>>>>
>>>> uniontest=# select st_area(st_union_fast(the_geom)) from
sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850054305
>>>> (1 row)
>>>>
>>>> Time: 271618.181 ms
>>>>
>>>>
>>>> That's one nasty data set.
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>> -----------------------------------------
>>>> The substance of this message, including any attachments, may be
>>>> confidential, legally privileged and/or exempt from disclosure
>>>> pursuant to Massachusetts law. It is intended
>>>> solely for the addressee. If you received this in error, please
>>>> contact the sender and delete the material from any computer.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mbdavis at refractions.net  Wed Jan 21 10:10:54 2009
From: mbdavis at refractions.net (Martin Davis)
Date: Wed, 21 Jan 2009 10:10:54 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>	<49775370.2030907@refractions.net>	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
Message-ID: <4977652E.70101@refractions.net>

Could be...   It would be interesting to see whether GEOS is faster than 
JTS.   Needs a test environment able to run both pieces of code on the 
same hardware.

Paul Ramsey wrote:
> I got another run in, right near the end, and it showed that
> GEOSUnionCascaded took only about 50% of the time in that slice. There
> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
> would be as fast as JTS (or faster?).
>
> P.
>
> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>   
>> Interesting! The Shark only samples for about 20 seconds, so I only
>> got the first 10% or so of the run, and the biggest user in that time
>> period memcpy'ing in LWGEOM_accum (postgis) and
>> advance_transition_function (pgsql). So we are spending a non-trivial
>> amount of time just accumulating the input...
>>
>> P
>>
>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>     
>>> The glove is dropped indeed... why speculate when I have the Shark...
>>> time to see where our time goes...
>>>
>>> P
>>>
>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net> wrote:
>>>       
>>>> Go for it, Regina!  The glove is dropped...
>>>>
>>>> Although I suspect this test may simply be running into the slower memory
>>>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>
>>>> Obe, Regina wrote:
>>>>         
>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>> retest on mine.
>>>>>
>>>>> So I think we still need work here.
>>>>>
>>>>> I'm curious what would happen if I combined the algorithm I wrote with
>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>> same, but I'm not really using Martin's cascaded union algorithm to the
>>>>> letter.
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>>>>> Ramsey
>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>> To: PostGIS Development Discussion
>>>>> Cc: lee.keel at uai.com
>>>>> Subject: [postgis-devel] Another Data Point
>>>>>
>>>>> Using the original sample set from Lee Keel,
>>>>>
>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>
>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>      st_area
>>>>> --------------------
>>>>>  0.0324039850011104
>>>>> (1 row)
>>>>>
>>>>> Time: 12419261.819 ms
>>>>>
>>>>>
>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>> faster.
>>>>>
>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>      st_area
>>>>> --------------------
>>>>>  0.0324039850054305
>>>>> (1 row)
>>>>>
>>>>> Time: 271618.181 ms
>>>>>
>>>>>
>>>>> That's one nasty data set.
>>>>>
>>>>> P.
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>> -----------------------------------------
>>>>> The substance of this message, including any attachments, may be
>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>> pursuant to Massachusetts law. It is intended
>>>>> solely for the addressee. If you received this in error, please
>>>>> contact the sender and delete the material from any computer.
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>>           
>>>> --
>>>> Martin Davis
>>>> Senior Technical Architect
>>>> Refractions Research, Inc.
>>>> (250) 383-3022
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>         
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



From david.bitner at gmail.com  Wed Jan 21 10:18:10 2009
From: david.bitner at gmail.com (David William Bitner)
Date: Wed, 21 Jan 2009 12:18:10 -0600
Subject: [postgis-devel] Another Data Point
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>
Message-ID: <d2f53e190901211018r2bbf82dube8311821c44da6b@mail.gmail.com>

Would any of the 8.4 implementation of the generic array_agg() function be
applicable to this?

On Wed, Jan 21, 2009 at 11:10 AM, Obe, Regina <robe.dnd at cityofboston.gov>wrote:

> That is not surprising.  I think much of the benefit of my code was
> spoon feeding to postgis so sort of acting as a memory manager within
> the PostgreSQL context and my arrays were much smaller -- never ended up
> with a single array of yeh big as I recall.  Though its been a while
> since I have looked.
>
> Anyrate I'll retest in the next day or so against 3.1.   I would be
> curious to see the results.
>
> Yes accumulation when you get in the 1000s is non-trivial because
> PostgreSQL has to resize the array.
>
> Which is why a construct such as
>
> ARRAY(SELECT the_geom FROM sometable)
>
> is faster than
>
> SELECT ST_Accum(the_geom)
> FROM sometable
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Wednesday, January 21, 2009 12:05 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
>
> P
>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
> > The glove is dropped indeed... why speculate when I have the Shark...
> > time to see where our time goes...
> >
> > P
> >
> > On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
> <mbdavis at refractions.net> wrote:
> >> Go for it, Regina!  The glove is dropped...
> >>
> >> Although I suspect this test may simply be running into the slower
> memory
> >> performance due to any or all of Postgres, C, GEOS compared to good
> ol'
> >> Java...  Hard to beat that tuned JVM memory manager!
> >>
> >> Obe, Regina wrote:
> >>>
> >>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
> >>> version was able to beat out Kevin's nested by a small margin.  I'll
> >>> retest on mine.
> >>>
> >>> So I think we still need work here.
> >>>
> >>> I'm curious what would happen if I combined the algorithm I wrote
> with
> >>> the new ST_Union how things would fair.  In theory it should fair
> the
> >>> same, but I'm not really using Martin's cascaded union algorithm to
> the
> >>> letter.
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: postgis-devel-bounces at postgis.refractions.net
> >>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
> Paul
> >>> Ramsey
> >>> Sent: Wednesday, January 21, 2009 12:50 AM
> >>> To: PostGIS Development Discussion
> >>> Cc: lee.keel at uai.com
> >>> Subject: [postgis-devel] Another Data Point
> >>>
> >>> Using the original sample set from Lee Keel,
> >>>
> >>> With the old style ST_Union, 3 hours, 27 minutes:
> >>>
> >>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
> >>>      st_area
> >>> --------------------
> >>>  0.0324039850011104
> >>> (1 row)
> >>>
> >>> Time: 12419261.819 ms
> >>>
> >>>
> >>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
> >>> faster.
> >>>
> >>> uniontest=# select st_area(st_union_fast(the_geom)) from
> sample_poly;
> >>>      st_area
> >>> --------------------
> >>>  0.0324039850054305
> >>> (1 row)
> >>>
> >>> Time: 271618.181 ms
> >>>
> >>>
> >>> That's one nasty data set.
> >>>
> >>> P.
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>> -----------------------------------------
> >>> The substance of this message, including any attachments, may be
> >>> confidential, legally privileged and/or exempt from disclosure
> >>> pursuant to Massachusetts law. It is intended
> >>> solely for the addressee. If you received this in error, please
> >>> contact the sender and delete the material from any computer.
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >>>
> >>
> >> --
> >> Martin Davis
> >> Senior Technical Architect
> >> Refractions Research, Inc.
> >> (250) 383-3022
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/4a4595bb/attachment.html>

From robe.dnd at cityofboston.gov  Wed Jan 21 10:50:59 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 13:50:59 -0500
Subject: [postgis-devel] Another Data Point
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>
	<d2f53e190901211018r2bbf82dube8311821c44da6b@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F115@ZDND.DND.boston.cob>

David,
Possibly.  Wasn't aware of those changes. I'll check those out.
I've just recently started exploring 8.4, but haven't gotten that far into it.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of David William Bitner
Sent: Wed 1/21/2009 1:18 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point
 
Would any of the 8.4 implementation of the generic array_agg() function be
applicable to this?

On Wed, Jan 21, 2009 at 11:10 AM, Obe, Regina <robe.dnd at cityofboston.gov>wrote:

> That is not surprising.  I think much of the benefit of my code was
> spoon feeding to postgis so sort of acting as a memory manager within
> the PostgreSQL context and my arrays were much smaller -- never ended up
> with a single array of yeh big as I recall.  Though its been a while
> since I have looked.
>
> Anyrate I'll retest in the next day or so against 3.1.   I would be
> curious to see the results.
>
> Yes accumulation when you get in the 1000s is non-trivial because
> PostgreSQL has to resize the array.
>
> Which is why a construct such as
>
> ARRAY(SELECT the_geom FROM sometable)
>
> is faster than
>
> SELECT ST_Accum(the_geom)
> FROM sometable
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Wednesday, January 21, 2009 12:05 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
>
> P
>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
> > The glove is dropped indeed... why speculate when I have the Shark...
> > time to see where our time goes...
> >
> > P
> >
> > On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
> <mbdavis at refractions.net> wrote:
> >> Go for it, Regina!  The glove is dropped...
> >>
> >> Although I suspect this test may simply be running into the slower
> memory
> >> performance due to any or all of Postgres, C, GEOS compared to good
> ol'
> >> Java...  Hard to beat that tuned JVM memory manager!
> >>
> >> Obe, Regina wrote:
> >>>
> >>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
> >>> version was able to beat out Kevin's nested by a small margin.  I'll
> >>> retest on mine.
> >>>
> >>> So I think we still need work here.
> >>>
> >>> I'm curious what would happen if I combined the algorithm I wrote
> with
> >>> the new ST_Union how things would fair.  In theory it should fair
> the
> >>> same, but I'm not really using Martin's cascaded union algorithm to
> the
> >>> letter.
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: postgis-devel-bounces at postgis.refractions.net
> >>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
> Paul
> >>> Ramsey
> >>> Sent: Wednesday, January 21, 2009 12:50 AM
> >>> To: PostGIS Development Discussion
> >>> Cc: lee.keel at uai.com
> >>> Subject: [postgis-devel] Another Data Point
> >>>
> >>> Using the original sample set from Lee Keel,
> >>>
> >>> With the old style ST_Union, 3 hours, 27 minutes:
> >>>
> >>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
> >>>      st_area
> >>> --------------------
> >>>  0.0324039850011104
> >>> (1 row)
> >>>
> >>> Time: 12419261.819 ms
> >>>
> >>>
> >>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
> >>> faster.
> >>>
> >>> uniontest=# select st_area(st_union_fast(the_geom)) from
> sample_poly;
> >>>      st_area
> >>> --------------------
> >>>  0.0324039850054305
> >>> (1 row)
> >>>
> >>> Time: 271618.181 ms
> >>>
> >>>
> >>> That's one nasty data set.
> >>>
> >>> P.
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>> -----------------------------------------
> >>> The substance of this message, including any attachments, may be
> >>> confidential, legally privileged and/or exempt from disclosure
> >>> pursuant to Massachusetts law. It is intended
> >>> solely for the addressee. If you received this in error, please
> >>> contact the sender and delete the material from any computer.
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >>>
> >>
> >> --
> >> Martin Davis
> >> Senior Technical Architect
> >> Refractions Research, Inc.
> >> (250) 383-3022
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/f5616f5c/attachment.html>

From pramsey at cleverelephant.ca  Wed Jan 21 10:58:41 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 10:58:41 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <4977652E.70101@refractions.net>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
	<4977652E.70101@refractions.net>
Message-ID: <30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>

Well, just running this:

uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
  geometrytype
--------------------
 GEOMETRYCOLLECTION
(1 row)

Time: 261624.195 ms

takes 251 of the 271 seconds the union operation took... the
implication is that the GEOS portion of the work is on the order of 10
seconds.

P.

On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net> wrote:
> Could be...   It would be interesting to see whether GEOS is faster than
> JTS.   Needs a test environment able to run both pieces of code on the same
> hardware.
>
> Paul Ramsey wrote:
>>
>> I got another run in, right near the end, and it showed that
>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>> would be as fast as JTS (or faster?).
>>
>> P.
>>
>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>>
>>>
>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>> got the first 10% or so of the run, and the biggest user in that time
>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>> amount of time just accumulating the input...
>>>
>>> P
>>>
>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>> time to see where our time goes...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>> wrote:
>>>>
>>>>>
>>>>> Go for it, Regina!  The glove is dropped...
>>>>>
>>>>> Although I suspect this test may simply be running into the slower
>>>>> memory
>>>>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>
>>>>> Obe, Regina wrote:
>>>>>
>>>>>>
>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>> retest on mine.
>>>>>>
>>>>>> So I think we still need work here.
>>>>>>
>>>>>> I'm curious what would happen if I combined the algorithm I wrote with
>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>> the
>>>>>> letter.
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>> Paul
>>>>>> Ramsey
>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>> To: PostGIS Development Discussion
>>>>>> Cc: lee.keel at uai.com
>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>
>>>>>> Using the original sample set from Lee Keel,
>>>>>>
>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>
>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>     st_area
>>>>>> --------------------
>>>>>>  0.0324039850011104
>>>>>> (1 row)
>>>>>>
>>>>>> Time: 12419261.819 ms
>>>>>>
>>>>>>
>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>> faster.
>>>>>>
>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>     st_area
>>>>>> --------------------
>>>>>>  0.0324039850054305
>>>>>> (1 row)
>>>>>>
>>>>>> Time: 271618.181 ms
>>>>>>
>>>>>>
>>>>>> That's one nasty data set.
>>>>>>
>>>>>> P.
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>> -----------------------------------------
>>>>>> The substance of this message, including any attachments, may be
>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>> pursuant to Massachusetts law. It is intended
>>>>>> solely for the addressee. If you received this in error, please
>>>>>> contact the sender and delete the material from any computer.
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Martin Davis
>>>>> Senior Technical Architect
>>>>> Refractions Research, Inc.
>>>>> (250) 383-3022
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at cleverelephant.ca  Wed Jan 21 11:36:33 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 11:36:33 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
	<4977652E.70101@refractions.net>
	<30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>
Message-ID: <30fe546d0901211136o8d6e4bdmb5c4d5994c046bab@mail.gmail.com>

Scuse,

takes *261* of the 271 seconds the union operation took... the
implication is that the GEOS portion of the work is on the order of 10
seconds.


On Wed, Jan 21, 2009 at 10:58 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Well, just running this:
>
> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>  geometrytype
> --------------------
>  GEOMETRYCOLLECTION
> (1 row)
>
> Time: 261624.195 ms
>
> takes 251 of the 271 seconds the union operation took... the
> implication is that the GEOS portion of the work is on the order of 10
> seconds.
>
> P.
>
> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net> wrote:
>> Could be...   It would be interesting to see whether GEOS is faster than
>> JTS.   Needs a test environment able to run both pieces of code on the same
>> hardware.
>>
>> Paul Ramsey wrote:
>>>
>>> I got another run in, right near the end, and it showed that
>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>> would be as fast as JTS (or faster?).
>>>
>>> P.
>>>
>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>> got the first 10% or so of the run, and the biggest user in that time
>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>> amount of time just accumulating the input...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>> time to see where our time goes...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>
>>>>>> Although I suspect this test may simply be running into the slower
>>>>>> memory
>>>>>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>
>>>>>> Obe, Regina wrote:
>>>>>>
>>>>>>>
>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>> retest on mine.
>>>>>>>
>>>>>>> So I think we still need work here.
>>>>>>>
>>>>>>> I'm curious what would happen if I combined the algorithm I wrote with
>>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>> the
>>>>>>> letter.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>> Paul
>>>>>>> Ramsey
>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>> To: PostGIS Development Discussion
>>>>>>> Cc: lee.keel at uai.com
>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>
>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>
>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850011104
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 12419261.819 ms
>>>>>>>
>>>>>>>
>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>> faster.
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850054305
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 271618.181 ms
>>>>>>>
>>>>>>>
>>>>>>> That's one nasty data set.
>>>>>>>
>>>>>>> P.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>> -----------------------------------------
>>>>>>> The substance of this message, including any attachments, may be
>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>> contact the sender and delete the material from any computer.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Davis
>>>>>> Senior Technical Architect
>>>>>> Refractions Research, Inc.
>>>>>> (250) 383-3022
>>>>>>
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>


From robe.dnd at cityofboston.gov  Wed Jan 21 11:43:59 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 14:43:59 -0500
Subject: [postgis-devel] Another Data Point
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com><30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com><4977652E.70101@refractions.net>
	<30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>

Paul,
I wouldn't proclaim victory on that alone.  

Do another test.  20 seconds sounds a little too short.  
I'm not saying it isn't right and my memory may be wrong on the JTS result too.
Besides JTS would have to collect geometries as well I imagine so you can't simply throw that out and proclaim victory.


Test out

SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM sample_poly)))

Though that wouldn't be quite a true test either. But somewhere between the
two would be the answer.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Wed 1/21/2009 1:58 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point
 
Well, just running this:

uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
  geometrytype
--------------------
 GEOMETRYCOLLECTION
(1 row)

Time: 261624.195 ms

takes 251 of the 271 seconds the union operation took... the
implication is that the GEOS portion of the work is on the order of 10
seconds.

P.

On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net> wrote:
> Could be...   It would be interesting to see whether GEOS is faster than
> JTS.   Needs a test environment able to run both pieces of code on the same
> hardware.
>
> Paul Ramsey wrote:
>>
>> I got another run in, right near the end, and it showed that
>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>> would be as fast as JTS (or faster?).
>>
>> P.
>>
>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>>
>>>
>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>> got the first 10% or so of the run, and the biggest user in that time
>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>> amount of time just accumulating the input...
>>>
>>> P
>>>
>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>> time to see where our time goes...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>> wrote:
>>>>
>>>>>
>>>>> Go for it, Regina!  The glove is dropped...
>>>>>
>>>>> Although I suspect this test may simply be running into the slower
>>>>> memory
>>>>> performance due to any or all of Postgres, C, GEOS compared to good ol'
>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>
>>>>> Obe, Regina wrote:
>>>>>
>>>>>>
>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>> retest on mine.
>>>>>>
>>>>>> So I think we still need work here.
>>>>>>
>>>>>> I'm curious what would happen if I combined the algorithm I wrote with
>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>> the
>>>>>> letter.
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>> Paul
>>>>>> Ramsey
>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>> To: PostGIS Development Discussion
>>>>>> Cc: lee.keel at uai.com
>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>
>>>>>> Using the original sample set from Lee Keel,
>>>>>>
>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>
>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>     st_area
>>>>>> --------------------
>>>>>>  0.0324039850011104
>>>>>> (1 row)
>>>>>>
>>>>>> Time: 12419261.819 ms
>>>>>>
>>>>>>
>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>> faster.
>>>>>>
>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>     st_area
>>>>>> --------------------
>>>>>>  0.0324039850054305
>>>>>> (1 row)
>>>>>>
>>>>>> Time: 271618.181 ms
>>>>>>
>>>>>>
>>>>>> That's one nasty data set.
>>>>>>
>>>>>> P.
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>> -----------------------------------------
>>>>>> The substance of this message, including any attachments, may be
>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>> pursuant to Massachusetts law. It is intended
>>>>>> solely for the addressee. If you received this in error, please
>>>>>> contact the sender and delete the material from any computer.
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Martin Davis
>>>>> Senior Technical Architect
>>>>> Refractions Research, Inc.
>>>>> (250) 383-3022
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/0e9beab5/attachment.html>

From pramsey at cleverelephant.ca  Wed Jan 21 11:47:07 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 11:47:07 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <d2f53e190901211018r2bbf82dube8311821c44da6b@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>
	<d2f53e190901211018r2bbf82dube8311821c44da6b@mail.gmail.com>
Message-ID: <30fe546d0901211147w2d0fa09ahee2350018c06ee20@mail.gmail.com>

Is that only coming in 8.4? I see a patch from Stephen Frost from 2006
that does that. I see the code in CVS head too... it's exactly what I
was thinking: build the result off to the side in a memory context
instead of passing it around all the time.

I guess a quick'n'dirty test is to build 8.4, load PostGIS and see how
much the new array_agg outperforms our existing collect(). If the
answer is "a lot", then steal the new code into our tree, so we can
support older pgsql versions.

P

On Wed, Jan 21, 2009 at 10:18 AM, David William Bitner
<david.bitner at gmail.com> wrote:
> Would any of the 8.4 implementation of the generic array_agg() function be
> applicable to this?
>
> On Wed, Jan 21, 2009 at 11:10 AM, Obe, Regina <robe.dnd at cityofboston.gov>
> wrote:
>>
>> That is not surprising.  I think much of the benefit of my code was
>> spoon feeding to postgis so sort of acting as a memory manager within
>> the PostgreSQL context and my arrays were much smaller -- never ended up
>> with a single array of yeh big as I recall.  Though its been a while
>> since I have looked.
>>
>> Anyrate I'll retest in the next day or so against 3.1.   I would be
>> curious to see the results.
>>
>> Yes accumulation when you get in the 1000s is non-trivial because
>> PostgreSQL has to resize the array.
>>
>> Which is why a construct such as
>>
>> ARRAY(SELECT the_geom FROM sometable)
>>
>> is faster than
>>
>> SELECT ST_Accum(the_geom)
>> FROM sometable
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Wednesday, January 21, 2009 12:05 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Another Data Point
>>
>> Interesting! The Shark only samples for about 20 seconds, so I only
>> got the first 10% or so of the run, and the biggest user in that time
>> period memcpy'ing in LWGEOM_accum (postgis) and
>> advance_transition_function (pgsql). So we are spending a non-trivial
>> amount of time just accumulating the input...
>>
>> P
>>
>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>> > The glove is dropped indeed... why speculate when I have the Shark...
>> > time to see where our time goes...
>> >
>> > P
>> >
>> > On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
>> <mbdavis at refractions.net> wrote:
>> >> Go for it, Regina!  The glove is dropped...
>> >>
>> >> Although I suspect this test may simply be running into the slower
>> memory
>> >> performance due to any or all of Postgres, C, GEOS compared to good
>> ol'
>> >> Java...  Hard to beat that tuned JVM memory manager!
>> >>
>> >> Obe, Regina wrote:
>> >>>
>> >>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>> >>> version was able to beat out Kevin's nested by a small margin.  I'll
>> >>> retest on mine.
>> >>>
>> >>> So I think we still need work here.
>> >>>
>> >>> I'm curious what would happen if I combined the algorithm I wrote
>> with
>> >>> the new ST_Union how things would fair.  In theory it should fair
>> the
>> >>> same, but I'm not really using Martin's cascaded union algorithm to
>> the
>> >>> letter.
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: postgis-devel-bounces at postgis.refractions.net
>> >>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>> Paul
>> >>> Ramsey
>> >>> Sent: Wednesday, January 21, 2009 12:50 AM
>> >>> To: PostGIS Development Discussion
>> >>> Cc: lee.keel at uai.com
>> >>> Subject: [postgis-devel] Another Data Point
>> >>>
>> >>> Using the original sample set from Lee Keel,
>> >>>
>> >>> With the old style ST_Union, 3 hours, 27 minutes:
>> >>>
>> >>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>> >>>      st_area
>> >>> --------------------
>> >>>  0.0324039850011104
>> >>> (1 row)
>> >>>
>> >>> Time: 12419261.819 ms
>> >>>
>> >>>
>> >>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>> >>> faster.
>> >>>
>> >>> uniontest=# select st_area(st_union_fast(the_geom)) from
>> sample_poly;
>> >>>      st_area
>> >>> --------------------
>> >>>  0.0324039850054305
>> >>> (1 row)
>> >>>
>> >>> Time: 271618.181 ms
>> >>>
>> >>>
>> >>> That's one nasty data set.
>> >>>
>> >>> P.
>> >>> _______________________________________________
>> >>> postgis-devel mailing list
>> >>> postgis-devel at postgis.refractions.net
>> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> >>> -----------------------------------------
>> >>> The substance of this message, including any attachments, may be
>> >>> confidential, legally privileged and/or exempt from disclosure
>> >>> pursuant to Massachusetts law. It is intended
>> >>> solely for the addressee. If you received this in error, please
>> >>> contact the sender and delete the material from any computer.
>> >>> _______________________________________________
>> >>> postgis-devel mailing list
>> >>> postgis-devel at postgis.refractions.net
>> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> >>>
>> >>>
>> >>
>> >> --
>> >> Martin Davis
>> >> Senior Technical Architect
>> >> Refractions Research, Inc.
>> >> (250) 383-3022
>> >>
>> >> _______________________________________________
>> >> postgis-devel mailing list
>> >> postgis-devel at postgis.refractions.net
>> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> >>
>> >
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> --
> ************************************
> David William Bitner
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From pramsey at cleverelephant.ca  Wed Jan 21 11:50:55 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 11:50:55 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
	<4977652E.70101@refractions.net>
	<30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com>

Now can I do my little dance?

uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
the_geom FROM sample_poly)));
 geometrytype
--------------
 MULTIPOLYGON
(1 row)

Time: 24122.901 ms
uniontest=#



On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
> I wouldn't proclaim victory on that alone.
>
> Do another test.  20 seconds sounds a little too short.
> I'm not saying it isn't right and my memory may be wrong on the JTS result
> too.
> Besides JTS would have to collect geometries as well I imagine so you can't
> simply throw that out and proclaim victory.
>
>
> Test out
>
> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
> sample_poly)))
>
> Though that wouldn't be quite a true test either. But somewhere between the
> two would be the answer.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Wed 1/21/2009 1:58 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Well, just running this:
>
> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>   geometrytype
> --------------------
>  GEOMETRYCOLLECTION
> (1 row)
>
> Time: 261624.195 ms
>
> takes 251 of the 271 seconds the union operation took... the
> implication is that the GEOS portion of the work is on the order of 10
> seconds.
>
> P.
>
> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
> wrote:
>> Could be...   It would be interesting to see whether GEOS is faster than
>> JTS.   Needs a test environment able to run both pieces of code on the
>> same
>> hardware.
>>
>> Paul Ramsey wrote:
>>>
>>> I got another run in, right near the end, and it showed that
>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>> would be as fast as JTS (or faster?).
>>>
>>> P.
>>>
>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>> got the first 10% or so of the run, and the biggest user in that time
>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>> amount of time just accumulating the input...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>> time to see where our time goes...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>
>>>>>> Although I suspect this test may simply be running into the slower
>>>>>> memory
>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>> ol'
>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>
>>>>>> Obe, Regina wrote:
>>>>>>
>>>>>>>
>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>> retest on mine.
>>>>>>>
>>>>>>> So I think we still need work here.
>>>>>>>
>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>> with
>>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>> the
>>>>>>> letter.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>> Paul
>>>>>>> Ramsey
>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>> To: PostGIS Development Discussion
>>>>>>> Cc: lee.keel at uai.com
>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>
>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>
>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850011104
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 12419261.819 ms
>>>>>>>
>>>>>>>
>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>> faster.
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850054305
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 271618.181 ms
>>>>>>>
>>>>>>>
>>>>>>> That's one nasty data set.
>>>>>>>
>>>>>>> P.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>> -----------------------------------------
>>>>>>> The substance of this message, including any attachments, may be
>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>> contact the sender and delete the material from any computer.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Davis
>>>>>> Senior Technical Architect
>>>>>> Refractions Research, Inc.
>>>>>> (250) 383-3022
>>>>>>
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ________________________________
>
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant to
> Massachusetts law. It is intended solely for the addressee. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From robe.dnd at cityofboston.gov  Wed Jan 21 11:53:11 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 14:53:11 -0500
Subject: [postgis-devel] Another Data Point
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com><30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com><4977652E.70101@refractions.net><30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>
	<30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F118@ZDND.DND.boston.cob>

I don't have my OpenJump available at the moment. 

Kevin or Paul you happen to have that? If not then I guess I can test tomorrow and
then Paul can do his little dance :)

Though would make more sense for Paul to do it so we are testing on the same hardware.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Wed 1/21/2009 2:50 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point
 
Now can I do my little dance?

uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
the_geom FROM sample_poly)));
 geometrytype
--------------
 MULTIPOLYGON
(1 row)

Time: 24122.901 ms
uniontest=#



On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
> I wouldn't proclaim victory on that alone.
>
> Do another test.  20 seconds sounds a little too short.
> I'm not saying it isn't right and my memory may be wrong on the JTS result
> too.
> Besides JTS would have to collect geometries as well I imagine so you can't
> simply throw that out and proclaim victory.
>
>
> Test out
>
> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
> sample_poly)))
>
> Though that wouldn't be quite a true test either. But somewhere between the
> two would be the answer.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Wed 1/21/2009 1:58 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Well, just running this:
>
> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>   geometrytype
> --------------------
>  GEOMETRYCOLLECTION
> (1 row)
>
> Time: 261624.195 ms
>
> takes 251 of the 271 seconds the union operation took... the
> implication is that the GEOS portion of the work is on the order of 10
> seconds.
>
> P.
>
> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
> wrote:
>> Could be...   It would be interesting to see whether GEOS is faster than
>> JTS.   Needs a test environment able to run both pieces of code on the
>> same
>> hardware.
>>
>> Paul Ramsey wrote:
>>>
>>> I got another run in, right near the end, and it showed that
>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>> would be as fast as JTS (or faster?).
>>>
>>> P.
>>>
>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>>
>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>> got the first 10% or so of the run, and the biggest user in that time
>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>> amount of time just accumulating the input...
>>>>
>>>> P
>>>>
>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>> time to see where our time goes...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>
>>>>>> Although I suspect this test may simply be running into the slower
>>>>>> memory
>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>> ol'
>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>
>>>>>> Obe, Regina wrote:
>>>>>>
>>>>>>>
>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>> retest on mine.
>>>>>>>
>>>>>>> So I think we still need work here.
>>>>>>>
>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>> with
>>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>> the
>>>>>>> letter.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>> Paul
>>>>>>> Ramsey
>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>> To: PostGIS Development Discussion
>>>>>>> Cc: lee.keel at uai.com
>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>
>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>
>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850011104
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 12419261.819 ms
>>>>>>>
>>>>>>>
>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>> faster.
>>>>>>>
>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>>     st_area
>>>>>>> --------------------
>>>>>>>  0.0324039850054305
>>>>>>> (1 row)
>>>>>>>
>>>>>>> Time: 271618.181 ms
>>>>>>>
>>>>>>>
>>>>>>> That's one nasty data set.
>>>>>>>
>>>>>>> P.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>> -----------------------------------------
>>>>>>> The substance of this message, including any attachments, may be
>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>> contact the sender and delete the material from any computer.
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Davis
>>>>>> Senior Technical Architect
>>>>>> Refractions Research, Inc.
>>>>>> (250) 383-3022
>>>>>>
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel at postgis.refractions.net
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ________________________________
>
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant to
> Massachusetts law. It is intended solely for the addressee. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/30ffdd02/attachment.html>

From pramsey at cleverelephant.ca  Wed Jan 21 12:03:09 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 21 Jan 2009 12:03:09 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901211147w2d0fa09ahee2350018c06ee20@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F15B3@ZDND.DND.boston.cob>
	<d2f53e190901211018r2bbf82dube8311821c44da6b@mail.gmail.com>
	<30fe546d0901211147w2d0fa09ahee2350018c06ee20@mail.gmail.com>
Message-ID: <30fe546d0901211203x26cf283cpcd343c4918c55d1b@mail.gmail.com>

Oops, the ground shifted under our feet (to quote President Obama),
can't compile postgis-svn against postgresql-cvs right now...

P

On Wed, Jan 21, 2009 at 11:47 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Is that only coming in 8.4? I see a patch from Stephen Frost from 2006
> that does that. I see the code in CVS head too... it's exactly what I
> was thinking: build the result off to the side in a memory context
> instead of passing it around all the time.
>
> I guess a quick'n'dirty test is to build 8.4, load PostGIS and see how
> much the new array_agg outperforms our existing collect(). If the
> answer is "a lot", then steal the new code into our tree, so we can
> support older pgsql versions.
>
> P
>
> On Wed, Jan 21, 2009 at 10:18 AM, David William Bitner
> <david.bitner at gmail.com> wrote:
>> Would any of the 8.4 implementation of the generic array_agg() function be
>> applicable to this?
>>
>> On Wed, Jan 21, 2009 at 11:10 AM, Obe, Regina <robe.dnd at cityofboston.gov>
>> wrote:
>>>
>>> That is not surprising.  I think much of the benefit of my code was
>>> spoon feeding to postgis so sort of acting as a memory manager within
>>> the PostgreSQL context and my arrays were much smaller -- never ended up
>>> with a single array of yeh big as I recall.  Though its been a while
>>> since I have looked.
>>>
>>> Anyrate I'll retest in the next day or so against 3.1.   I would be
>>> curious to see the results.
>>>
>>> Yes accumulation when you get in the 1000s is non-trivial because
>>> PostgreSQL has to resize the array.
>>>
>>> Which is why a construct such as
>>>
>>> ARRAY(SELECT the_geom FROM sometable)
>>>
>>> is faster than
>>>
>>> SELECT ST_Accum(the_geom)
>>> FROM sometable
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net
>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>>> Ramsey
>>> Sent: Wednesday, January 21, 2009 12:05 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Another Data Point
>>>
>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>> got the first 10% or so of the run, and the biggest user in that time
>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>> amount of time just accumulating the input...
>>>
>>> P
>>>
>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>> > The glove is dropped indeed... why speculate when I have the Shark...
>>> > time to see where our time goes...
>>> >
>>> > P
>>> >
>>> > On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
>>> <mbdavis at refractions.net> wrote:
>>> >> Go for it, Regina!  The glove is dropped...
>>> >>
>>> >> Although I suspect this test may simply be running into the slower
>>> memory
>>> >> performance due to any or all of Postgres, C, GEOS compared to good
>>> ol'
>>> >> Java...  Hard to beat that tuned JVM memory manager!
>>> >>
>>> >> Obe, Regina wrote:
>>> >>>
>>> >>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>> >>> version was able to beat out Kevin's nested by a small margin.  I'll
>>> >>> retest on mine.
>>> >>>
>>> >>> So I think we still need work here.
>>> >>>
>>> >>> I'm curious what would happen if I combined the algorithm I wrote
>>> with
>>> >>> the new ST_Union how things would fair.  In theory it should fair
>>> the
>>> >>> same, but I'm not really using Martin's cascaded union algorithm to
>>> the
>>> >>> letter.
>>> >>>
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: postgis-devel-bounces at postgis.refractions.net
>>> >>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>> Paul
>>> >>> Ramsey
>>> >>> Sent: Wednesday, January 21, 2009 12:50 AM
>>> >>> To: PostGIS Development Discussion
>>> >>> Cc: lee.keel at uai.com
>>> >>> Subject: [postgis-devel] Another Data Point
>>> >>>
>>> >>> Using the original sample set from Lee Keel,
>>> >>>
>>> >>> With the old style ST_Union, 3 hours, 27 minutes:
>>> >>>
>>> >>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>> >>>      st_area
>>> >>> --------------------
>>> >>>  0.0324039850011104
>>> >>> (1 row)
>>> >>>
>>> >>> Time: 12419261.819 ms
>>> >>>
>>> >>>
>>> >>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>> >>> faster.
>>> >>>
>>> >>> uniontest=# select st_area(st_union_fast(the_geom)) from
>>> sample_poly;
>>> >>>      st_area
>>> >>> --------------------
>>> >>>  0.0324039850054305
>>> >>> (1 row)
>>> >>>
>>> >>> Time: 271618.181 ms
>>> >>>
>>> >>>
>>> >>> That's one nasty data set.
>>> >>>
>>> >>> P.
>>> >>> _______________________________________________
>>> >>> postgis-devel mailing list
>>> >>> postgis-devel at postgis.refractions.net
>>> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> >>> -----------------------------------------
>>> >>> The substance of this message, including any attachments, may be
>>> >>> confidential, legally privileged and/or exempt from disclosure
>>> >>> pursuant to Massachusetts law. It is intended
>>> >>> solely for the addressee. If you received this in error, please
>>> >>> contact the sender and delete the material from any computer.
>>> >>> _______________________________________________
>>> >>> postgis-devel mailing list
>>> >>> postgis-devel at postgis.refractions.net
>>> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> >>>
>>> >>>
>>> >>
>>> >> --
>>> >> Martin Davis
>>> >> Senior Technical Architect
>>> >> Refractions Research, Inc.
>>> >> (250) 383-3022
>>> >>
>>> >> _______________________________________________
>>> >> postgis-devel mailing list
>>> >> postgis-devel at postgis.refractions.net
>>> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> >>
>>> >
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> --
>> ************************************
>> David William Bitner
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>


From pramsey at opengeo.org  Wed Jan 21 12:17:30 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 21 Jan 2009 12:17:30 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F118@ZDND.DND.boston.cob>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>
	<49775370.2030907@refractions.net>
	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>
	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>
	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>
	<4977652E.70101@refractions.net>
	<30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>
	<30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F118@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901211217q263c79a4sd2396817ab023cca@mail.gmail.com>

15 seconds on OpenJump. I'll take my victories where I can get them,
this is close enough.

P

On Wed, Jan 21, 2009 at 11:53 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> I don't have my OpenJump available at the moment.
>
> Kevin or Paul you happen to have that? If not then I guess I can test
> tomorrow and
> then Paul can do his little dance :)
>
> Though would make more sense for Paul to do it so we are testing on the same
> hardware.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Wed 1/21/2009 2:50 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Now can I do my little dance?
>
> uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
> the_geom FROM sample_poly)));
>  geometrytype
> --------------
>  MULTIPOLYGON
> (1 row)
>
> Time: 24122.901 ms
> uniontest=#
>
>
>
> On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov>
> wrote:
>> Paul,
>> I wouldn't proclaim victory on that alone.
>>
>> Do another test.  20 seconds sounds a little too short.
>> I'm not saying it isn't right and my memory may be wrong on the JTS result
>> too.
>> Besides JTS would have to collect geometries as well I imagine so you
>> can't
>> simply throw that out and proclaim victory.
>>
>>
>> Test out
>>
>> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
>> sample_poly)))
>>
>> Though that wouldn't be quite a true test either. But somewhere between
>> the
>> two would be the answer.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
>> Ramsey
>> Sent: Wed 1/21/2009 1:58 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Another Data Point
>>
>> Well, just running this:
>>
>> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>>   geometrytype
>> --------------------
>>  GEOMETRYCOLLECTION
>> (1 row)
>>
>> Time: 261624.195 ms
>>
>> takes 251 of the 271 seconds the union operation took... the
>> implication is that the GEOS portion of the work is on the order of 10
>> seconds.
>>
>> P.
>>
>> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
>> wrote:
>>> Could be...   It would be interesting to see whether GEOS is faster than
>>> JTS.   Needs a test environment able to run both pieces of code on the
>>> same
>>> hardware.
>>>
>>> Paul Ramsey wrote:
>>>>
>>>> I got another run in, right near the end, and it showed that
>>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>>> would be as fast as JTS (or faster?).
>>>>
>>>> P.
>>>>
>>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>>> got the first 10% or so of the run, and the biggest user in that time
>>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>>> amount of time just accumulating the input...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey
>>>>> <pramsey at cleverelephant.ca>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>>> time to see where our time goes...
>>>>>>
>>>>>> P
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
>>>>>> <mbdavis at refractions.net>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>>
>>>>>>> Although I suspect this test may simply be running into the slower
>>>>>>> memory
>>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>>> ol'
>>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>>
>>>>>>> Obe, Regina wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>>> retest on mine.
>>>>>>>>
>>>>>>>> So I think we still need work here.
>>>>>>>>
>>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>>> with
>>>>>>>> the new ST_Union how things would fair.  In theory it should fair
>>>>>>>> the
>>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>>> the
>>>>>>>> letter.
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>>> Paul
>>>>>>>> Ramsey
>>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>>> To: PostGIS Development Discussion
>>>>>>>> Cc: lee.keel at uai.com
>>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>>
>>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>>
>>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850011104
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 12419261.819 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>>> faster.
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from
>>>>>>>> sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850054305
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 271618.181 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> That's one nasty data set.
>>>>>>>>
>>>>>>>> P.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>> -----------------------------------------
>>>>>>>> The substance of this message, including any attachments, may be
>>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>>> contact the sender and delete the material from any computer.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Martin Davis
>>>>>>> Senior Technical Architect
>>>>>>> Refractions Research, Inc.
>>>>>>> (250) 383-3022
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>> ________________________________
>>
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure pursuant to
>> Massachusetts law. It is intended solely for the addressee. If you
>> received
>> this in error, please contact the sender and delete the material from any
>> computer.
>>
>> ________________________________
>>
>> Help make the earth a greener place. If at all possible resist printing
>> this
>> email and join us in saving paper.
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ________________________________
>
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant to
> Massachusetts law. It is intended solely for the addressee. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From kneufeld at refractions.net  Wed Jan 21 12:23:49 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Wed, 21 Jan 2009 12:23:49 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B915D@ZDND.DND.boston.cob>	<49775370.2030907@refractions.net>	<30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com>	<30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com>	<30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com>	<4977652E.70101@refractions.net>	<30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob>
	<30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com>
Message-ID: <49778455.3000509@refractions.net>

Dancing, fun :)  It does sound like party stuff to me.
-- Kevin

Paul Ramsey wrote:
> Now can I do my little dance?
> 
> uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
> the_geom FROM sample_poly)));
>  geometrytype
> --------------
>  MULTIPOLYGON
> (1 row)
> 
> Time: 24122.901 ms
> uniontest=#
> 
> 
> 
> On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Paul,
>> I wouldn't proclaim victory on that alone.
>>
>> Do another test.  20 seconds sounds a little too short.
>> I'm not saying it isn't right and my memory may be wrong on the JTS result
>> too.
>> Besides JTS would have to collect geometries as well I imagine so you can't
>> simply throw that out and proclaim victory.
>>
>>
>> Test out
>>
>> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
>> sample_poly)))
>>
>> Though that wouldn't be quite a true test either. But somewhere between the
>> two would be the answer.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
>> Sent: Wed 1/21/2009 1:58 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Another Data Point
>>
>> Well, just running this:
>>
>> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>>   geometrytype
>> --------------------
>>  GEOMETRYCOLLECTION
>> (1 row)
>>
>> Time: 261624.195 ms
>>
>> takes 251 of the 271 seconds the union operation took... the
>> implication is that the GEOS portion of the work is on the order of 10
>> seconds.
>>
>> P.
>>
>> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
>> wrote:
>>> Could be...   It would be interesting to see whether GEOS is faster than
>>> JTS.   Needs a test environment able to run both pieces of code on the
>>> same
>>> hardware.
>>>
>>> Paul Ramsey wrote:
>>>> I got another run in, right near the end, and it showed that
>>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>>> would be as fast as JTS (or faster?).
>>>>
>>>> P.
>>>>
>>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>>> got the first 10% or so of the run, and the biggest user in that time
>>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>>> amount of time just accumulating the input...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>>> wrote:
>>>>>
>>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>>> time to see where our time goes...
>>>>>>
>>>>>> P
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis <mbdavis at refractions.net>
>>>>>> wrote:
>>>>>>
>>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>>
>>>>>>> Although I suspect this test may simply be running into the slower
>>>>>>> memory
>>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>>> ol'
>>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>>
>>>>>>> Obe, Regina wrote:
>>>>>>>
>>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>>> retest on mine.
>>>>>>>>
>>>>>>>> So I think we still need work here.
>>>>>>>>
>>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>>> with
>>>>>>>> the new ST_Union how things would fair.  In theory it should fair the
>>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>>> the
>>>>>>>> letter.
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>>> Paul
>>>>>>>> Ramsey
>>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>>> To: PostGIS Development Discussion
>>>>>>>> Cc: lee.keel at uai.com
>>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>>
>>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>>
>>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850011104
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 12419261.819 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>>> faster.
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850054305
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 271618.181 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> That's one nasty data set.
>>>>>>>>
>>>>>>>> P.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>> -----------------------------------------
>>>>>>>> The substance of this message, including any attachments, may be
>>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>>> contact the sender and delete the material from any computer.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Martin Davis
>>>>>>> Senior Technical Architect
>>>>>>> Refractions Research, Inc.
>>>>>>> (250) 383-3022
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>> ________________________________
>>
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure pursuant to
>> Massachusetts law. It is intended solely for the addressee. If you received
>> this in error, please contact the sender and delete the material from any
>> computer.
>>
>> ________________________________
>>
>> Help make the earth a greener place. If at all possible resist printing this
>> email and join us in saving paper.
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From robe.dnd at cityofboston.gov  Wed Jan 21 12:29:45 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Wed, 21 Jan 2009 15:29:45 -0500
Subject: [postgis-devel] Another Data Point
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com><30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com><4977652E.70101@refractions.net><30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob><30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F118@ZDND.DND.boston.cob>
	<30fe546d0901211217q263c79a4sd2396817ab023cca@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F119@ZDND.DND.boston.cob>


Okay you can dance.  I'll say its a tie so all can dance :)

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Wed 1/21/2009 3:17 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point
 
15 seconds on OpenJump. I'll take my victories where I can get them,
this is close enough.

P

On Wed, Jan 21, 2009 at 11:53 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> I don't have my OpenJump available at the moment.
>
> Kevin or Paul you happen to have that? If not then I guess I can test
> tomorrow and
> then Paul can do his little dance :)
>
> Though would make more sense for Paul to do it so we are testing on the same
> hardware.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Wed 1/21/2009 2:50 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> Now can I do my little dance?
>
> uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
> the_geom FROM sample_poly)));
>  geometrytype
> --------------
>  MULTIPOLYGON
> (1 row)
>
> Time: 24122.901 ms
> uniontest=#
>
>
>
> On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina <robe.dnd at cityofboston.gov>
> wrote:
>> Paul,
>> I wouldn't proclaim victory on that alone.
>>
>> Do another test.  20 seconds sounds a little too short.
>> I'm not saying it isn't right and my memory may be wrong on the JTS result
>> too.
>> Besides JTS would have to collect geometries as well I imagine so you
>> can't
>> simply throw that out and proclaim victory.
>>
>>
>> Test out
>>
>> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
>> sample_poly)))
>>
>> Though that wouldn't be quite a true test either. But somewhere between
>> the
>> two would be the answer.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
>> Ramsey
>> Sent: Wed 1/21/2009 1:58 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Another Data Point
>>
>> Well, just running this:
>>
>> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
>>   geometrytype
>> --------------------
>>  GEOMETRYCOLLECTION
>> (1 row)
>>
>> Time: 261624.195 ms
>>
>> takes 251 of the 271 seconds the union operation took... the
>> implication is that the GEOS portion of the work is on the order of 10
>> seconds.
>>
>> P.
>>
>> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net>
>> wrote:
>>> Could be...   It would be interesting to see whether GEOS is faster than
>>> JTS.   Needs a test environment able to run both pieces of code on the
>>> same
>>> hardware.
>>>
>>> Paul Ramsey wrote:
>>>>
>>>> I got another run in, right near the end, and it showed that
>>>> GEOSUnionCascaded took only about 50% of the time in that slice. There
>>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
>>>> would be as fast as JTS (or faster?).
>>>>
>>>> P.
>>>>
>>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
>>>> wrote:
>>>>
>>>>>
>>>>> Interesting! The Shark only samples for about 20 seconds, so I only
>>>>> got the first 10% or so of the run, and the biggest user in that time
>>>>> period memcpy'ing in LWGEOM_accum (postgis) and
>>>>> advance_transition_function (pgsql). So we are spending a non-trivial
>>>>> amount of time just accumulating the input...
>>>>>
>>>>> P
>>>>>
>>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey
>>>>> <pramsey at cleverelephant.ca>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> The glove is dropped indeed... why speculate when I have the Shark...
>>>>>> time to see where our time goes...
>>>>>>
>>>>>> P
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
>>>>>> <mbdavis at refractions.net>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Go for it, Regina!  The glove is dropped...
>>>>>>>
>>>>>>> Although I suspect this test may simply be running into the slower
>>>>>>> memory
>>>>>>> performance due to any or all of Postgres, C, GEOS compared to good
>>>>>>> ol'
>>>>>>> Java...  Hard to beat that tuned JVM memory manager!
>>>>>>>
>>>>>>> Obe, Regina wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>>>>>> version was able to beat out Kevin's nested by a small margin.  I'll
>>>>>>>> retest on mine.
>>>>>>>>
>>>>>>>> So I think we still need work here.
>>>>>>>>
>>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
>>>>>>>> with
>>>>>>>> the new ST_Union how things would fair.  In theory it should fair
>>>>>>>> the
>>>>>>>> same, but I'm not really using Martin's cascaded union algorithm to
>>>>>>>> the
>>>>>>>> letter.
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>>>>>>> Paul
>>>>>>>> Ramsey
>>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>>>>>> To: PostGIS Development Discussion
>>>>>>>> Cc: lee.keel at uai.com
>>>>>>>> Subject: [postgis-devel] Another Data Point
>>>>>>>>
>>>>>>>> Using the original sample set from Lee Keel,
>>>>>>>>
>>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850011104
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 12419261.819 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>>>>>> faster.
>>>>>>>>
>>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from
>>>>>>>> sample_poly;
>>>>>>>>     st_area
>>>>>>>> --------------------
>>>>>>>>  0.0324039850054305
>>>>>>>> (1 row)
>>>>>>>>
>>>>>>>> Time: 271618.181 ms
>>>>>>>>
>>>>>>>>
>>>>>>>> That's one nasty data set.
>>>>>>>>
>>>>>>>> P.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>> -----------------------------------------
>>>>>>>> The substance of this message, including any attachments, may be
>>>>>>>> confidential, legally privileged and/or exempt from disclosure
>>>>>>>> pursuant to Massachusetts law. It is intended
>>>>>>>> solely for the addressee. If you received this in error, please
>>>>>>>> contact the sender and delete the material from any computer.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Martin Davis
>>>>>>> Senior Technical Architect
>>>>>>> Refractions Research, Inc.
>>>>>>> (250) 383-3022
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel at postgis.refractions.net
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>> ________________________________
>>
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure pursuant to
>> Massachusetts law. It is intended solely for the addressee. If you
>> received
>> this in error, please contact the sender and delete the material from any
>> computer.
>>
>> ________________________________
>>
>> Help make the earth a greener place. If at all possible resist printing
>> this
>> email and join us in saving paper.
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ________________________________
>
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant to
> Massachusetts law. It is intended solely for the addressee. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/767018b6/attachment.html>

From codesite-noreply at google.com  Wed Jan 21 12:37:05 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 21 Jan 2009 20:37:05 +0000
Subject: [postgis-devel] Issue 101 in postgis: ST_Union on one-row table
	doesn't union
Message-ID: <0016e64418dc72e0790461041e9d@google.com>

Status: Accepted
Owner: pwramsey3

New issue 101 by pwramsey3: ST_Union on one-row table doesn't union
http://code.google.com/p/postgis/issues/detail?id=101

What steps will reproduce the problem?
1. Make a table with a single row including a multipolygon with overlapping  
parts.
2. Run ST_Union on it.



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From kneufeld at refractions.net  Wed Jan 21 14:39:08 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Wed, 21 Jan 2009 14:39:08 -0800
Subject: [postgis-devel] overlaps left
Message-ID: <4977A40C.7070006@refractions.net>

The docs said that &> returned true if the bounding boxes overlap OR is to the left of ...

That doesn't seem to be the case:
SELECT tbl1.column1, tbl2.column1,
   tbl1.column2 && tbl2.column2 AS overlaps,
   tbl1.column2 &< tbl2.column2 AS overlapsleft
FROM
   ( VALUES
	(1, 'LINESTRING( 1 2, 4 6 )'::geometry)) AS tbl1,
   ( VALUES
	(2, 'LINESTRING( 0 0, 3 3 )'::geometry)) AS tbl2;

  column1 | column1 | overlaps | overlapsleft
---------+---------+----------+--------------
        1 |       2 | t        | f
(1 row)


-- Kevin


From kneufeld at refractions.net  Wed Jan 21 14:44:09 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Wed, 21 Jan 2009 14:44:09 -0800
Subject: [postgis-devel] overlaps left
In-Reply-To: <4977A40C.7070006@refractions.net>
References: <4977A40C.7070006@refractions.net>
Message-ID: <4977A539.8070602@refractions.net>

Typo.. that was &<

Kevin Neufeld wrote:
> The docs said that &> returned true if the bounding boxes overlap OR is 
> to the left of ...
> 
> That doesn't seem to be the case:
> SELECT tbl1.column1, tbl2.column1,
>   tbl1.column2 && tbl2.column2 AS overlaps,
>   tbl1.column2 &< tbl2.column2 AS overlapsleft
> FROM
>   ( VALUES
>     (1, 'LINESTRING( 1 2, 4 6 )'::geometry)) AS tbl1,
>   ( VALUES
>     (2, 'LINESTRING( 0 0, 3 3 )'::geometry)) AS tbl2;
> 
>  column1 | column1 | overlaps | overlapsleft
> ---------+---------+----------+--------------
>        1 |       2 | t        | f
> (1 row)
> 
> 
> -- Kevin
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From kneufeld at refractions.net  Wed Jan 21 15:00:18 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Wed, 21 Jan 2009 15:00:18 -0800
Subject: [postgis-devel] overlaps left
In-Reply-To: <4977A539.8070602@refractions.net>
References: <4977A40C.7070006@refractions.net>
	<4977A539.8070602@refractions.net>
Message-ID: <4977A902.4010206@refractions.net>

OK, I think what this should be saying is that &< returns true if it overlaps or is NOT to the right of ...

Kevin Neufeld wrote:
> Typo.. that was &<
> 
> Kevin Neufeld wrote:
>> The docs said that &> returned true if the bounding boxes overlap OR 
>> is to the left of ...
>>
>> That doesn't seem to be the case:
>> SELECT tbl1.column1, tbl2.column1,
>>   tbl1.column2 && tbl2.column2 AS overlaps,
>>   tbl1.column2 &< tbl2.column2 AS overlapsleft
>> FROM
>>   ( VALUES
>>     (1, 'LINESTRING( 1 2, 4 6 )'::geometry)) AS tbl1,
>>   ( VALUES
>>     (2, 'LINESTRING( 0 0, 3 3 )'::geometry)) AS tbl2;
>>
>>  column1 | column1 | overlaps | overlapsleft
>> ---------+---------+----------+--------------
>>        1 |       2 | t        | f
>> (1 row)
>>
>>
>> -- Kevin
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From mbdavis at refractions.net  Wed Jan 21 16:18:23 2009
From: mbdavis at refractions.net (Martin Davis)
Date: Wed, 21 Jan 2009 16:18:23 -0800
Subject: [postgis-devel] Another Data Point
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F119@ZDND.DND.boston.cob>
References: <30fe546d0901202149q2f085fd4w5bc99bd0e2438089@mail.gmail.com><49775370.2030907@refractions.net><30fe546d0901210900t36a36e06oe54e2ee9cfa2174e@mail.gmail.com><30fe546d0901210905r77aac47dl4b1132aba286765e@mail.gmail.com><30fe546d0901210913x37f2397dl821200bb0edfbd67@mail.gmail.com><4977652E.70101@refractions.net><30fe546d0901211058s1a56a96aq9811e9026febc4ea@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F117@ZDND.DND.boston.cob><30fe546d0901211150o68e23edel797dd38d09df856e@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D204D7F118@ZDND.DND.boston.cob>	<30fe546d0901211217q263c79a4sd2396817ab023cca@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F119@ZDND.DND.boston.cob>
Message-ID: <4977BB4F.8060502@refractions.net>

I'm dancing! 

Obe, Regina wrote:
>
> Okay you can dance.  I'll say its a tie so all can dance :)
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul 
> Ramsey
> Sent: Wed 1/21/2009 3:17 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Another Data Point
>
> 15 seconds on OpenJump. I'll take my victories where I can get them,
> this is close enough.
>
> P
>
> On Wed, Jan 21, 2009 at 11:53 AM, Obe, Regina 
> <robe.dnd at cityofboston.gov> wrote:
> > I don't have my OpenJump available at the moment.
> >
> > Kevin or Paul you happen to have that? If not then I guess I can test
> > tomorrow and
> > then Paul can do his little dance :)
> >
> > Though would make more sense for Paul to do it so we are testing on 
> the same
> > hardware.
> >
> >
> > -----Original Message-----
> > From: postgis-devel-bounces at postgis.refractions.net on behalf of 
> Paul Ramsey
> > Sent: Wed 1/21/2009 2:50 PM
> > To: PostGIS Development Discussion
> > Subject: Re: [postgis-devel] Another Data Point
> >
> > Now can I do my little dance?
> >
> > uniontest=# SELECT geometrytype(_unite_garray_fast(ARRAY(SELECT
> > the_geom FROM sample_poly)));
> >  geometrytype
> > --------------
> >  MULTIPOLYGON
> > (1 row)
> >
> > Time: 24122.901 ms
> > uniontest=#
> >
> >
> >
> > On Wed, Jan 21, 2009 at 11:43 AM, Obe, Regina 
> <robe.dnd at cityofboston.gov>
> > wrote:
> >> Paul,
> >> I wouldn't proclaim victory on that alone.
> >>
> >> Do another test.  20 seconds sounds a little too short.
> >> I'm not saying it isn't right and my memory may be wrong on the JTS 
> result
> >> too.
> >> Besides JTS would have to collect geometries as well I imagine so you
> >> can't
> >> simply throw that out and proclaim victory.
> >>
> >>
> >> Test out
> >>
> >> SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM
> >> sample_poly)))
> >>
> >> Though that wouldn't be quite a true test either. But somewhere between
> >> the
> >> two would be the answer.
> >>
> >>
> >> -----Original Message-----
> >> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
> >> Ramsey
> >> Sent: Wed 1/21/2009 1:58 PM
> >> To: PostGIS Development Discussion
> >> Subject: Re: [postgis-devel] Another Data Point
> >>
> >> Well, just running this:
> >>
> >> uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
> >>   geometrytype
> >> --------------------
> >>  GEOMETRYCOLLECTION
> >> (1 row)
> >>
> >> Time: 261624.195 ms
> >>
> >> takes 251 of the 271 seconds the union operation took... the
> >> implication is that the GEOS portion of the work is on the order of 10
> >> seconds.
> >>
> >> P.
> >>
> >> On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis 
> <mbdavis at refractions.net>
> >> wrote:
> >>> Could be...   It would be interesting to see whether GEOS is 
> faster than
> >>> JTS.   Needs a test environment able to run both pieces of code on the
> >>> same
> >>> hardware.
> >>>
> >>> Paul Ramsey wrote:
> >>>>
> >>>> I got another run in, right near the end, and it showed that
> >>>> GEOSUnionCascaded took only about 50% of the time in that slice. 
> There
> >>>> was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
> >>>> would be as fast as JTS (or faster?).
> >>>>
> >>>> P.
> >>>>
> >>>> On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey 
> <pramsey at cleverelephant.ca>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> Interesting! The Shark only samples for about 20 seconds, so I only
> >>>>> got the first 10% or so of the run, and the biggest user in that 
> time
> >>>>> period memcpy'ing in LWGEOM_accum (postgis) and
> >>>>> advance_transition_function (pgsql). So we are spending a 
> non-trivial
> >>>>> amount of time just accumulating the input...
> >>>>>
> >>>>> P
> >>>>>
> >>>>> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey
> >>>>> <pramsey at cleverelephant.ca>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> The glove is dropped indeed... why speculate when I have the 
> Shark...
> >>>>>> time to see where our time goes...
> >>>>>>
> >>>>>> P
> >>>>>>
> >>>>>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
> >>>>>> <mbdavis at refractions.net>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Go for it, Regina!  The glove is dropped...
> >>>>>>>
> >>>>>>> Although I suspect this test may simply be running into the slower
> >>>>>>> memory
> >>>>>>> performance due to any or all of Postgres, C, GEOS compared to 
> good
> >>>>>>> ol'
> >>>>>>> Java...  Hard to beat that tuned JVM memory manager!
> >>>>>>>
> >>>>>>> Obe, Regina wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Ah I think JTS was able to do this in about 40-50 seconds.  
> And my
> >>>>>>>> version was able to beat out Kevin's nested by a small 
> margin.  I'll
> >>>>>>>> retest on mine.
> >>>>>>>>
> >>>>>>>> So I think we still need work here.
> >>>>>>>>
> >>>>>>>> I'm curious what would happen if I combined the algorithm I wrote
> >>>>>>>> with
> >>>>>>>> the new ST_Union how things would fair.  In theory it should fair
> >>>>>>>> the
> >>>>>>>> same, but I'm not really using Martin's cascaded union 
> algorithm to
> >>>>>>>> the
> >>>>>>>> letter.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: postgis-devel-bounces at postgis.refractions.net
> >>>>>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> Behalf Of
> >>>>>>>> Paul
> >>>>>>>> Ramsey
> >>>>>>>> Sent: Wednesday, January 21, 2009 12:50 AM
> >>>>>>>> To: PostGIS Development Discussion
> >>>>>>>> Cc: lee.keel at uai.com
> >>>>>>>> Subject: [postgis-devel] Another Data Point
> >>>>>>>>
> >>>>>>>> Using the original sample set from Lee Keel,
> >>>>>>>>
> >>>>>>>> With the old style ST_Union, 3 hours, 27 minutes:
> >>>>>>>>
> >>>>>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
> >>>>>>>>     st_area
> >>>>>>>> --------------------
> >>>>>>>>  0.0324039850011104
> >>>>>>>> (1 row)
> >>>>>>>>
> >>>>>>>> Time: 12419261.819 ms
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 
> times
> >>>>>>>> faster.
> >>>>>>>>
> >>>>>>>> uniontest=# select st_area(st_union_fast(the_geom)) from
> >>>>>>>> sample_poly;
> >>>>>>>>     st_area
> >>>>>>>> --------------------
> >>>>>>>>  0.0324039850054305
> >>>>>>>> (1 row)
> >>>>>>>>
> >>>>>>>> Time: 271618.181 ms
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> That's one nasty data set.
> >>>>>>>>
> >>>>>>>> P.
> >>>>>>>> _______________________________________________
> >>>>>>>> postgis-devel mailing list
> >>>>>>>> postgis-devel at postgis.refractions.net
> >>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>>>> -----------------------------------------
> >>>>>>>> The substance of this message, including any attachments, may be
> >>>>>>>> confidential, legally privileged and/or exempt from disclosure
> >>>>>>>> pursuant to Massachusetts law. It is intended
> >>>>>>>> solely for the addressee. If you received this in error, please
> >>>>>>>> contact the sender and delete the material from any computer.
> >>>>>>>> _______________________________________________
> >>>>>>>> postgis-devel mailing list
> >>>>>>>> postgis-devel at postgis.refractions.net
> >>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Martin Davis
> >>>>>>> Senior Technical Architect
> >>>>>>> Refractions Research, Inc.
> >>>>>>> (250) 383-3022
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> postgis-devel mailing list
> >>>>>>> postgis-devel at postgis.refractions.net
> >>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>>>
> >>>>>>>
> >>>>
> >>>> _______________________________________________
> >>>> postgis-devel mailing list
> >>>> postgis-devel at postgis.refractions.net
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>
> >>>>
> >>>
> >>> --
> >>> Martin Davis
> >>> Senior Technical Architect
> >>> Refractions Research, Inc.
> >>> (250) 383-3022
> >>>
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >> ________________________________
> >>
> >> The substance of this message, including any attachments, may be
> >> confidential, legally privileged and/or exempt from disclosure 
> pursuant to
> >> Massachusetts law. It is intended solely for the addressee. If you
> >> received
> >> this in error, please contact the sender and delete the material 
> from any
> >> computer.
> >>
> >> ________________________________
> >>
> >> Help make the earth a greener place. If at all possible resist printing
> >> this
> >> email and join us in saving paper.
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> > ________________________________
> >
> > The substance of this message, including any attachments, may be
> > confidential, legally privileged and/or exempt from disclosure 
> pursuant to
> > Massachusetts law. It is intended solely for the addressee. If you 
> received
> > this in error, please contact the sender and delete the material 
> from any
> > computer.
> >
> > ________________________________
> >
> > Help make the earth a greener place. If at all possible resist 
> printing this
> > email and join us in saving paper.
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> ------------------------------------------------------------------------
>
> *The substance of this message, including any attachments, may be 
> confidential, legally privileged and/or exempt from disclosure 
> pursuant to Massachusetts law. It is intended solely for the 
> addressee. If you received this in error, please contact the sender 
> and delete the material from any computer. *
>
> ------------------------------------------------------------------------
>
> * Help make the earth a greener place. If at all possible resist 
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022



From pramsey at opengeo.org  Wed Jan 21 16:44:47 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 21 Jan 2009 16:44:47 -0800
Subject: [postgis-devel] Faster Accum
Message-ID: <30fe546d0901211644q3105b858v7812298a06586de4@mail.gmail.com>

I've started on bringing the 8.4 array_agg back into our tree. Oddly,
the code for much of it exists in the postgresql tree already, back to
8.0, so the amount of in our tree is fairly slight.  Unfortunately,
because the idea is to pass an internal pointer around, and CREATE
AGGREGATE doesn't like that, there's some updating of system tables
required to fully hook it up.

It's called ST_GeometryArray(), have a look.

P.


From pramsey at opengeo.org  Wed Jan 21 17:11:05 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 21 Jan 2009 17:11:05 -0800
Subject: [postgis-devel] Aligned Speed
Message-ID: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>

I did up a little test program to see if I could determine the extra
performance around aligned access of *double. Not sure I'm seeing
anything, but it could be my test is bogus.

P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aligned-read.c
Type: application/octet-stream
Size: 1070 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/119c6088/attachment.obj>

From pramsey at opengeo.org  Wed Jan 21 21:01:32 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 21 Jan 2009 21:01:32 -0800
Subject: [postgis-devel] Try before you Buy
Message-ID: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>

All the pieces of the new super-fast cascaded geometry are now in SVN.
You'll need an absolutely fresh copy of GEOS to use them, but once you
do, you can run something like this:

aggtest=# select
geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
sample_poly;
       geometrytype --------------
 MULTIPOLYGON
(1 row)
Time: 23267.905 ms


note that
 st_union() is still bound against the oldest implementation
 st_union_fast() is bound against an implementation with slow
aggregation but fast GEOS union
 _unite_garray_fast(st_geometryarray()) is the only way to get the
ultimate speed right now

Unfortunately, it looks I'm going to need a special finalfunc for
every single aggregate that takes in the internal pointer to the
side-cache. That makes all the aggregates less pretty, since they
won't use function(geometry[]) as their finalfunc anymore. The
cleanest way would be to have those finalfuncs do little more than
call other functions.

Mark, is there a prescribed way to call postgresql functions (ones
with (PG_FUNCTION_ARGS) as the argument) from other internal
functions?

Paul


From pramsey at opengeo.org  Wed Jan 21 22:14:59 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Wed, 21 Jan 2009 22:14:59 -0800
Subject: [postgis-devel] Re: Try before you Buy
In-Reply-To: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
Message-ID: <30fe546d0901212214l61b4b27bie0bb57970cc336c5@mail.gmail.com>

On Wed, Jan 21, 2009 at 9:01 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> Mark, is there a prescribed way to call postgresql functions (ones
> with (PG_FUNCTION_ARGS) as the argument) from other internal
> functions?

Never mind, found DirectFunctionCall1, etc.

P


From bobdebm at gmail.com  Thu Jan 22 00:28:13 2009
From: bobdebm at gmail.com (Bob and Deb)
Date: Thu, 22 Jan 2009 00:28:13 -0800
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
Message-ID: <7a3148720901220028s3030262nec46c8f553fdfa3c@mail.gmail.com>

Btw, I got 15849 ms when I ran this query:

SELECT state,
  SUM(ST_NPoints(the_geom)) As  numpointsbefore,
    ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
  FROM usstatebounds
  GROUP BY state
  ORDER BY state;

I was so excited to see unioncascade that I did not adjust my test server
parameters.  Fyi, my server is on a 1.83 Ghz duo core laptop with 2 gigs of
mem running Ubuntu Hardy Heron.

This machine also has the latest postgresql, postgis, and geos installed.

GeoDB=# SELECT PostGIS_Full_Version();
                                  postgis_full_version
----------------------------------------------------------------------------------------
 POSTGIS="1.4.0SVN" GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.1, 21 August
2008" USE_STATS
(1 row)


How do I use _unite_garray_fast(st_geometryarray(the_geom)) with the
usstatebounds?


On Wed, Jan 21, 2009 at 9:01 PM, Paul Ramsey <pramsey at opengeo.org> wrote:

> All the pieces of the new super-fast cascaded geometry are now in SVN.
> You'll need an absolutely fresh copy of GEOS to use them, but once you
> do, you can run something like this:
>
> aggtest=# select
> geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
> sample_poly;
>       geometrytype --------------
>  MULTIPOLYGON
> (1 row)
> Time: 23267.905 ms
>
>
> note that
>  st_union() is still bound against the oldest implementation
>  st_union_fast() is bound against an implementation with slow
> aggregation but fast GEOS union
>  _unite_garray_fast(st_geometryarray()) is the only way to get the
> ultimate speed right now
>
> Unfortunately, it looks I'm going to need a special finalfunc for
> every single aggregate that takes in the internal pointer to the
> side-cache. That makes all the aggregates less pretty, since they
> won't use function(geometry[]) as their finalfunc anymore. The
> cleanest way would be to have those finalfuncs do little more than
> call other functions.
>
> Mark, is there a prescribed way to call postgresql functions (ones
> with (PG_FUNCTION_ARGS) as the argument) from other internal
> functions?
>
> Paul
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/7d188ffd/attachment.html>

From bobdebm at gmail.com  Thu Jan 22 00:37:21 2009
From: bobdebm at gmail.com (Bob and Deb)
Date: Thu, 22 Jan 2009 00:37:21 -0800
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <7a3148720901220028s3030262nec46c8f553fdfa3c@mail.gmail.com>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
	<7a3148720901220028s3030262nec46c8f553fdfa3c@mail.gmail.com>
Message-ID: <7a3148720901220037pdd4a9eyb8793294febdd54@mail.gmail.com>

Replying to myself :-)  I figured it out.  I used this query and got 12661
ms:

SELECT state,
  SUM(ST_NPoints(the_geom)) As  numpointsbefore,
    ST_NPoints(_unite_garray_fast(st_geometryarray(the_geom))) As
numpointsafter
  FROM usstatebounds
  GROUP BY state
  ORDER BY state;



On Thu, Jan 22, 2009 at 12:28 AM, Bob and Deb <bobdebm at gmail.com> wrote:

> Btw, I got 15849 ms when I ran this query:
>
> SELECT state,
>   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>     ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
>   FROM usstatebounds
>   GROUP BY state
>   ORDER BY state;
>
> I was so excited to see unioncascade that I did not adjust my test server
> parameters.  Fyi, my server is on a 1.83 Ghz duo core laptop with 2 gigs of
> mem running Ubuntu Hardy Heron.
>
> This machine also has the latest postgresql, postgis, and geos installed.
>
> GeoDB=# SELECT PostGIS_Full_Version();
>                                   postgis_full_version
>
> ----------------------------------------------------------------------------------------
>  POSTGIS="1.4.0SVN" GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.1, 21 August
> 2008" USE_STATS
> (1 row)
>
>
> How do I use _unite_garray_fast(st_geometryarray(the_geom)) with the
> usstatebounds?
>
>
> On Wed, Jan 21, 2009 at 9:01 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>
>> All the pieces of the new super-fast cascaded geometry are now in SVN.
>> You'll need an absolutely fresh copy of GEOS to use them, but once you
>> do, you can run something like this:
>>
>> aggtest=# select
>> geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
>> sample_poly;
>>       geometrytype --------------
>>  MULTIPOLYGON
>> (1 row)
>> Time: 23267.905 ms
>>
>>
>> note that
>>  st_union() is still bound against the oldest implementation
>>  st_union_fast() is bound against an implementation with slow
>> aggregation but fast GEOS union
>>  _unite_garray_fast(st_geometryarray()) is the only way to get the
>> ultimate speed right now
>>
>> Unfortunately, it looks I'm going to need a special finalfunc for
>> every single aggregate that takes in the internal pointer to the
>> side-cache. That makes all the aggregates less pretty, since they
>> won't use function(geometry[]) as their finalfunc anymore. The
>> cleanest way would be to have those finalfuncs do little more than
>> call other functions.
>>
>> Mark, is there a prescribed way to call postgresql functions (ones
>> with (PG_FUNCTION_ARGS) as the argument) from other internal
>> functions?
>>
>> Paul
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/8db8e8a1/attachment.html>

From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 01:37:13 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 09:37:13 +0000
Subject: [postgis-devel] Faster Accum
In-Reply-To: <30fe546d0901211644q3105b858v7812298a06586de4@mail.gmail.com>
References: <30fe546d0901211644q3105b858v7812298a06586de4@mail.gmail.com>
Message-ID: <49783E49.9010304@siriusit.co.uk>

Paul Ramsey wrote:

> I've started on bringing the 8.4 array_agg back into our tree. Oddly,
> the code for much of it exists in the postgresql tree already, back to
> 8.0, so the amount of in our tree is fairly slight. 

Awesome. Well done Paul, the results look really impressive so far...

> Unfortunately,
> because the idea is to pass an internal pointer around, and CREATE
> AGGREGATE doesn't like that, there's some updating of system tables
> required to fully hook it up.

Eeek. Changing the system catalogs in an undocumented manner like this 
is an absolute no-no. What should be happening is that we should create 
a special type for the transition function (which is essentially a 
wrapper on Datum) to hold the ArrayState and use that instead.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Thu Jan 22 01:39:56 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 09:39:56 +0000
Subject: [postgis-devel] Issue 101 in postgis: ST_Union on one-row table
	doesn't union
Message-ID: <00163691ff32221ddb04610f0e33@google.com>


Comment #1 on issue 101 by mark.cav... at siriusit.co.uk: ST_Union on one-row  
table doesn't union
http://code.google.com/p/postgis/issues/detail?id=101

Paul,

Is this a 1.4 TODO?


ATB,

Mark.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Thu Jan 22 01:43:12 2009
From: strk at keybit.net (strk)
Date: Thu, 22 Jan 2009 10:43:12 +0100
Subject: [postgis-devel] Aligned Speed
In-Reply-To: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>
References: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>
Message-ID: <20090122094312.GK33765@keybit.net>

On Wed, Jan 21, 2009 at 05:11:05PM -0800, Paul Ramsey wrote:
> I did up a little test program to see if I could determine the extra
> performance around aligned access of *double. Not sure I'm seeing
> anything, but it could be my test is bogus.

I made a similar test and haven't found major difference as well.
Next you should find a system on which that cast won't work, for
testing implications and detection of it.

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From codesite-noreply at google.com  Thu Jan 22 01:43:56 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 09:43:56 +0000
Subject: [postgis-devel] Issue 99 in postgis: shp2pgsql 'Only import DBF'
	error.
Message-ID: <001485f945a477d01a04610f1c98@google.com>


Comment #1 on issue 99 by mark.cav... at siriusit.co.uk: shp2pgsql 'Only  
import DBF' error.
http://code.google.com/p/postgis/issues/detail?id=99

Regina/Paul: any comment on this one?


ATB,

Mark.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 01:56:00 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 09:56:00 +0000
Subject: [postgis-devel] overlaps left
In-Reply-To: <4977A40C.7070006@refractions.net>
References: <4977A40C.7070006@refractions.net>
Message-ID: <497842B0.7090007@siriusit.co.uk>

Kevin Neufeld wrote:

> The docs said that &> returned true if the bounding boxes overlap OR is 
> to the left of ...
> 
> That doesn't seem to be the case:
> SELECT tbl1.column1, tbl2.column1,
>   tbl1.column2 && tbl2.column2 AS overlaps,
>   tbl1.column2 &< tbl2.column2 AS overlapsleft
> FROM
>   ( VALUES
>     (1, 'LINESTRING( 1 2, 4 6 )'::geometry)) AS tbl1,
>   ( VALUES
>     (2, 'LINESTRING( 0 0, 3 3 )'::geometry)) AS tbl2;
> 
>  column1 | column1 | overlaps | overlapsleft
> ---------+---------+----------+--------------
>        1 |       2 | t        | f
> (1 row)

Yeah... I found this when I was debugging some of the R-Tree routines 
before. The R-Tree semantics for "overlap" are defined differently than 
you or I would expect.

Here are a set of examples to try and help explain this: if you imagine 
A sliding from the right to the left across B in the X dimension then it 
should make sense.


A:              -------
B:     ------

A &< B == False


A:        ------
B:     -------

A &< B == False


A:     ------
B:     ------

A &< B == True


A:   ------
B:     ------

A &< B == True


If you think of overlap as being "directly on top of" then this may help 
too. But feel free to come up with a better definition of course.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 02:19:22 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 10:19:22 +0000
Subject: [postgis-devel] Aligned Speed
In-Reply-To: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>
References: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>
Message-ID: <4978482A.1010708@siriusit.co.uk>

Paul Ramsey wrote:

> I did up a little test program to see if I could determine the extra
> performance around aligned access of *double. Not sure I'm seeing
> anything, but it could be my test is bogus.
> 
> P

Looks reasonably sane on first inspection, although clock() seems 
useless - on here it rounds to the nearest 10000 ticks, so 
gettimeofday() would be a better choice. And even then it shows 
unaligned access being faster which is totally bogus.

There should be some measurable difference with a fast enough clock, but 
as strk points out, the main reason we wish to align is to try and avoid 
the overhead of memcpy() when accessing points in large geometries.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From codesite-noreply at google.com  Thu Jan 22 03:50:30 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 11:50:30 +0000
Subject: [postgis-devel] Issue 99 in postgis: shp2pgsql 'Only import DBF'
	error.
Message-ID: <0016e640985a156efe046110e140@google.com>


Comment #2 on issue 99 by robe.... at cityofboston.gov: shp2pgsql 'Only import  
DBF' error.
http://code.google.com/p/postgis/issues/detail?id=99

I haven't looked at it.  I can take a look later today

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From robe.dnd at cityofboston.gov  Thu Jan 22 03:55:26 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Thu, 22 Jan 2009 06:55:26 -0500
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>

Paul,

I hope we are not creating yet another aggregate function here, but I
assume you are just doing this so we can test and compare.

st_geometryarray(the_geom)

Isn't this what ST_Accum is supposed to do in which case for the final
version,  shouldn't you just replace the existing functionality of
ST_Accum rather than introducing yet another term in my already limited
brain cells?

Thanks,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Thursday, January 22, 2009 12:02 AM
To: PostGIS Development Discussion
Subject: [postgis-devel] Try before you Buy

All the pieces of the new super-fast cascaded geometry are now in SVN.
You'll need an absolutely fresh copy of GEOS to use them, but once you
do, you can run something like this:

aggtest=# select
geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
sample_poly;
       geometrytype --------------
 MULTIPOLYGON
(1 row)
Time: 23267.905 ms


note that
 st_union() is still bound against the oldest implementation
 st_union_fast() is bound against an implementation with slow
aggregation but fast GEOS union
 _unite_garray_fast(st_geometryarray()) is the only way to get the
ultimate speed right now

Unfortunately, it looks I'm going to need a special finalfunc for
every single aggregate that takes in the internal pointer to the
side-cache. That makes all the aggregates less pretty, since they
won't use function(geometry[]) as their finalfunc anymore. The
cleanest way would be to have those finalfuncs do little more than
call other functions.

Mark, is there a prescribed way to call postgresql functions (ones
with (PG_FUNCTION_ARGS) as the argument) from other internal
functions?

Paul
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 04:02:41 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 12:02:41 +0000
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
Message-ID: <49786061.3070807@siriusit.co.uk>

Obe, Regina wrote:
> Paul,
> 
> I hope we are not creating yet another aggregate function here, but I
> assume you are just doing this so we can test and compare.
> 
> st_geometryarray(the_geom)
> 
> Isn't this what ST_Accum is supposed to do in which case for the final
> version,  shouldn't you just replace the existing functionality of
> ST_Accum rather than introducing yet another term in my already limited
> brain cells?
> 
> Thanks,
> Regina 

Yeah. I assume that these are just for testing, and Paul will remove the 
old versions when he's happy...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Thu Jan 22 04:10:20 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Thu, 22 Jan 2009 07:10:20 -0500
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <49786061.3070807@siriusit.co.uk>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
	<49786061.3070807@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A4A@ZDND.DND.boston.cob>

Mark,
Yes. I wasn't sure since Paul didn't put his signature _fast at the end
of it. 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Thursday, January 22, 2009 7:03 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Try before you Buy

Obe, Regina wrote:
> Paul,
> 
> I hope we are not creating yet another aggregate function here, but I
> assume you are just doing this so we can test and compare.
> 
> st_geometryarray(the_geom)
> 
> Isn't this what ST_Accum is supposed to do in which case for the final
> version,  shouldn't you just replace the existing functionality of
> ST_Accum rather than introducing yet another term in my already
limited
> brain cells?
> 
> Thanks,
> Regina 

Yeah. I assume that these are just for testing, and Paul will remove the

old versions when he's happy...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From codesite-noreply at google.com  Thu Jan 22 07:28:36 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 15:28:36 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <0016364ed2cc192464046113edb5@google.com>


Comment #7 on issue 89 by fwarmerdam: transform() grid-shift 2nd chance  
logic defective
http://code.google.com/p/postgis/issues/detail?id=89

It is my opinion that a more appropriate location to adjust behavior is the  
+nadgrids
specification for the coordinate system.

The default +nadgrids setting for NAD27 is (with +datum=NAD27):

   +nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat

The @ prefix means no error is reported if the files are not present, but  
if the end
of the list is reached with no file having been appropriate (ie. found and
overlapping) then an error is issued.

If, conversely, you wanted to ensure that at least the standard files were  
present,
but that if all files were scanning without a hit a null transformation is  
applied
you could use:

   +nadgrids=conus,alaska, at ntv2_0.gsb,ntv1_can.dat,null

The null grid shift file is a valid grid shift file covering the whole  
world and
applying no shift.

I still feel the default behavior (report an error if no covering grid  
shift file is
found) is reasonable, but the behavior is fairly easily modified by  
changing the grid
shift string.  In the case of postgis, this could be done by replacing  
+datum=NAD27
with the above +nadgrids directive in the spatial_ref_sys table.

I'm not too keen on the patch approach.





--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Thu Jan 22 08:31:58 2009
From: strk at keybit.net (strk)
Date: Thu, 22 Jan 2009 17:31:58 +0100
Subject: [postgis-devel] Aligned Speed
In-Reply-To: <4978482A.1010708@siriusit.co.uk>
References: <30fe546d0901211711y68f1ed33j416c7b3a0e1cd867@mail.gmail.com>
	<4978482A.1010708@siriusit.co.uk>
Message-ID: <20090122163158.GP33765@keybit.net>

On Thu, Jan 22, 2009 at 10:19:22AM +0000, Mark Cave-Ayland wrote:

> There should be some measurable difference with a fast enough clock, but 
> as strk points out, the main reason we wish to align is to try and avoid 
> the overhead of memcpy() when accessing points in large geometries.

I wonder how much replacing the memcpy with bitwise ops would
speed the thing up...

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From codesite-noreply at google.com  Thu Jan 22 08:42:22 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 16:42:22 +0000
Subject: [postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd
	chance logic defective
Message-ID: <001485f945a4e3ff8c046114f49a@google.com>


Comment #8 on issue 89 by william.... at acm.org: transform() grid-shift 2nd  
chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Thanks, Frank.  I hadn't dug that deeply into proj (and thanks for all you  
do there
and on GDAL).  I can hardly do otherwise than gratefully embrace your  
analysis and
conclusion.  However ...

1. It would be really nice if proj.4 error handling clearly distinguished  
between
missing grid-shift files and transformed points outside the range for which  
the grid
shift is defined.

2. The "second chance" logic in PostGIS's lwgeom_transform.c should be  
entirely
removed.  It does not do what its comments claim, and, if it did, would  
conflict
with the approach you recommend above.

3. It would be helpful to improve PostGIS warning/error messages as I  
suggest in the
next to last paragraph of my last message above, at least to the extent  
still
relevant with your recommended approach.

I'll be happy to take a swipe at patches for items 2 and 3 above, though  
given my
limited C coding skills, it would probably be better for the PostGIS  
development
team to do so if resources are available.

-- Bill

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Thu Jan 22 09:20:49 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 17:20:49 +0000
Subject: [postgis-devel] Issue 99 in postgis: shp2pgsql 'Only import DBF'
	error.
Message-ID: <000e0cd6a77c66877d0461157ed1@google.com>


Comment #3 on issue 99 by robe.... at cityofboston.gov: shp2pgsql 'Only import  
DBF' error.
http://code.google.com/p/postgis/issues/detail?id=99

Problem I think was with the DBFReadDeleted.  I think it was doing the  
reverse of
what it was intended to do pulling in deleted records and leaving out  
non-deleted
records.  Paul can you verify my logic.  Unfortunately I don't have FoxPro  
loaded and
I only know how to mark dbf records deleted with FoxPro.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Thu Jan 22 09:24:56 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 22 Jan 2009 17:24:56 +0000
Subject: [postgis-devel] Issue 99 in postgis: shp2pgsql 'Only import DBF'
	error.
Message-ID: <00163630ee1b1ca4560461158ddb@google.com>

Updates:
	Status: Testing
	Labels: Type-Defect Milestone-1.3.X Priority-Critical

Comment #4 on issue 99 by robe.... at cityofboston.gov: shp2pgsql 'Only import  
DBF' error.
http://code.google.com/p/postgis/issues/detail?id=99

Forgot to switch to testing  status

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Thu Jan 22 09:47:56 2009
From: strk at keybit.net (strk)
Date: Thu, 22 Jan 2009 18:47:56 +0100
Subject: [postgis-devel] shapelib fixes ?
Message-ID: <20090122174756.GC74465@keybit.net>

Salve Regina!

I noticed this commit:

* r3561 /trunk/loader/dbfopen.c: Fix DBFReadDeleted logic
  -- should return 1 if record is deleted and 0 if it is not
  deleted

Note that dbfopen.c is part of Frank Warmerdam's
shapelib, copied in postgis tree verbatim and occasionally
updated to new versions.
This means that on next update your "fix" would be reverted
(unless it is in upstream, which I strongly dubt).

Generally, returning 0 for success and 1 for error is a trick
to allow for fine-grained error reporting. A success is
a success, while an error can be for different reasons, thus
the non-zero return on error.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From pramsey at cleverelephant.ca  Thu Jan 22 10:28:59 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 22 Jan 2009 10:28:59 -0800
Subject: [postgis-devel] Faster Accum
In-Reply-To: <49783E49.9010304@siriusit.co.uk>
References: <30fe546d0901211644q3105b858v7812298a06586de4@mail.gmail.com>
	<49783E49.9010304@siriusit.co.uk>
Message-ID: <C502AAA4-669A-4481-B829-EFAFA51EDDE6@cleverelephant.ca>


On Jan 22, 2009, at 1:37 AM, Mark Cave-Ayland wrote:

> Eeek. Changing the system catalogs in an undocumented manner like  
> this is an absolute no-no. What should be happening is that we  
> should create a special type for the transition function (which is  
> essentially a wrapper on Datum) to hold the ArrayState and use that  
> instead.


Done. I found that wrapping the ArrayBuildState pointer was easier in  
the end, after much banging of heads on desks (both mine).

P.

--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From robe.dnd at cityofboston.gov  Thu Jan 22 10:39:41 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Thu, 22 Jan 2009 13:39:41 -0500
Subject: [postgis-devel] RE: shapelib fixes ?
References: <20090122174756.GC74465@keybit.net>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F11C@ZDND.DND.boston.cob>

Sandro,

Good point.  I was thinking of whether it would be better to just change
the DBFReadDeleted in shp2pgsql to !DBFReadDeleted, but given the verbiage
it seemed more confusing to do that.  Then again I hate the function name altogether.  I think I spent more time figuring out what the hell does that mean than doing anything.  I would prefer IsDBFRecordDeleted.

It seems to me DBFReadDeleted is asking the question, is the record we are reading deleted (or is it if the record is Delete then don't read it, but its reading it to figure out it is deleted). It took me a while to figure out what that meant? Or at least that is what that phrase means to me.  I think IsDBFRecordDeleted or IsDBFRecordActive is clearer.  

Also I'm not sure this is not Paul's concoction because comparing to the dbfopen from the 1.3.3, this function isn't even there.  I don't have access to Frank's shapelib so can't commit changes.

Paul you didn't happen to commit this change to shapelib did you or synch from there to get this function?

Thanks,
Regina





-----Original Message-----
From: strk [mailto:strk at keybit.net]
Sent: Thu 1/22/2009 12:47 PM
To: Obe, Regina
Cc: postgis-devel at postgis.refractions.net
Subject: shapelib fixes ?
 
Salve Regina!

I noticed this commit:

* r3561 /trunk/loader/dbfopen.c: Fix DBFReadDeleted logic
  -- should return 1 if record is deleted and 0 if it is not
  deleted

Note that dbfopen.c is part of Frank Warmerdam's
shapelib, copied in postgis tree verbatim and occasionally
updated to new versions.
This means that on next update your "fix" would be reverted
(unless it is in upstream, which I strongly dubt).

Generally, returning 0 for success and 1 for error is a trick
to allow for fine-grained error reporting. A success is
a success, while an error can be for different reasons, thus
the non-zero return on error.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/971cf534/attachment.html>

From pramsey at cleverelephant.ca  Thu Jan 22 10:39:54 2009
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 22 Jan 2009 10:39:54 -0800
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
Message-ID: <6D5015F6-5E5E-4DC0-B0B4-3C5EBC222B79@cleverelephant.ca>

I'm happy to keep the names the "same" where needed, subject to my  
public/private re-naming, coming soon. (I'll send a document to the  
list for review.)

ST_Accum will have the new behavior on the next commit, ST_Accum_Old  
will have the old behavior.

P.

On Jan 22, 2009, at 3:55 AM, Obe, Regina wrote:

> Paul,
>
> I hope we are not creating yet another aggregate function here, but I
> assume you are just doing this so we can test and compare.
>
> st_geometryarray(the_geom)
>
> Isn't this what ST_Accum is supposed to do in which case for the final
> version,  shouldn't you just replace the existing functionality of
> ST_Accum rather than introducing yet another term in my already  
> limited
> brain cells?
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of  
> Paul
> Ramsey
> Sent: Thursday, January 22, 2009 12:02 AM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Try before you Buy
>
> All the pieces of the new super-fast cascaded geometry are now in SVN.
> You'll need an absolutely fresh copy of GEOS to use them, but once you
> do, you can run something like this:
>
> aggtest=# select
> geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
> sample_poly;
>       geometrytype --------------
> MULTIPOLYGON
> (1 row)
> Time: 23267.905 ms
>
>
> note that
> st_union() is still bound against the oldest implementation
> st_union_fast() is bound against an implementation with slow
> aggregation but fast GEOS union
> _unite_garray_fast(st_geometryarray()) is the only way to get the
> ultimate speed right now
>
> Unfortunately, it looks I'm going to need a special finalfunc for
> every single aggregate that takes in the internal pointer to the
> side-cache. That makes all the aggregates less pretty, since they
> won't use function(geometry[]) as their finalfunc anymore. The
> cleanest way would be to have those finalfuncs do little more than
> call other functions.
>
> Mark, is there a prescribed way to call postgresql functions (ones
> with (PG_FUNCTION_ARGS) as the argument) from other internal
> functions?
>
> Paul
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632



From robe.dnd at cityofboston.gov  Thu Jan 22 10:40:00 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Thu, 22 Jan 2009 13:40:00 -0500
Subject: [postgis-devel] Faster Accum
References: <30fe546d0901211644q3105b858v7812298a06586de4@mail.gmail.com><49783E49.9010304@siriusit.co.uk>
	<C502AAA4-669A-4481-B829-EFAFA51EDDE6@cleverelephant.ca>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F11D@ZDND.DND.boston.cob>


And how many heads do you have?

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Thu 1/22/2009 1:28 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Faster Accum
 

On Jan 22, 2009, at 1:37 AM, Mark Cave-Ayland wrote:

> Eeek. Changing the system catalogs in an undocumented manner like  
> this is an absolute no-no. What should be happening is that we  
> should create a special type for the transition function (which is  
> essentially a wrapper on Datum) to hold the ArrayState and use that  
> instead.


Done. I found that wrapping the ArrayBuildState pointer was easier in  
the end, after much banging of heads on desks (both mine).

P.

--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632

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



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/6c6cd823/attachment.html>

From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 11:39:21 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 19:39:21 +0000
Subject: [postgis-devel] Try before you Buy
In-Reply-To: <6D5015F6-5E5E-4DC0-B0B4-3C5EBC222B79@cleverelephant.ca>
References: <30fe546d0901212101n1b186d35u6b0e9fe82e1ac284@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2054F1A48@ZDND.DND.boston.cob>
	<6D5015F6-5E5E-4DC0-B0B4-3C5EBC222B79@cleverelephant.ca>
Message-ID: <4978CB69.4060600@siriusit.co.uk>

Paul Ramsey wrote:

> ST_Accum will have the new behavior on the next commit, ST_Accum_Old 
> will have the old behavior.

At this stage in the game, I would just commit the new behaviour so it 
sees more testing and remove the old. If anyone wishes to have a 
comparison point with the old behaviour, they can just use an old 1.3 
database.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From mark.cave-ayland at siriusit.co.uk  Thu Jan 22 11:41:00 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Thu, 22 Jan 2009 19:41:00 +0000
Subject: [postgis-devel] shapelib fixes ?
In-Reply-To: <20090122174756.GC74465@keybit.net>
References: <20090122174756.GC74465@keybit.net>
Message-ID: <4978CBCC.4060802@siriusit.co.uk>

strk wrote:

> Note that dbfopen.c is part of Frank Warmerdam's
> shapelib, copied in postgis tree verbatim and occasionally
> updated to new versions.
> This means that on next update your "fix" would be reverted
> (unless it is in upstream, which I strongly dubt).
> 
> Generally, returning 0 for success and 1 for error is a trick
> to allow for fine-grained error reporting. A success is
> a success, while an error can be for different reasons, thus
> the non-zero return on error.

I'd say that Regina's fix is fine for 1.3 branch as we are trying to 
minimise changes there; however it may be worth importing again from 
upstream for SVN trunk.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Thu Jan 22 15:02:28 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Thu, 22 Jan 2009 15:02:28 -0800
Subject: [postgis-devel] Aggregates
Message-ID: <30fe546d0901221502m72903fd8mea068aaddd262f2c@mail.gmail.com>

I've flipped all the aggregate functions that used to build arrays the
old way to use the new code (at r3565).

ST_MakeLine( geometry )
ST_Polygonize( geometry )
ST_Collect( geometry )
ST_Union( geometry )
ST_Accum( geometry )

These are all on the new code now. For comparison, I've left behind
two legacy implementations, that will disappear before release:

ST_Accum_old( geometry )
ST_Union_old( geometry )

I also thought that

ST_MakeLine( geometry[] )
ST_Polygonize( goemetry[] )
ST_Collect( geometry[] )
ST_Union( geometry[] )

were all more "in the spirit of PostgreSQL" so I have added them.

I will agitate for the removal of

ST_Makeline_Garray( geometry[] )
et al

later, as I build my big spreadsheet-of-doom.

Paul


From robe.dnd at cityofboston.gov  Thu Jan 22 15:10:01 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Thu, 22 Jan 2009 18:10:01 -0500
Subject: [postgis-devel] Aggregates
References: <30fe546d0901221502m72903fd8mea068aaddd262f2c@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F11E@ZDND.DND.boston.cob>

Personally if you got rid of those GArrays I'd be fine since it looks like you are introducing new versions with same functionality.

While you are building your big spreadsheet of doom.  Don't forget to add those 20 someodd functions we really want to get rid of.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Thu 1/22/2009 6:02 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Aggregates
 
I've flipped all the aggregate functions that used to build arrays the
old way to use the new code (at r3565).

ST_MakeLine( geometry )
ST_Polygonize( geometry )
ST_Collect( geometry )
ST_Union( geometry )
ST_Accum( geometry )

These are all on the new code now. For comparison, I've left behind
two legacy implementations, that will disappear before release:

ST_Accum_old( geometry )
ST_Union_old( geometry )

I also thought that

ST_MakeLine( geometry[] )
ST_Polygonize( goemetry[] )
ST_Collect( geometry[] )
ST_Union( geometry[] )

were all more "in the spirit of PostgreSQL" so I have added them.

I will agitate for the removal of

ST_Makeline_Garray( geometry[] )
et al

later, as I build my big spreadsheet-of-doom.

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



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/c0c9d6b0/attachment.html>

From robe.dnd at cityofboston.gov  Fri Jan 23 07:26:33 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 10:26:33 -0500
Subject: [postgis-devel] Compile issues on MingW trunk
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>

I tried doing a make clean and 

sh autogen.sh

on MingW and I'm getting this on autogen and not sure what it means

/usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
AG_PATH_AUTOOPTS
  run info '(automake)Extending aclocal'
  or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
Can't locate object method "path" via package "Request" (perhaps you
forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm line
69, <GEN1> line 111.
aclocal: autom4te failed with exit status: 127
Can't locate object method "path" via package "Request" (perhaps you
forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm line
69, <GEN1> line 111.

Thanks,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Fri Jan 23 07:42:29 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 23 Jan 2009 15:42:29 +0000
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
Message-ID: <4979E565.3000901@siriusit.co.uk>

Obe, Regina wrote:

> I tried doing a make clean and 
> 
> sh autogen.sh
> 
> on MingW and I'm getting this on autogen and not sure what it means
> 
> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
> AG_PATH_AUTOOPTS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm line
> 69, <GEN1> line 111.
> aclocal: autom4te failed with exit status: 127
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm line
> 69, <GEN1> line 111.
> 
> Thanks,
> Regina

Hi Regina,

What if you run autogen.sh on your SuSE box to generate configure and 
transfer the resulting file across? Does it work then?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Fri Jan 23 08:02:32 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 11:02:32 -0500
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <4979E565.3000901@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
	<4979E565.3000901@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>

Mark,

Well copying the configure appears to work, but when I go to make I get
all sorts of errors mostly to do with the shp2pgsql changes.  Note I did
not put in a --with-gui since I don't have wx loaded yet, but I assume
these errors are the core changes and not for the gui.  

shp2pgsql-cli.exe
shp2pgsql-core.o: In function `pgis_logf':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:177: undefined
reference to `vasprintf'
shp2pgsql-core.o: In function `DropTable':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1518: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1538: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1510: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1530: undefined
reference to `asprintf'
shp2pgsql-core.o: In function `LoadData':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:739: undefined
reference to `asprintf'
shp2pgsql-core.o:d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:74
4: more undefined references to `asprintf' follow
collect2: ld returned 1 exit status
make[1]: *** [shp2pgsql-cli.exe] Error 1
make[1]: Leaving directory `/D/SVNProjects/PostGIS/trunk/loader'
make: *** [loaderdumper] Error 2

On my OpenSUSE it compiles fine, but that is configured --with-gui
switch.  Haven't tried without with-gui on that.


Also I thought I had it set last week so I could autogen under MingW for
1.4.  I could have been dreaming and confusing with my GEOS autogen
experience.

For GEOS autogen I get the same warning below but without the errors and
it configures and compiles fine.

> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
> AG_PATH_AUTOOPTS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Friday, January 23, 2009 10:42 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Compile issues on MingW trunk

Obe, Regina wrote:

> I tried doing a make clean and 
> 
> sh autogen.sh
> 
> on MingW and I'm getting this on autogen and not sure what it means
> 
> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
> AG_PATH_AUTOOPTS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
line
> 69, <GEN1> line 111.
> aclocal: autom4te failed with exit status: 127
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
line
> 69, <GEN1> line 111.
> 
> Thanks,
> Regina

Hi Regina,

What if you run autogen.sh on your SuSE box to generate configure and 
transfer the resulting file across? Does it work then?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From robe.dnd at cityofboston.gov  Fri Jan 23 09:01:34 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 12:01:34 -0500
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob><4979E565.3000901@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>

Mark,
On closer inspection I see that asprintf and so forth are supposed to be
defined in stdio.h.

My stdio.h under MingW doesn't have these functions and in fact looks
very different from this one and doesn't even have a copyright notice

http://linux.die.net/include/stdio.h

My msys doesn't seem to have stdio.h aside from sources I've downloaded
which do have these functions.

So maybe my base libraries need to be upgraded.

Can you let me know if you have luck compiling this under MingW?  If you
do, then I'll assume its just something wrong with my install which
wouldn't be all that surprising since I don't know what I'm doing :).

I'm pretty sure I was able to compile trunk under MingW until we started
introducing these new fangled things.

Thanks,
Regina 
 


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Obe,
Regina
Sent: Friday, January 23, 2009 11:03 AM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Compile issues on MingW trunk

Mark,

Well copying the configure appears to work, but when I go to make I get
all sorts of errors mostly to do with the shp2pgsql changes.  Note I did
not put in a --with-gui since I don't have wx loaded yet, but I assume
these errors are the core changes and not for the gui.  

shp2pgsql-cli.exe
shp2pgsql-core.o: In function `pgis_logf':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:177: undefined
reference to `vasprintf'
shp2pgsql-core.o: In function `DropTable':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1518: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1538: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1510: undefined
reference to `asprintf'
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1530: undefined
reference to `asprintf'
shp2pgsql-core.o: In function `LoadData':
d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:739: undefined
reference to `asprintf'
shp2pgsql-core.o:d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:74
4: more undefined references to `asprintf' follow
collect2: ld returned 1 exit status
make[1]: *** [shp2pgsql-cli.exe] Error 1
make[1]: Leaving directory `/D/SVNProjects/PostGIS/trunk/loader'
make: *** [loaderdumper] Error 2

On my OpenSUSE it compiles fine, but that is configured --with-gui
switch.  Haven't tried without with-gui on that.


Also I thought I had it set last week so I could autogen under MingW for
1.4.  I could have been dreaming and confusing with my GEOS autogen
experience.

For GEOS autogen I get the same warning below but without the errors and
it configures and compiles fine.

> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
> AG_PATH_AUTOOPTS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Friday, January 23, 2009 10:42 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Compile issues on MingW trunk

Obe, Regina wrote:

> I tried doing a make clean and 
> 
> sh autogen.sh
> 
> on MingW and I'm getting this on autogen and not sure what it means
> 
> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
> AG_PATH_AUTOOPTS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
line
> 69, <GEN1> line 111.
> aclocal: autom4te failed with exit status: 127
> Can't locate object method "path" via package "Request" (perhaps you
> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
line
> 69, <GEN1> line 111.
> 
> Thanks,
> Regina

Hi Regina,

What if you run autogen.sh on your SuSE box to generate configure and 
transfer the resulting file across? Does it work then?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From mark.cave-ayland at siriusit.co.uk  Fri Jan 23 09:20:22 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 23 Jan 2009 17:20:22 +0000
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob><4979E565.3000901@siriusit.co.uk>	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
Message-ID: <4979FC56.8000005@siriusit.co.uk>

Obe, Regina wrote:

> Mark,
> On closer inspection I see that asprintf and so forth are supposed to be
> defined in stdio.h.
> 
> My stdio.h under MingW doesn't have these functions and in fact looks
> very different from this one and doesn't even have a copyright notice
> 
> http://linux.die.net/include/stdio.h
> 
> My msys doesn't seem to have stdio.h aside from sources I've downloaded
> which do have these functions.
> 
> So maybe my base libraries need to be upgraded.
> 
> Can you let me know if you have luck compiling this under MingW?  If you
> do, then I'll assume its just something wrong with my install which
> wouldn't be all that surprising since I don't know what I'm doing :).
> 
> I'm pretty sure I was able to compile trunk under MingW until we started
> introducing these new fangled things.
> 
> Thanks,
> Regina 

I see it. The MS C runtime doesn't contain vasprintf() or asprintf() 
which is why we include our own versions in liblwgeom. According to 
http://svn.refractions.net/postgis/trunk/liblwgeom/vsprintf.c, adding a 
lw_ prefix to both should solve this for you.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Fri Jan 23 09:21:04 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 09:21:04 -0800
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
	<4979E565.3000901@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901230921p3947faabu9f5359fc431596c8@mail.gmail.com>

It might be we need to provide our own implementations. Not a huge
problem, kind of normal in the multi-platform world.  I'll wait until
MCA weighs in on what MinGW has/hasn't.

p

On Fri, Jan 23, 2009 at 9:01 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Mark,
> On closer inspection I see that asprintf and so forth are supposed to be
> defined in stdio.h.
>
> My stdio.h under MingW doesn't have these functions and in fact looks
> very different from this one and doesn't even have a copyright notice
>
> http://linux.die.net/include/stdio.h
>
> My msys doesn't seem to have stdio.h aside from sources I've downloaded
> which do have these functions.
>
> So maybe my base libraries need to be upgraded.
>
> Can you let me know if you have luck compiling this under MingW?  If you
> do, then I'll assume its just something wrong with my install which
> wouldn't be all that surprising since I don't know what I'm doing :).
>
> I'm pretty sure I was able to compile trunk under MingW until we started
> introducing these new fangled things.
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Obe,
> Regina
> Sent: Friday, January 23, 2009 11:03 AM
> To: PostGIS Development Discussion
> Subject: RE: [postgis-devel] Compile issues on MingW trunk
>
> Mark,
>
> Well copying the configure appears to work, but when I go to make I get
> all sorts of errors mostly to do with the shp2pgsql changes.  Note I did
> not put in a --with-gui since I don't have wx loaded yet, but I assume
> these errors are the core changes and not for the gui.
>
> shp2pgsql-cli.exe
> shp2pgsql-core.o: In function `pgis_logf':
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:177: undefined
> reference to `vasprintf'
> shp2pgsql-core.o: In function `DropTable':
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1518: undefined
> reference to `asprintf'
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1538: undefined
> reference to `asprintf'
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1510: undefined
> reference to `asprintf'
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:1530: undefined
> reference to `asprintf'
> shp2pgsql-core.o: In function `LoadData':
> d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:739: undefined
> reference to `asprintf'
> shp2pgsql-core.o:d:/SVNProjects/PostGIS/trunk/loader/shp2pgsql-core.c:74
> 4: more undefined references to `asprintf' follow
> collect2: ld returned 1 exit status
> make[1]: *** [shp2pgsql-cli.exe] Error 1
> make[1]: Leaving directory `/D/SVNProjects/PostGIS/trunk/loader'
> make: *** [loaderdumper] Error 2
>
> On my OpenSUSE it compiles fine, but that is configured --with-gui
> switch.  Haven't tried without with-gui on that.
>
>
> Also I thought I had it set last week so I could autogen under MingW for
> 1.4.  I could have been dreaming and confusing with my GEOS autogen
> experience.
>
> For GEOS autogen I get the same warning below but without the errors and
> it configures and compiles fine.
>
>> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
>> AG_PATH_AUTOOPTS
>>   run info '(automake)Extending aclocal'
>>   or see
>> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
> Cave-Ayland
> Sent: Friday, January 23, 2009 10:42 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Compile issues on MingW trunk
>
> Obe, Regina wrote:
>
>> I tried doing a make clean and
>>
>> sh autogen.sh
>>
>> on MingW and I'm getting this on autogen and not sure what it means
>>
>> /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of
>> AG_PATH_AUTOOPTS
>>   run info '(automake)Extending aclocal'
>>   or see
>> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
>> Can't locate object method "path" via package "Request" (perhaps you
>> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
> line
>> 69, <GEN1> line 111.
>> aclocal: autom4te failed with exit status: 127
>> Can't locate object method "path" via package "Request" (perhaps you
>> forgot to load "Request"?) at /usr/share/autoconf/Autom4te/C4che.pm
> line
>> 69, <GEN1> line 111.
>>
>> Thanks,
>> Regina
>
> Hi Regina,
>
> What if you run autogen.sh on your SuSE box to generate configure and
> transfer the resulting file across? Does it work then?
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at opengeo.org  Fri Jan 23 09:24:33 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 09:24:33 -0800
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <4979FC56.8000005@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
	<4979E565.3000901@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
	<4979FC56.8000005@siriusit.co.uk>
Message-ID: <30fe546d0901230924x7ad2d944o17783a2344b947b8@mail.gmail.com>

Hm. Could we do it with an autoconf test and conditional compilation?
Is how mapserver does it, for example... Would be nice to use the
built-ins where available.

P

On Fri, Jan 23, 2009 at 9:20 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Obe, Regina wrote:
>
>> Mark,
>> On closer inspection I see that asprintf and so forth are supposed to be
>> defined in stdio.h.
>>
>> My stdio.h under MingW doesn't have these functions and in fact looks
>> very different from this one and doesn't even have a copyright notice
>>
>> http://linux.die.net/include/stdio.h
>>
>> My msys doesn't seem to have stdio.h aside from sources I've downloaded
>> which do have these functions.
>>
>> So maybe my base libraries need to be upgraded.
>>
>> Can you let me know if you have luck compiling this under MingW?  If you
>> do, then I'll assume its just something wrong with my install which
>> wouldn't be all that surprising since I don't know what I'm doing :).
>>
>> I'm pretty sure I was able to compile trunk under MingW until we started
>> introducing these new fangled things.
>>
>> Thanks,
>> Regina
>
> I see it. The MS C runtime doesn't contain vasprintf() or asprintf() which
> is why we include our own versions in liblwgeom. According to
> http://svn.refractions.net/postgis/trunk/liblwgeom/vsprintf.c, adding a lw_
> prefix to both should solve this for you.
>
>
> HTH,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From mark.cave-ayland at siriusit.co.uk  Fri Jan 23 09:37:27 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Fri, 23 Jan 2009 17:37:27 +0000
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <30fe546d0901230924x7ad2d944o17783a2344b947b8@mail.gmail.com>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>	<4979E565.3000901@siriusit.co.uk>	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>	<53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>	<4979FC56.8000005@siriusit.co.uk>
	<30fe546d0901230924x7ad2d944o17783a2344b947b8@mail.gmail.com>
Message-ID: <497A0057.8050905@siriusit.co.uk>

Paul Ramsey wrote:

> Hm. Could we do it with an autoconf test and conditional compilation?
> Is how mapserver does it, for example... Would be nice to use the
> built-ins where available.
> 
> P

Yeah. The correct way would be to use AC_REPLACE_FUNCS so that we can 
drop in other functions for other platforms if required in the future.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From pramsey at opengeo.org  Fri Jan 23 09:56:41 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 09:56:41 -0800
Subject: [postgis-devel] Compile issues on MingW trunk
In-Reply-To: <497A0057.8050905@siriusit.co.uk>
References: <53F9CF533E1AA14EA1F8C5C08ABC08D2055190D3@ZDND.DND.boston.cob>
	<4979E565.3000901@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D205519137@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D20551921E@ZDND.DND.boston.cob>
	<4979FC56.8000005@siriusit.co.uk>
	<30fe546d0901230924x7ad2d944o17783a2344b947b8@mail.gmail.com>
	<497A0057.8050905@siriusit.co.uk>
Message-ID: <30fe546d0901230956u19e67f4cy34f1e738411af185@mail.gmail.com>

Another thing for the crudlist :) As I slog through my function review
(600!!!) I realize I bit off a larger piece than I thought.
Oh well, things will be cleaner as a result...
P

On Fri, Jan 23, 2009 at 9:37 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>
>> Hm. Could we do it with an autoconf test and conditional compilation?
>> Is how mapserver does it, for example... Would be nice to use the
>> built-ins where available.
>>
>> P
>
> Yeah. The correct way would be to use AC_REPLACE_FUNCS so that we can drop
> in other functions for other platforms if required in the future.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at opengeo.org  Fri Jan 23 11:08:24 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 11:08:24 -0800
Subject: [postgis-devel] Function Naming
Message-ID: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>

I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
You should be able to open it with any spreadsheet program that reads
tab-separated intput.
Please do a review in your abundant spare time.
Functions marked PUBLIC/KEEP should be part of the documentation.
Everything else should be invisible. We have a large collection of
functions that have been deprecated since 1.2. However, removing them
*will* break some client apps (mapserver, for example).
Hopefully the rest of it is self-explanatory.
P.


From pramsey at opengeo.org  Fri Jan 23 11:21:49 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 11:21:49 -0800
Subject: [postgis-devel] Execution Cost
Message-ID: <30fe546d0901231121v70e3a3a7wa37f4f51cb991ba8@mail.gmail.com>

(a) Should we be looking at setting explicit costs onto our functions
as part of the 1.4 release?
(b) By defining our (ST_Intersects, etc) wrappers as 'SQL' language
have we harmed our helped ourselves? (Non-C functions are given
autocost of 100, C functions get autocost of 1.)

P.


From pramsey at opengeo.org  Fri Jan 23 11:24:34 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 11:24:34 -0800
Subject: [postgis-devel] Deprecation Warnings
Message-ID: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>

Could we use the function creation option

SET configuration_parameter { TO value | = value | FROM CURRENT }

to, for example, set postgis_deprecated to true?
Then in the function, we could warn on deprecation. So the same
backend to intersects() could be used by several function names, but
only some would raise deprecation warnings.

Or do we want to continue our gentle regime of letting the old names
live in quite obscurity?

P.


From robe.dnd at cityofboston.gov  Fri Jan 23 11:26:04 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 14:26:04 -0500
Subject: [postgis-devel] Execution Cost
In-Reply-To: <30fe546d0901231121v70e3a3a7wa37f4f51cb991ba8@mail.gmail.com>
References: <30fe546d0901231121v70e3a3a7wa37f4f51cb991ba8@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2055193BB@ZDND.DND.boston.cob>

We should think about it.  For B) geometry functions should in general
have higher cost.  So I think a cost of 100 is better than 1.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, January 23, 2009 2:22 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Execution Cost

(a) Should we be looking at setting explicit costs onto our functions
as part of the 1.4 release?
(b) By defining our (ST_Intersects, etc) wrappers as 'SQL' language
have we harmed our helped ourselves? (Non-C functions are given
autocost of 100, C functions get autocost of 1.)

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From robe.dnd at cityofboston.gov  Fri Jan 23 11:31:14 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 14:31:14 -0500
Subject: [postgis-devel] Function Naming
In-Reply-To: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>

Paul,
You realize this is not a complete list.  A cursory glance looks like
you left out all the long transaction support functions.

Also all those geometry_ functions you kept, I would prefer they don't
start with geometry. 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, January 23, 2009 2:08 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Function Naming

I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
You should be able to open it with any spreadsheet program that reads
tab-separated intput.
Please do a review in your abundant spare time.
Functions marked PUBLIC/KEEP should be part of the documentation.
Everything else should be invisible. We have a large collection of
functions that have been deprecated since 1.2. However, removing them
*will* break some client apps (mapserver, for example).
Hopefully the rest of it is self-explanatory.
P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


From codesite-noreply at google.com  Fri Jan 23 12:08:59 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 23 Jan 2009 20:08:59 +0000
Subject: [postgis-devel] Issue 102 in postgis: Fix name of f_table_schema in
	doc
Message-ID: <0015174ff158a8fa8204612bf57d@google.com>

Status: New
Owner: ----

New issue 102 by dudu... at yahoo.fr: Fix name of f_table_schema in doc
http://code.google.com/p/postgis/issues/detail?id=102

The DropGeometryColumn has incorrect documentation. The column name for the
schema in the geometry_columns table is f_table_schema and not  
f_schema_name.

Attachments:
	fix_dropgeometrycolumn_doc.patch  544 bytes

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From kneufeld at refractions.net  Fri Jan 23 12:52:08 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 23 Jan 2009 12:52:08 -0800
Subject: [postgis-devel] Execution Cost
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2055193BB@ZDND.DND.boston.cob>
References: <30fe546d0901231121v70e3a3a7wa37f4f51cb991ba8@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193BB@ZDND.DND.boston.cob>
Message-ID: <497A2DF8.5050005@refractions.net>

I agree.  I know it's caused some issues in the past.  I was going to set up a testing environment with a common dataset 
(ie. tiger) to come up with a relative cost per function.  Then all we would need to do is scale the costs 
appropriately.  However, my spare time is disappearing faster than dust on a windy day :)  I do think it's a good idea 
though.

-- Kevin

Obe, Regina wrote:
> We should think about it.  For B) geometry functions should in general
> have higher cost.  So I think a cost of 100 is better than 1.
> 
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Friday, January 23, 2009 2:22 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Execution Cost
> 
> (a) Should we be looking at setting explicit costs onto our functions
> as part of the 1.4 release?
> (b) By defining our (ST_Intersects, etc) wrappers as 'SQL' language
> have we harmed our helped ourselves? (Non-C functions are given
> autocost of 100, C functions get autocost of 1.)
> 
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From kneufeld at refractions.net  Fri Jan 23 12:59:45 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 23 Jan 2009 12:59:45 -0800
Subject: [postgis-devel] Deprecation Warnings
In-Reply-To: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>
Message-ID: <497A2FC1.4050105@refractions.net>

What if we deprecate the functions as you suggest (and eventually remove them), but provide a sql script that will 
reinstate them as wrappers to the ST_* methods.  That way, folks can have their cake and eat it too ... upgrade to the 
latest version without breaking their apps.

-- Kevin

Paul Ramsey wrote:
> Could we use the function creation option
> 
> SET configuration_parameter { TO value | = value | FROM CURRENT }
> 
> to, for example, set postgis_deprecated to true?
> Then in the function, we could warn on deprecation. So the same
> backend to intersects() could be used by several function names, but
> only some would raise deprecation warnings.
> 
> Or do we want to continue our gentle regime of letting the old names
> live in quite obscurity?
> 
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From codesite-noreply at google.com  Fri Jan 23 13:07:14 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 23 Jan 2009 21:07:14 +0000
Subject: [postgis-devel] Issue 102 in postgis: Fix name of f_table_schema in
	doc
Message-ID: <001485f91cb2efabdc04612cc57d@google.com>

Updates:
	Status: Fixed
	Labels: Type-Patch Priority-Low Milestone-1.4

Comment #1 on issue 102 by ke... at refractions.net: Fix name of  
f_table_schema in doc
http://code.google.com/p/postgis/issues/detail?id=102

Committed.  Thanx.
-- Kevin

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From david.bitner at gmail.com  Fri Jan 23 13:51:38 2009
From: david.bitner at gmail.com (David William Bitner)
Date: Fri, 23 Jan 2009 15:51:38 -0600
Subject: [postgis-devel] Deprecation Warnings
In-Reply-To: <497A2FC1.4050105@refractions.net>
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>
	<497A2FC1.4050105@refractions.net>
Message-ID: <d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>

+1, I like Cake.

On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld <kneufeld at refractions.net>wrote:

> What if we deprecate the functions as you suggest (and eventually remove
> them), but provide a sql script that will reinstate them as wrappers to the
> ST_* methods.  That way, folks can have their cake and eat it too ...
> upgrade to the latest version without breaking their apps.
>
> -- Kevin
>
>
> Paul Ramsey wrote:
>
>> Could we use the function creation option
>>
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>
>> to, for example, set postgis_deprecated to true?
>> Then in the function, we could warn on deprecation. So the same
>> backend to intersects() could be used by several function names, but
>> only some would raise deprecation warnings.
>>
>> Or do we want to continue our gentle regime of letting the old names
>> live in quite obscurity?
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090123/43ee2eca/attachment.html>

From robe.dnd at cityofboston.gov  Fri Jan 23 14:06:49 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 17:06:49 -0500
Subject: [postgis-devel] Deprecation Warnings
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com><497A2FC1.4050105@refractions.net>
	<d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F122@ZDND.DND.boston.cob>

+2


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of David William Bitner
Sent: Fri 1/23/2009 4:51 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Deprecation Warnings
 
+1, I like Cake.

On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld <kneufeld at refractions.net>wrote:

> What if we deprecate the functions as you suggest (and eventually remove
> them), but provide a sql script that will reinstate them as wrappers to the
> ST_* methods.  That way, folks can have their cake and eat it too ...
> upgrade to the latest version without breaking their apps.
>
> -- Kevin
>
>
> Paul Ramsey wrote:
>
>> Could we use the function creation option
>>
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>
>> to, for example, set postgis_deprecated to true?
>> Then in the function, we could warn on deprecation. So the same
>> backend to intersects() could be used by several function names, but
>> only some would raise deprecation warnings.
>>
>> Or do we want to continue our gentle regime of letting the old names
>> live in quite obscurity?
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner




-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090123/97266083/attachment.html>

From robe.dnd at cityofboston.gov  Fri Jan 23 14:25:23 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Fri, 23 Jan 2009 17:25:23 -0500
Subject: [postgis-devel] Deprecation Warnings
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com><497A2FC1.4050105@refractions.net><d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F122@ZDND.DND.boston.cob>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F123@ZDND.DND.boston.cob>

Hmm although it really wouldn't be deprecate -- it would be lets remove them and allow people to reinstate them if they want as Kevin suggested.

Personally I don't care for warnings -- either keep it or get rid of it.  Warnings sounds like a lot of wasted log space which will probably only be seen by logs and potentially mysteriously slow down applications in the process.

Though I guess we must think of the children (Mapserver, GeoServer and ZigGIS and so forth which may be using the old names).  But then I suppose anyone using apps relying on deprecated names would just install the wrapper patch.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
Sent: Fri 1/23/2009 5:06 PM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Deprecation Warnings
 
+2


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of David William Bitner
Sent: Fri 1/23/2009 4:51 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Deprecation Warnings
 
+1, I like Cake.

On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld <kneufeld at refractions.net>wrote:

> What if we deprecate the functions as you suggest (and eventually remove
> them), but provide a sql script that will reinstate them as wrappers to the
> ST_* methods.  That way, folks can have their cake and eat it too ...
> upgrade to the latest version without breaking their apps.
>
> -- Kevin
>
>
> Paul Ramsey wrote:
>
>> Could we use the function creation option
>>
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>
>> to, for example, set postgis_deprecated to true?
>> Then in the function, we could warn on deprecation. So the same
>> backend to intersects() could be used by several function names, but
>> only some would raise deprecation warnings.
>>
>> Or do we want to continue our gentle regime of letting the old names
>> live in quite obscurity?
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner




-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090123/a4a0b3c4/attachment.html>

From pramsey at opengeo.org  Fri Jan 23 14:30:20 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 14:30:20 -0800
Subject: [postgis-devel] Deprecation Warnings
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F123@ZDND.DND.boston.cob>
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>
	<497A2FC1.4050105@refractions.net>
	<d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F122@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F123@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901231430m1e7a379ap460a9b651e78c2ec@mail.gmail.com>

Right. Not even wrappers, just breaking the install into postgis.sql
and postgis_legacy.sql...

P

On Fri, Jan 23, 2009 at 2:25 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Hmm although it really wouldn't be deprecate -- it would be lets remove them
> and allow people to reinstate them if they want as Kevin suggested.
>
> Personally I don't care for warnings -- either keep it or get rid of it.
> Warnings sounds like a lot of wasted log space which will probably only be
> seen by logs and potentially mysteriously slow down applications in the
> process.
>
> Though I guess we must think of the children (Mapserver, GeoServer and
> ZigGIS and so forth which may be using the old names).  But then I suppose
> anyone using apps relying on deprecated names would just install the wrapper
> patch.
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
> Sent: Fri 1/23/2009 5:06 PM
> To: PostGIS Development Discussion
> Subject: RE: [postgis-devel] Deprecation Warnings
>
> +2
>
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net on behalf of David
> William Bitner
> Sent: Fri 1/23/2009 4:51 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Deprecation Warnings
>
> +1, I like Cake.
>
> On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld
> <kneufeld at refractions.net>wrote:
>
>> What if we deprecate the functions as you suggest (and eventually remove
>> them), but provide a sql script that will reinstate them as wrappers to
>> the
>> ST_* methods.  That way, folks can have their cake and eat it too ...
>> upgrade to the latest version without breaking their apps.
>>
>> -- Kevin
>>
>>
>> Paul Ramsey wrote:
>>
>>> Could we use the function creation option
>>>
>>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>>
>>> to, for example, set postgis_deprecated to true?
>>> Then in the function, we could warn on deprecation. So the same
>>> backend to intersects() could be used by several function names, but
>>> only some would raise deprecation warnings.
>>>
>>> Or do we want to continue our gentle regime of letting the old names
>>> live in quite obscurity?
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
>
> --
> ************************************
> David William Bitner
>
>
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>


From pramsey at opengeo.org  Fri Jan 23 14:30:59 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Fri, 23 Jan 2009 14:30:59 -0800
Subject: [postgis-devel] Deprecation Warnings
In-Reply-To: <30fe546d0901231430m1e7a379ap460a9b651e78c2ec@mail.gmail.com>
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>
	<497A2FC1.4050105@refractions.net>
	<d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F122@ZDND.DND.boston.cob>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F123@ZDND.DND.boston.cob>
	<30fe546d0901231430m1e7a379ap460a9b651e78c2ec@mail.gmail.com>
Message-ID: <30fe546d0901231430vea39e32gde744667afddda7a@mail.gmail.com>

Although, to answer myself, if we're doing that, is it so bad to just
keep the damn things around? the point of removing them is....
*removing* them. So they don't have to be thougth about anymore.

P.

On Fri, Jan 23, 2009 at 2:30 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> Right. Not even wrappers, just breaking the install into postgis.sql
> and postgis_legacy.sql...
>
> P
>
> On Fri, Jan 23, 2009 at 2:25 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Hmm although it really wouldn't be deprecate -- it would be lets remove them
>> and allow people to reinstate them if they want as Kevin suggested.
>>
>> Personally I don't care for warnings -- either keep it or get rid of it.
>> Warnings sounds like a lot of wasted log space which will probably only be
>> seen by logs and potentially mysteriously slow down applications in the
>> process.
>>
>> Though I guess we must think of the children (Mapserver, GeoServer and
>> ZigGIS and so forth which may be using the old names).  But then I suppose
>> anyone using apps relying on deprecated names would just install the wrapper
>> patch.
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
>> Sent: Fri 1/23/2009 5:06 PM
>> To: PostGIS Development Discussion
>> Subject: RE: [postgis-devel] Deprecation Warnings
>>
>> +2
>>
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of David
>> William Bitner
>> Sent: Fri 1/23/2009 4:51 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Deprecation Warnings
>>
>> +1, I like Cake.
>>
>> On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld
>> <kneufeld at refractions.net>wrote:
>>
>>> What if we deprecate the functions as you suggest (and eventually remove
>>> them), but provide a sql script that will reinstate them as wrappers to
>>> the
>>> ST_* methods.  That way, folks can have their cake and eat it too ...
>>> upgrade to the latest version without breaking their apps.
>>>
>>> -- Kevin
>>>
>>>
>>> Paul Ramsey wrote:
>>>
>>>> Could we use the function creation option
>>>>
>>>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>>>
>>>> to, for example, set postgis_deprecated to true?
>>>> Then in the function, we could warn on deprecation. So the same
>>>> backend to intersects() could be used by several function names, but
>>>> only some would raise deprecation warnings.
>>>>
>>>> Or do we want to continue our gentle regime of letting the old names
>>>> live in quite obscurity?
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>
>>
>>
>> --
>> ************************************
>> David William Bitner
>>
>>
>>
>>
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>


From kneufeld at refractions.net  Fri Jan 23 14:37:01 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Fri, 23 Jan 2009 14:37:01 -0800
Subject: [postgis-devel] Deprecation Warnings
In-Reply-To: <30fe546d0901231430vea39e32gde744667afddda7a@mail.gmail.com>
References: <30fe546d0901231124r99af786y48e30aeadb2b0dab@mail.gmail.com>	<497A2FC1.4050105@refractions.net>	<d2f53e190901231351v580fb0e6if0db48b51b037518@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F122@ZDND.DND.boston.cob>	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F123@ZDND.DND.boston.cob>	<30fe546d0901231430m1e7a379ap460a9b651e78c2ec@mail.gmail.com>
	<30fe546d0901231430vea39e32gde744667afddda7a@mail.gmail.com>
Message-ID: <497A468D.40501@refractions.net>

:) Right.  The only reason I suppose to have the two scripts would be to make a really strong hint that people should 
upgrade their apps (since they would have to purposely install the legacy sql script to make their new PostGIS install 
backwards compatible).

Paul Ramsey wrote:
> Although, to answer myself, if we're doing that, is it so bad to just
> keep the damn things around? the point of removing them is....
> *removing* them. So they don't have to be thougth about anymore.
> 
> P.
> 
> On Fri, Jan 23, 2009 at 2:30 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>> Right. Not even wrappers, just breaking the install into postgis.sql
>> and postgis_legacy.sql...
>>
>> P
>>
>> On Fri, Jan 23, 2009 at 2:25 PM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>>> Hmm although it really wouldn't be deprecate -- it would be lets remove them
>>> and allow people to reinstate them if they want as Kevin suggested.
>>>
>>> Personally I don't care for warnings -- either keep it or get rid of it.
>>> Warnings sounds like a lot of wasted log space which will probably only be
>>> seen by logs and potentially mysteriously slow down applications in the
>>> process.
>>>
>>> Though I guess we must think of the children (Mapserver, GeoServer and
>>> ZigGIS and so forth which may be using the old names).  But then I suppose
>>> anyone using apps relying on deprecated names would just install the wrapper
>>> patch.
>>>
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
>>> Sent: Fri 1/23/2009 5:06 PM
>>> To: PostGIS Development Discussion
>>> Subject: RE: [postgis-devel] Deprecation Warnings
>>>
>>> +2
>>>
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net on behalf of David
>>> William Bitner
>>> Sent: Fri 1/23/2009 4:51 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Deprecation Warnings
>>>
>>> +1, I like Cake.
>>>
>>> On Fri, Jan 23, 2009 at 2:59 PM, Kevin Neufeld
>>> <kneufeld at refractions.net>wrote:
>>>
>>>> What if we deprecate the functions as you suggest (and eventually remove
>>>> them), but provide a sql script that will reinstate them as wrappers to
>>>> the
>>>> ST_* methods.  That way, folks can have their cake and eat it too ...
>>>> upgrade to the latest version without breaking their apps.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Paul Ramsey wrote:
>>>>
>>>>> Could we use the function creation option
>>>>>
>>>>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>>>>>
>>>>> to, for example, set postgis_deprecated to true?
>>>>> Then in the function, we could warn on deprecation. So the same
>>>>> backend to intersects() could be used by several function names, but
>>>>> only some would raise deprecation warnings.
>>>>>
>>>>> Or do we want to continue our gentle regime of letting the old names
>>>>> live in quite obscurity?
>>>>>
>>>>> P.
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at postgis.refractions.net
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>
>>>
>>> --
>>> ************************************
>>> David William Bitner
>>>
>>>
>>>
>>>
>>> -----------------------------------------
>>> The substance of this message, including any attachments, may be
>>> confidential, legally privileged and/or exempt from disclosure
>>> pursuant to Massachusetts law. It is intended
>>> solely for the addressee. If you received this in error, please
>>> contact the sender and delete the material from any computer.
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


From pramsey at opengeo.org  Sat Jan 24 11:45:30 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Sat, 24 Jan 2009 11:45:30 -0800
Subject: [postgis-devel] Function Naming
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>
Message-ID: <30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>

the geometry_* naming convention is what PgSQL uses for other
type-support functions, which is why I recommend moving back to that
from the ST_* versions that are currently in there.

P.

On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
> You realize this is not a complete list.  A cursory glance looks like
> you left out all the long transaction support functions.
>
> Also all those geometry_ functions you kept, I would prefer they don't
> start with geometry.
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Friday, January 23, 2009 2:08 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Function Naming
>
> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
> You should be able to open it with any spreadsheet program that reads
> tab-separated intput.
> Please do a review in your abundant spare time.
> Functions marked PUBLIC/KEEP should be part of the documentation.
> Everything else should be invisible. We have a large collection of
> functions that have been deprecated since 1.2. However, removing them
> *will* break some client apps (mapserver, for example).
> Hopefully the rest of it is self-explanatory.
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>


From pramsey at opengeo.org  Sat Jan 24 11:46:58 2009
From: pramsey at opengeo.org (Paul Ramsey)
Date: Sat, 24 Jan 2009 11:46:58 -0800
Subject: [postgis-devel] Function Naming
In-Reply-To: <30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>
	<30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>
Message-ID: <30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>

One naming inconsistency you might have noted is that i've recommended
renaming some ugly-named gist support functions to
postgis_gist_compress, etc. But I also have some new functions for the
aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
re-name my new pgis_ functions to use the fully spelled out
"postgis_"? I am leaning that way.

P.

On Sat, Jan 24, 2009 at 11:45 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> the geometry_* naming convention is what PgSQL uses for other
> type-support functions, which is why I recommend moving back to that
> from the ST_* versions that are currently in there.
>
> P.
>
> On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Paul,
>> You realize this is not a complete list.  A cursory glance looks like
>> you left out all the long transaction support functions.
>>
>> Also all those geometry_ functions you kept, I would prefer they don't
>> start with geometry.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, January 23, 2009 2:08 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Function Naming
>>
>> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
>> You should be able to open it with any spreadsheet program that reads
>> tab-separated intput.
>> Please do a review in your abundant spare time.
>> Functions marked PUBLIC/KEEP should be part of the documentation.
>> Everything else should be invisible. We have a large collection of
>> functions that have been deprecated since 1.2. However, removing them
>> *will* break some client apps (mapserver, for example).
>> Hopefully the rest of it is self-explanatory.
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>


From robe.dnd at cityofboston.gov  Sat Jan 24 15:07:25 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Sat, 24 Jan 2009 18:07:25 -0500
Subject: [postgis-devel] Function Naming
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob><30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>
	<30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F125@ZDND.DND.boston.cob>

I don't care just toss a coin and pick one or which one has the fewest functions move to the other.

Though I would have preferred lwgeom or something like that.  postgis/pgis seems kind of tempting to use for a clueless end user.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Sat 1/24/2009 2:46 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Function Naming
 
One naming inconsistency you might have noted is that i've recommended
renaming some ugly-named gist support functions to
postgis_gist_compress, etc. But I also have some new functions for the
aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
re-name my new pgis_ functions to use the fully spelled out
"postgis_"? I am leaning that way.

P.

On Sat, Jan 24, 2009 at 11:45 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> the geometry_* naming convention is what PgSQL uses for other
> type-support functions, which is why I recommend moving back to that
> from the ST_* versions that are currently in there.
>
> P.
>
> On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Paul,
>> You realize this is not a complete list.  A cursory glance looks like
>> you left out all the long transaction support functions.
>>
>> Also all those geometry_ functions you kept, I would prefer they don't
>> start with geometry.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, January 23, 2009 2:08 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Function Naming
>>
>> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
>> You should be able to open it with any spreadsheet program that reads
>> tab-separated intput.
>> Please do a review in your abundant spare time.
>> Functions marked PUBLIC/KEEP should be part of the documentation.
>> Everything else should be invisible. We have a large collection of
>> functions that have been deprecated since 1.2. However, removing them
>> *will* break some client apps (mapserver, for example).
>> Hopefully the rest of it is self-explanatory.
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090124/ff6b263f/attachment.html>

From mark.cave-ayland at siriusit.co.uk  Sat Jan 24 15:15:38 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Sat, 24 Jan 2009 23:15:38 +0000
Subject: [postgis-devel] Function Naming
In-Reply-To: <30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>	<30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>
	<30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>
Message-ID: <497BA11A.7030409@siriusit.co.uk>

Paul Ramsey wrote:

> One naming inconsistency you might have noted is that i've recommended
> renaming some ugly-named gist support functions to
> postgis_gist_compress, etc. But I also have some new functions for the
> aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
> re-name my new pgis_ functions to use the fully spelled out
> "postgis_"? I am leaning that way.
> 
> P.

The GiST support functions are related to an underlying type rather than 
to the library. If you were to go with "postgis_gist_compress", what 
would happen if someone were to code up an implementation of a new 
geography type for PostGIS? I think "geometry_gist_compress" etc. would 
be the way to go.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Sat Jan 24 15:17:51 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Sat, 24 Jan 2009 18:17:51 -0500
Subject: [postgis-devel] Function Naming
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com><53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob><30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com><30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F125@ZDND.DND.boston.cob>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F126@ZDND.DND.boston.cob>

On second thought existing support functions use postgis_  such as postgis_full_version()

so I guess postgis would be better than pgis.  But its a bit annoying to me that we've got functions intended to be used by end users mixed in with functions that aren't.

I actually like the whole underscore bit even though I suppose it doesn't follow postgresql convention.

So those new functions you have would be

_postgis_geometry_accum_finalfn

Same goes with all those geometry_ I whined about.

Seems better to be 

_geometry_

Since their public exposure is as operators or helper functions to operators.  Not to be used directly by end users.



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
Sent: Sat 1/24/2009 6:07 PM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Function Naming
 
I don't care just toss a coin and pick one or which one has the fewest functions move to the other.

Though I would have preferred lwgeom or something like that.  postgis/pgis seems kind of tempting to use for a clueless end user.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Sat 1/24/2009 2:46 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Function Naming
 
One naming inconsistency you might have noted is that i've recommended
renaming some ugly-named gist support functions to
postgis_gist_compress, etc. But I also have some new functions for the
aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
re-name my new pgis_ functions to use the fully spelled out
"postgis_"? I am leaning that way.

P.

On Sat, Jan 24, 2009 at 11:45 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> the geometry_* naming convention is what PgSQL uses for other
> type-support functions, which is why I recommend moving back to that
> from the ST_* versions that are currently in there.
>
> P.
>
> On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Paul,
>> You realize this is not a complete list.  A cursory glance looks like
>> you left out all the long transaction support functions.
>>
>> Also all those geometry_ functions you kept, I would prefer they don't
>> start with geometry.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, January 23, 2009 2:08 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Function Naming
>>
>> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
>> You should be able to open it with any spreadsheet program that reads
>> tab-separated intput.
>> Please do a review in your abundant spare time.
>> Functions marked PUBLIC/KEEP should be part of the documentation.
>> Everything else should be invisible. We have a large collection of
>> functions that have been deprecated since 1.2. However, removing them
>> *will* break some client apps (mapserver, for example).
>> Hopefully the rest of it is self-explanatory.
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090124/026acb88/attachment.html>

From robe.dnd at cityofboston.gov  Sat Jan 24 15:18:44 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Sat, 24 Jan 2009 18:18:44 -0500
Subject: [postgis-devel] Function Naming
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>	<30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>
	<30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>
	<497BA11A.7030409@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F127@ZDND.DND.boston.cob>

Does ESRI use GIST as well for their PG_GEOMETRY or whatever they call it.  I'm just thinking if we call it geometry  may get confusing for people that use both types. Though theirs is in a separate schema anyway so doesn't matter I suppose except if someone makes the sde schema a global one then we could have some clashes maybe.  Probably not.  Just thinking out loud.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Mark Cave-Ayland
Sent: Sat 1/24/2009 6:15 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Function Naming
 
Paul Ramsey wrote:

> One naming inconsistency you might have noted is that i've recommended
> renaming some ugly-named gist support functions to
> postgis_gist_compress, etc. But I also have some new functions for the
> aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
> re-name my new pgis_ functions to use the fully spelled out
> "postgis_"? I am leaning that way.
> 
> P.

The GiST support functions are related to an underlying type rather than 
to the library. If you were to go with "postgis_gist_compress", what 
would happen if someone were to code up an implementation of a new 
geography type for PostGIS? I think "geometry_gist_compress" etc. would 
be the way to go.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090124/140e5aa5/attachment.html>

From codesite-noreply at google.com  Sun Jan 25 07:20:56 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 25 Jan 2009 15:20:56 +0000
Subject: [postgis-devel] Issue 104 in postgis: shp2pgsql is using deprecated
	PostgreSQL escape syntax
Message-ID: <0016e64359462b8fd70461502b78@google.com>

Status: Accepted
Owner: robe.... at cityofboston.gov
Labels: Type-Defect Priority-Low

New issue 104 by robe.... at cityofboston.gov: shp2pgsql is using deprecated  
PostgreSQL escape syntax
http://code.google.com/p/postgis/issues/detail?id=104

For some datasets I get this

HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
WARNING:  nonstandard use of \\ in a string literal
LINE 1: ...w','St','Brighton','02135','Residential','3','R3','\\2003\\2...


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Sun Jan 25 07:24:57 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 25 Jan 2009 15:24:57 +0000
Subject: [postgis-devel] Issue 103 in postgis: Box3D always gets cast to 2D
	geometry
Message-ID: <0015174ff5d688499e04615039a2@google.com>

Status: New
Owner: robe.... at cityofboston.gov
Labels: Priority-Low

New issue 103 by robe.... at cityofboston.gov: Box3D always gets cast to 2D  
geometry
http://code.google.com/p/postgis/issues/detail?id=103

Actually not sure if this is solvable.  But ST_SetSRID, ST_Force_3DZ all
lose the Z coordinate value of a BOX3D.

Example:

SELECT ST_AsEWKT(ST_Force_3DZ(ST_Extent3D(foo.the_geom))) As b3extentpoly,
ST_Extent3D(foo.the_geom) As b3extent
FROM (SELECT ST_MakePoint(x,y,z) As the_geom
	FROM generate_series(1,3) As x
		CROSS JOIN generate_series(1,2) As y
		CROSS JOIN generate_series(0,2) As Z) As foo;

Yields:
b3extentpoly                                 b3extent
POLYGON((1 1 0,1 2 0,3 2 0,3 1 0,1 1 0)) ;BOX3D(1 1 0,3 2 2)

I would expect the POLYGON value to have some 2 z coords in there.



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From mark.cave-ayland at siriusit.co.uk  Sun Jan 25 10:01:18 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Sun, 25 Jan 2009 18:01:18 +0000
Subject: [postgis-devel] Function Naming
In-Reply-To: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F127@ZDND.DND.boston.cob>
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>	<30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>	<30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>	<497BA11A.7030409@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F127@ZDND.DND.boston.cob>
Message-ID: <497CA8EE.7010107@siriusit.co.uk>

Obe, Regina wrote:

> Does ESRI use GIST as well for their PG_GEOMETRY or whatever they call 
> it.  I'm just thinking if we call it geometry  may get confusing for 
> people that use both types. Though theirs is in a separate schema anyway 
> so doesn't matter I suppose except if someone makes the sde schema a 
> global one then we could have some clashes maybe.  Probably not.  Just 
> thinking out loud.

Heh. I think anyone who installs both PostGIS and ESRI's geometry type 
into the same database should probably have their head examined anyway 
:)  Seriously, how could anyone do this and sanely expect it all to work 
without any problems??!


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From robe.dnd at cityofboston.gov  Sun Jan 25 15:58:51 2009
From: robe.dnd at cityofboston.gov (Obe, Regina)
Date: Sun, 25 Jan 2009 18:58:51 -0500
Subject: [postgis-devel] Function Naming
References: <30fe546d0901231108j596f90e5t71dea5b2b5eaa98d@mail.gmail.com>	<53F9CF533E1AA14EA1F8C5C08ABC08D2055193DC@ZDND.DND.boston.cob>	<30fe546d0901241145m1ecbe136r7e147c8b33d92245@mail.gmail.com>	<30fe546d0901241146v640b20b2gef4c8e753de1d437@mail.gmail.com>	<497BA11A.7030409@siriusit.co.uk>
	<53F9CF533E1AA14EA1F8C5C08ABC08D204D7F127@ZDND.DND.boston.cob>
	<497CA8EE.7010107@siriusit.co.uk>
Message-ID: <53F9CF533E1AA14EA1F8C5C08ABC08D204D7F12A@ZDND.DND.boston.cob>

I haven't tried to myself, but then again I have yet to try ArcGIS PostSDE.
I suspect its common because I think from my reading ArcSDE forces you to register each PostSDE service against one database.  I have to verify that.  So lets say you want to make use of ArcSDE only features not supported by the PostGIS datatype, you may have tables using the ESRI geometry type (for example or at leaset as the claim goes ArcSDE curved support is better than PostGIS curve support), but if you want Open source apps to use some tables, you would use the PostGIS datatype.



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Mark Cave-Ayland
Sent: Sun 1/25/2009 1:01 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Function Naming
 
Obe, Regina wrote:

> Does ESRI use GIST as well for their PG_GEOMETRY or whatever they call 
> it.  I'm just thinking if we call it geometry  may get confusing for 
> people that use both types. Though theirs is in a separate schema anyway 
> so doesn't matter I suppose except if someone makes the sde schema a 
> global one then we could have some clashes maybe.  Probably not.  Just 
> thinking out loud.

Heh. I think anyone who installs both PostGIS and ESRI's geometry type 
into the same database should probably have their head examined anyway 
:)  Seriously, how could anyone do this and sanely expect it all to work 
without any problems??!


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090125/0a69f436/attachment.html>

From codesite-noreply at google.com  Mon Jan 26 01:15:18 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 26 Jan 2009 09:15:18 +0000
Subject: [postgis-devel] Issue 105 in postgis: pgsql2shp seems to produce
	incorrect dbase files, problems importing into Gnumeric
Message-ID: <00163630ee1d693a6e04615f2dca@google.com>

Status: New
Owner: ----

New issue 105 by phopfgartner: pgsql2shp seems to produce incorrect dbase  
files, problems importing into Gnumeric
http://code.google.com/p/postgis/issues/detail?id=105

What steps will reproduce the problem?
1. Export data with shp2pgsql
2. Import the generated dbase file into Gnumeric

Gnumeric does not show the last record.

Problem analysis by Gnumeric developers suggests 2 problems with the
generated file, major details at
http://bugzilla.gnome.org/show_bug.cgi?id=568454.

PostgreSQL: 8.2.9, as in current CentOS Testing repository
PostGIS: 1.3.5



Attachments:
	P200101.dbf  8.1 KB

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Mon Jan 26 02:51:40 2009
From: strk at keybit.net (strk)
Date: Mon, 26 Jan 2009 11:51:40 +0100
Subject: [postgis-devel] WKTRaster & liblwgeom : thread safety
Message-ID: <20090126105140.GC75703@keybit.net>

Hi all.
While interfacing to liblwgeom from WKTRaster in order
to implement vector construction from rasters I've
hit a limit preventing WKTRaster api from being thread-safe.

Is not a big deal for the project in this stage, but
for future improvements it might be worth thinking
about how to make that possible.

In particular, I've started the WKTRaster api by
defining a 'context' structure to hold memory management
and info reporting functions, similarly to what the
set of (lwalloc_var, lwrealloc_var, lwfree_var,
lwerror_var, lwnotice_var) accomplish for liblwgeom,
just into a structure that is passed around.

The context struct looks like this:

 typedef void* (*rt_allocator)(size_t size);
 typedef void* (*rt_reallocator)(void *mem, size_t size);
 typedef void  (*rt_deallocator)(void *mem);
 typedef void  (*rt_message_handler)(const char* string, ...);

 struct rt_context_t {
     rt_allocator alloc;
     rt_reallocator realloc;
     rt_deallocator dealloc;
     rt_message_handler err;
     rt_message_handler warn;
     rt_message_handler info;
 };

It allows for doing things like:

 void a_func(struct rt_context_t* ctx)
 {
	void* mem = ctx->alloc(32);
	ctx->info("Allocated 32 bytes @ %p", mem);
	mem = ctx->realloc(mem, 64);
	ctx->warn("Reallocated to %p", mem)
	ctx->dealloc(mem);
	ctx->err("Catastrophe, %p is gone!", mem)
 }

The structure is passed around to all functions of the API,
allowing for messages to come out from wherever.

Now, when it comes to interface to liblwgeom, we basically
loose any possibility to hook on the context, as liblwgeom
relies on that lib-static set of routines instead.

As an aim to integration I could drop the thread-safety
as a whole and use the same schema for those utility
functions. Or, we can modify lots of liblwgeom to allow
for thread-safety.

Your thougths on the matter ?

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From mark.cave-ayland at siriusit.co.uk  Mon Jan 26 03:54:17 2009
From: mark.cave-ayland at siriusit.co.uk (Mark Cave-Ayland)
Date: Mon, 26 Jan 2009 11:54:17 +0000
Subject: [postgis-devel] WKTRaster & liblwgeom : thread safety
In-Reply-To: <20090126105140.GC75703@keybit.net>
References: <20090126105140.GC75703@keybit.net>
Message-ID: <497DA469.1010309@siriusit.co.uk>

strk wrote:

> Hi all.
> While interfacing to liblwgeom from WKTRaster in order
> to implement vector construction from rasters I've
> hit a limit preventing WKTRaster api from being thread-safe.
> 
> Is not a big deal for the project in this stage, but
> for future improvements it might be worth thinking
> about how to make that possible.
> 
> In particular, I've started the WKTRaster api by
> defining a 'context' structure to hold memory management
> and info reporting functions, similarly to what the
> set of (lwalloc_var, lwrealloc_var, lwfree_var,
> lwerror_var, lwnotice_var) accomplish for liblwgeom,
> just into a structure that is passed around.
> 
> The context struct looks like this:
> 
>  typedef void* (*rt_allocator)(size_t size);
>  typedef void* (*rt_reallocator)(void *mem, size_t size);
>  typedef void  (*rt_deallocator)(void *mem);
>  typedef void  (*rt_message_handler)(const char* string, ...);
> 
>  struct rt_context_t {
>      rt_allocator alloc;
>      rt_reallocator realloc;
>      rt_deallocator dealloc;
>      rt_message_handler err;
>      rt_message_handler warn;
>      rt_message_handler info;
>  };
> 
> It allows for doing things like:
> 
>  void a_func(struct rt_context_t* ctx)
>  {
> 	void* mem = ctx->alloc(32);
> 	ctx->info("Allocated 32 bytes @ %p", mem);
> 	mem = ctx->realloc(mem, 64);
> 	ctx->warn("Reallocated to %p", mem)
> 	ctx->dealloc(mem);
> 	ctx->err("Catastrophe, %p is gone!", mem)
>  }
> 
> The structure is passed around to all functions of the API,
> allowing for messages to come out from wherever.
> 
> Now, when it comes to interface to liblwgeom, we basically
> loose any possibility to hook on the context, as liblwgeom
> relies on that lib-static set of routines instead.
> 
> As an aim to integration I could drop the thread-safety
> as a whole and use the same schema for those utility
> functions. Or, we can modify lots of liblwgeom to allow
> for thread-safety.
> 
> Your thougths on the matter ?


Hi strk,

I am actually not opposed to making the liblwgeom API thread-safe as I 
think this would be a good thing, and I like your function pointer 
notation above.

In terms of work required, it won't really affect the user interface and 
  if there are any bugs then they will show up fairly quickly - it's 
mainly just spending the time to redo all of the function calls. The 
hard part will be working out how to pass the context into PostGIS after 
PostgreSQL startup, since we are aiming to support 8.1, and 8.1 doesn't 
have PG_init.

In short, if you wish to do the work and provide a patch, I'd be happy 
to help you with it.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063


From strk at keybit.net  Mon Jan 26 04:22:55 2009
From: strk at keybit.net (strk)
Date: Mon, 26 Jan 2009 13:22:55 +0100
Subject: [postgis-devel] WKTRaster & liblwgeom : thread safety
In-Reply-To: <497DA469.1010309@siriusit.co.uk>
References: <20090126105140.GC75703@keybit.net>
	<497DA469.1010309@siriusit.co.uk>
Message-ID: <20090126122255.GE75703@keybit.net>

On Mon, Jan 26, 2009 at 11:54:17AM +0000, Mark Cave-Ayland wrote:

> In terms of work required, it won't really affect the user interface and 
>  if there are any bugs then they will show up fairly quickly - it's 
> mainly just spending the time to redo all of the function calls. The 
> hard part will be working out how to pass the context into PostGIS after 
> PostgreSQL startup, since we are aiming to support 8.1, and 8.1 doesn't 
> have PG_init.

We're currently calling the externally-provided lwgeom_init_allocators
everytime an allocation/release/message is required, might as 
well call the context-retriving function at PostgreSQL function
entry point instead. Would be even less calls.

We could cache the context in the extention lib (in a function-static)
like this:

static rt_context
get_context(FunctionCallInfoData *fcinfo)
{
    MemoryContext old_context;
    static rt_context ctx=0;

    if ( ctx ) return ctx;

    /* We switch memory context info so the rt_context
     * is not freed by the end of function call
     * TODO: check _which_ context we should be using
     * for a whole-plugin-lifetime persistence */
    old_context = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
    ctx = rt_context_new(rt_pgalloc, rt_pgrealloc, rt_pgfree);
    MemoryContextSwitchTo(old_context);

    rt_context_set_message_handlers(ctx, rt_pgerr, rt_pgwarn, rt_pginfo);

    return ctx;
}

Then obtain the context from functions:

 PG_FUNCTION_INFO_V1(RASTER_in);
 Datum RASTER_in(PG_FUNCTION_ARGS)
 {
   rt_context ctx = get_context(fcinfo);
   ...
 }

For liblwgeom it will be an lw_context most likely,
and our rt_context could hold a pointer to lw_context itself
for use of liblwgeom...

> In short, if you wish to do the work and provide a patch, I'd be happy 
> to help you with it.

Right. Lots of work though, not sure it's worth the current
fundings for WKTRaster.

--strk;


From mwtoews at sfu.ca  Mon Jan 26 21:52:08 2009
From: mwtoews at sfu.ca (Michael Toews)
Date: Mon, 26 Jan 2009 21:52:08 -0800 (PST)
Subject: [postgis-devel] shp2pgsql bug interpreting data type
In-Reply-To: <1889006313.182651233035511662.JavaMail.root@jaguar9.sfu.ca>
Message-ID: <941551879.182671233035528241.JavaMail.root@jaguar9.sfu.ca>

Hi,

I've tried loading SHP data from a Canadian topo data source CanVec http://geogratis.gc.ca/geogratis/en/product/search.do?id=28954 (try searching 094a02). But I get errors with 094a02_3_0_TR_1190009_2.shp:

> shp2pgsql -s 4326 -c 094a02_3_0_TR_1190009_2.shp tr_119 > tr_119.sql
Shapefile type: Polygon
Postgis type: MULTIPOLYGON[2]

> psql -U postgres -f tr_119.sql postgis
BEGIN
psql:tr_119.sql:12: NOTICE:  CREATE TABLE will create implicit sequence "tr_119_gid_seq" for serial column "tr_119.gid"
psql:tr_119.sql:12: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "tr_119_pkey" for table "tr_119"
CREATE TABLE
                     addgeometrycolumn
-----------------------------------------------------------
 public.tr_119.the_geom SRID:4326 TYPE:MULTIPOLYGON DIMS:2

(1 row)
psql:tr_119.sql:14: ERROR:  invalid input syntax for integer: "-"
psql:tr_119.sql:15: ERROR:  current transaction is aborted, commands ignored until end of transaction block
ROLLBACK



The error here is appears to be two-fold. In this particular dataset, the column "id_canac" is interpreted to be int4, but OGR sees the datatype as double precision (as established by ogrinfo and ogr2ogr to the same PG database). Secondly, the value '-' is attempted to be inserted into "id_canac" which doesn't work for either int4 or float8 datatypes.

Here is my version info of shp2pgsql:
RCSID: $Id: shp2pgsql.c 2764 2008-04-12 16:44:55Z pramsey $ RELEASE: 1.3.3


From strk at keybit.net  Tue Jan 27 07:41:50 2009
From: strk at keybit.net (strk)
Date: Tue, 27 Jan 2009 16:41:50 +0100
Subject: [postgis-devel] WKTRaster: RASTER and CHIP
In-Reply-To: <4970C48E.7010409@siriusit.co.uk>
References: <20090114093637.GD87941@keybit.net>
	<4970C0DF.1030407@refractions.net>
	<53F9CF533E1AA14EA1F8C5C08ABC08D2054B8661@ZDND.DND.boston.cob>
	<4970C48E.7010409@siriusit.co.uk>
Message-ID: <20090127154150.GB11944@keybit.net>

On Fri, Jan 16, 2009 at 05:31:58PM +0000, Mark Cave-Ayland wrote:

> I think Paul summarised in his email what I was saying but in much fewer 
> words; working in a branch is kinda okay as long as the WKTRaster 
> developers don't mind constant merging from trunk/fixing things based on 
> changes to the PostGIS core. Although my feeling is for the initial cut, 
> it may be less work to host the project independently and do a first 
> merge when it reaches a relatively stable point.

I think we found a good compromise by using the 'spike'
subdir of posgis SVN root, as per Paul suggestion and thanks
to Kevin.

It is an isolated spot so won't pollute distribution
or svn checkouts (unless pulled from the root).

 http://svn.refractions.net/postgis/spike/wktraster/

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From Pierre.Racine at sbf.ulaval.ca  Tue Jan 27 12:52:19 2009
From: Pierre.Racine at sbf.ulaval.ca (Pierre Racine)
Date: Tue, 27 Jan 2009 15:52:19 -0500
Subject: [postgis-devel]Enabling Tables or HTML in the PostGIS Wiki]
In-Reply-To: <4970BEC0.50701@refractions.net>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F430E@exch-be03.ulaval.ca>	<D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca><20090116151137.GF44057@keybit.net>
	<4970BEC0.50701@refractions.net>
Message-ID: <D58FF82475EA0A4A9347D3CE16B46E5F6F4BCC@exch-be03.ulaval.ca>

Hi Kevin,

We are in a crucial phase of the PostGIS WKT Raster project where we
need to convince some more people to fund the project. To do this I have
to make an attractive web page with a schedule and with what has been
funded up to now. I use to be a very creative person but I can't figure
how I'm going to do this without doing a sort of table of something
similar.

If, really, it is not possible to enabling HTML or anything else helping
us to do nicer pages soon, I will have to move the page somewhere else.
I would much more prefer to keep this page in the PostGIS wiki. I think
this is where it should be and this is a hearthbreaking decision.

Can we get this fixed soon? If not please let me know.

http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage

Pierre

>-----Original Message-----
>From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-
>bounces at postgis.refractions.net] On Behalf Of Kevin Neufeld
>Sent: 16 janvier 2009 12:07
>To: PostGIS Development Discussion
>Subject: Re: [postgis-devel]Enabling Tables or HTML in the PostGIS
Wiki]
>
>If that works...
>
>Sorry guys this is taking so long.  I keep bugging the high-ups to
allocate some resources to address
>this.  I know
>we're swamped right now making several fiscal-end deliveries which
probably plays part to the delay.
>
>-- Kevin
>
>strk wrote:
>> On Fri, Jan 16, 2009 at 09:58:39AM -0500, Pierre Racine wrote:
>>> Kevin,
>>>
>>> Any news on this? The wiki is very limited (no images, no files, no
tables). We won't be able to
>construct a real contributor community with those limitations.
>>
>> I suggest you register the project on http://savannah.nongnu.org.
>> It takes time so the earlier the better.
>> Not that it provides a wiki actually, but it has RCS and trackers,
>> and web space (under cvs).
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel


From kneufeld at refractions.net  Tue Jan 27 13:08:26 2009
From: kneufeld at refractions.net (Kevin Neufeld)
Date: Tue, 27 Jan 2009 13:08:26 -0800
Subject: [postgis-devel]Enabling Tables or HTML in the PostGIS Wiki]
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F4BCC@exch-be03.ulaval.ca>
References: <D58FF82475EA0A4A9347D3CE16B46E5F6F430E@exch-be03.ulaval.ca>	<D58FF82475EA0A4A9347D3CE16B46E5F6F4386@exch-be03.ulaval.ca><20090116151137.GF44057@keybit.net>
	<4970BEC0.50701@refractions.net>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F4BCC@exch-be03.ulaval.ca>
Message-ID: <497F77CA.4090209@refractions.net>

Hi Pierre.  I totally hear you and also think it would be really really 
nice to have such a capability.  Once again, I'll forward your request 
to Jeff, our resourcing department head, so he can reply to you.  I'm 
not sure, but I think that part of the problem is that the wiki is so 
old, the feature is not even available to enable and would require a new 
installation or different wiki system.  Either way, Jeff should get back 
to you shortly.

Cheers,
Kevin.

Pierre Racine wrote:
> Hi Kevin,
>
> We are in a crucial phase of the PostGIS WKT Raster project where we
> need to convince some more people to fund the project. To do this I have
> to make an attractive web page with a schedule and with what has been
> funded up to now. I use to be a very creative person but I can't figure
> how I'm going to do this without doing a sort of table of something
> similar.
>
> If, really, it is not possible to enabling HTML or anything else helping
> us to do nicer pages soon, I will have to move the page somewhere else.
> I would much more prefer to keep this page in the PostGIS wiki. I think
> this is where it should be and this is a hearthbreaking decision.
>
> Can we get this fixed soon? If not please let me know.
>
> http://postgis.refractions.net/support/wiki/index.php?WKTRasterHomePage
>
> Pierre
>
>   
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>>     
> [mailto:postgis-devel-
>   
>> bounces at postgis.refractions.net] On Behalf Of Kevin Neufeld
>> Sent: 16 janvier 2009 12:07
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel]Enabling Tables or HTML in the PostGIS
>>     
> Wiki]
>   
>> If that works...
>>
>> Sorry guys this is taking so long.  I keep bugging the high-ups to
>>     
> allocate some resources to address
>   
>> this.  I know
>> we're swamped right now making several fiscal-end deliveries which
>>     
> probably plays part to the delay.
>   
>> -- Kevin
>>
>> strk wrote:
>>     
>>> On Fri, Jan 16, 2009 at 09:58:39AM -0500, Pierre Racine wrote:
>>>       
>>>> Kevin,
>>>>
>>>> Any news on this? The wiki is very limited (no images, no files, no
>>>>         
> tables). We won't be able to
>   
>> construct a real contributor community with those limitations.
>>     
>>> I suggest you register the project on http://savannah.nongnu.org.
>>> It takes time so the earlier the better.
>>> Not that it provides a wiki actually, but it has RCS and trackers,
>>> and web space (under cvs).
>>>
>>> --strk;
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>       
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>     


From strk at keybit.net  Wed Jan 28 03:39:53 2009
From: strk at keybit.net (strk)
Date: Wed, 28 Jan 2009 12:39:53 +0100
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
Message-ID: <20090128113953.GB31668@keybit.net>

I've been approved fundings for second phase of first step
for WKTRaster project, which involves definition of the on-disk
format for it.

If anyone is interested, the RFC is here:

http://svn.refractions.net/postgis/spike/wktraster/doc/RFC1-SerializedFormat

It might be of interest for GEOMETRY as well in that
it defines a "version" field in the format, which would be
useful in case you'll change the on-disk format too, to reduce
problems deriving from further changing of the format
(hwgeom to lwgeom wasn't a walk in the park)

Comments welcome.

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From strk at keybit.net  Wed Jan 28 14:51:38 2009
From: strk at keybit.net (strk)
Date: Wed, 28 Jan 2009 23:51:38 +0100
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <20090128113953.GB31668@keybit.net>
References: <20090128113953.GB31668@keybit.net>
Message-ID: <20090128225138.GD46558@keybit.net>

On Wed, Jan 28, 2009 at 12:39:53PM +0100, strk wrote:

> http://svn.refractions.net/postgis/spike/wktraster/doc/RFC1-SerializedFormat

RFC updated to take into account off-db storage and bigger precision
on insertion points. 

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From codesite-noreply at google.com  Wed Jan 28 18:04:54 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 29 Jan 2009 02:04:54 +0000
Subject: [postgis-devel] Issue 106 in postgis: pgsql2shp memory leak on
	WIndows
Message-ID: <0016e644cc68af0f18046195837d@google.com>

Status: New
Owner: ----

New issue 106 by krellor: pgsql2shp memory leak on WIndows
http://code.google.com/p/postgis/issues/detail?id=106

What steps will reproduce the problem?
1. Export NHD table to shp file using pgsql2shp.exe


What is the expected output? What do you see instead?

After 3.1 million records exported the process fails giving a generic
fwrite() error.  The expected output is a shp file.

What version of the product are you using? On what operating system?

1.3.5 on 32bit Windows XP pro, and 32bit Windows Vista Business

Please provide any additional information below.

I have a table that holds the flowline hydrography of Washington State.
When I export to shapefile on Windows XP the processes memory usage swells
to 1.6GB and then fails with a generic fwrite() error.  When I attach my
debugger to the running process I see a Heap Coruption error for every
single row exported.  I've looked at the source but don't see anything that
stands out as an error.  I tried re-building with cygwin changing it to be
more verbose, but ran into some problems.

On Windows Vista Business windows terminates the process on the first row,
presumably because it has stricter memory management than Windows XP, which
only fails when the system is out of memory.  On Windows XP I tried
breaking up the 4 million records across 4 tables, 1 million records each.
  I was able to successfully export them that way so I know it is not a
problem with the data.  And like I said, every single row exported throws a
Heap Corruption error.



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From strk at keybit.net  Thu Jan 29 01:31:43 2009
From: strk at keybit.net (strk)
Date: Thu, 29 Jan 2009 10:31:43 +0100
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <20090128225138.GD46558@keybit.net>
References: <20090128113953.GB31668@keybit.net>
	<20090128225138.GD46558@keybit.net>
Message-ID: <20090129093143.GA50412@keybit.net>

On Wed, Jan 28, 2009 at 11:51:38PM +0100, strk wrote:
> On Wed, Jan 28, 2009 at 12:39:53PM +0100, strk wrote:
> 
> > http://svn.refractions.net/postgis/spike/wktraster/doc/RFC1-SerializedFormat
> 
> RFC updated to take into account off-db storage and bigger precision
> on insertion points. 

I fluffed the header some more, so to have all doubles
for georeference. After all what does it pay to have a mixed
float/double georef ? (and GDAL uses double precision for that).

Also added example total sizes of single band on-disk rasters.
A 64x64 16bit band won't fit in a default potgresql page size,
an 8bit band of that dimension would.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From codesite-noreply at google.com  Thu Jan 29 04:42:58 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 29 Jan 2009 12:42:58 +0000
Subject: [postgis-devel] Issue 106 in postgis: pgsql2shp memory leak on
	WIndows
Message-ID: <00163691ff329b88e304619e6d9e@google.com>

Updates:
	Owner: robe.... at cityofboston.gov

Comment #1 on issue 106 by robe.... at cityofboston.gov: pgsql2shp memory leak  
on WIndows
http://code.google.com/p/postgis/issues/detail?id=106

Krellor,

Can you try the 1.3.6SVN build.  I had fixed the Windows Vista crash  
problem in that
version, though your other issue probably still exists in that version,  
though maybe
not because the main change in 1.3.6 was changing how we release memory.

If you need a windows precompiled version -- I have one here which is from  
December
but should be good enough.

http://www.bostongis.com/downloads/pgutils/pgsql2shp136patched.zip

Alas another victim.  If you have a non -1 SRID, can you verify that it  
also outputs
a .prj file and if you have something like ArcGIS or some other .prj aware  
app, that
it reads it correctly.  Works for me, but haven't gotten anyone else to  
verify.

Thanks,
Regina

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From Pierre.Racine at sbf.ulaval.ca  Thu Jan 29 06:17:49 2009
From: Pierre.Racine at sbf.ulaval.ca (Pierre Racine)
Date: Thu, 29 Jan 2009 09:17:49 -0500
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <20090129093143.GA50412@keybit.net>
References: <20090128113953.GB31668@keybit.net>
	<20090128225138.GD46558@keybit.net>
	<20090129093143.GA50412@keybit.net>
Message-ID: <D58FF82475EA0A4A9347D3CE16B46E5F6F4D1E@exch-be03.ulaval.ca>

>Also added example total sizes of single band on-disk rasters.
>A 64x64 16bit band won't fit in a default potgresql page size,
>an 8bit band of that dimension would.

Nice work. I always wondered what were the implications of working with
data bigger than the page size.

Pierre


From strk at keybit.net  Thu Jan 29 07:35:06 2009
From: strk at keybit.net (strk)
Date: Thu, 29 Jan 2009 16:35:06 +0100
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <D58FF82475EA0A4A9347D3CE16B46E5F6F4D1E@exch-be03.ulaval.ca>
References: <20090128113953.GB31668@keybit.net>
	<20090128225138.GD46558@keybit.net>
	<20090129093143.GA50412@keybit.net>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F4D1E@exch-be03.ulaval.ca>
Message-ID: <20090129153506.GA61110@keybit.net>

On Thu, Jan 29, 2009 at 09:17:49AM -0500, Pierre Racine wrote:
> >Also added example total sizes of single band on-disk rasters.
> >A 64x64 16bit band won't fit in a default potgresql page size,
> >an 8bit band of that dimension would.
> 
> Nice work. I always wondered what were the implications of working with
> data bigger than the page size.

Data that fits in a page size won't need to be compressed
or stored in a separate table (the TOAST table), so it more
quickly gets loaded into memory.

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From strk at keybit.net  Thu Jan 29 09:39:04 2009
From: strk at keybit.net (strk)
Date: Thu, 29 Jan 2009 18:39:04 +0100
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <20090129153506.GA61110@keybit.net>
References: <20090128113953.GB31668@keybit.net>
	<20090128225138.GD46558@keybit.net>
	<20090129093143.GA50412@keybit.net>
	<D58FF82475EA0A4A9347D3CE16B46E5F6F4D1E@exch-be03.ulaval.ca>
	<20090129153506.GA61110@keybit.net>
Message-ID: <20090129173904.GA68289@keybit.net>

On Thu, Jan 29, 2009 at 04:35:06PM +0100, strk wrote:
> On Thu, Jan 29, 2009 at 09:17:49AM -0500, Pierre Racine wrote:
> > >Also added example total sizes of single band on-disk rasters.
> > >A 64x64 16bit band won't fit in a default potgresql page size,
> > >an 8bit band of that dimension would.
> > 
> > Nice work. I always wondered what were the implications of working with
> > data bigger than the page size.
> 
> Data that fits in a page size won't need to be compressed
> or stored in a separate table (the TOAST table), so it more
> quickly gets loaded into memory.

Since we're on the matter, last thing I'd like we all agree
on is the size (in bits) of values for pixeltype in (PT_1BB,
PT_2BUI, PT_4BUI).

These could be encoded as 1bit, 2bit, 4bit respectively,
saving space on disk, but requiring more CPU cycles to read.
Or could be encoded all as 8bit, making things simpler to
manage but saving nothing.

Beside, it seems GDAL doesn't support pixel types with length < 8bit.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From strk at keybit.net  Thu Jan 29 13:16:16 2009
From: strk at keybit.net (strk)
Date: Thu, 29 Jan 2009 22:16:16 +0100
Subject: [postgis-devel] WKTRaster: canonical i/o (and WKB)
Message-ID: <20090129211616.GB68289@keybit.net>

Second RFC for rasters: WKB.
http://svn.refractions.net/postgis/spike/wktraster/doc/RFC2-WellKnownBinaryFormat

The WellKnownBinary format is modeled after the serialied format,
except from adding an endian field at the start and removing
padding.

For matching endiannes, dropping the padding means we'll be forced
to scan all the band values.  When endiannes mismatches we'll be forced
to scan all band values with isOffline flag clear and pixtype of
size > 8bit.

As usual, comments are welcome.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From strk at keybit.net  Thu Jan 29 13:21:47 2009
From: strk at keybit.net (strk)
Date: Thu, 29 Jan 2009 22:21:47 +0100
Subject: [gdal-dev] Fwd: [postgis-devel] WKTRaster: RFC1: serialized form
In-Reply-To: <49821422.7090404@pobox.com>
References: <20090128113953.GB31668@keybit.net>
	<30fe546d0901281019y18d265dexd153584cb7369191@mail.gmail.com>
	<4980BEFA.4010502@pobox.com> <20090128224435.GB46558@keybit.net>
	<49821422.7090404@pobox.com>
Message-ID: <20090129212147.GC68289@keybit.net>

On Thu, Jan 29, 2009 at 03:40:02PM -0500, Frank Warmerdam wrote:

> Issues that I was not clear on included knowing how important it was for
> the structure to be small (ie. what are typical raster tile sizes, etc)

That's a good question for Pierre, having knowlege of the 
analisys use cases.

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 


From codesite-noreply at google.com  Thu Jan 29 15:42:35 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 29 Jan 2009 23:42:35 +0000
Subject: [postgis-devel] Issue 106 in postgis: pgsql2shp memory leak on
	WIndows
Message-ID: <0016e64079c094e2a00461a7a49b@google.com>


Comment #2 on issue 106 by krellor: pgsql2shp memory leak on WIndows
http://code.google.com/p/postgis/issues/detail?id=106

I have downloaded your compiled exe and will try again this evening and see  
if it
still throwing heap corruptions or not.  I will also test the projection  
file and
make sure it reads properly.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Thu Jan 29 21:38:54 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 30 Jan 2009 05:38:54 +0000
Subject: [postgis-devel] Issue 108 in postgis: ST_LineToCurve Crashing
Message-ID: <0016368e1c09de30730461ac9e40@google.com>

Status: New
Owner: ----

New issue 108 by rbroamer: ST_LineToCurve Crashing
http://code.google.com/p/postgis/issues/detail?id=108

What steps will reproduce the problem?

=> SELECT ST_LineToCurve('LINESTRING(-13151357.927248 3913656.64539871,-
13151419.0845266 3913664.12016378,-13151441.323537 3913666.61175286,-
13151456.8908442 3913666.61175286,-13151476.9059536 3913666.61175286,-
13151496.921063 3913666.61175287,-13151521.3839744 3913666.61175287,-
13151591.4368571 3913665.36595828)');
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

This is running on TODAY's PostGIS SVN and GEOS 3.1.0RC1. It's on a 32-bit  
Ubuntu 8 LTS box
with PostgreSQL 8.3.5. Had the same problem with 1.3.4.



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan 30 05:11:18 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 30 Jan 2009 13:11:18 +0000
Subject: [postgis-devel] Issue 109 in postgis: Some operators not supported
	for Circular
Message-ID: <00163630f1d7c7a1eb0461b2f03d@google.com>

Status: Accepted
Owner: ----
Labels: Milestone-1.4 Type-Defect Priority-Low

New issue 109 by robe.... at cityofboston.gov: Some operators not supported  
for Circular
http://code.google.com/p/postgis/issues/detail?id=109

What steps will reproduce the problem?
1.
                         SELECT foo1.the_geom ~= foo2.the_geom
                                         FROM ((SELECT
ST_LineToCurve(ST_Buffer(ST_SetSRID(ST_Point(i,j),4326), j))  As the_geom
                 FROM generate_series(-10,50,10) As i
                         CROSS JOIN generate_series(40,70, 20) As j)) As
foo1 CROSS JOIN ((SELECT
ST_LineToCurve(ST_Buffer(ST_SetSRID(ST_Point(i,j),4326), j))  As the_geom
                 FROM generate_series(-10,50,10) As i
                         CROSS JOIN generate_series(40,70, 20) As j)) As foo2
                                         LIMIT 3;

What is the expected output? Either not supported for x and y or for it to
do something
What do you see instead?
psql:torturetest.sql:22279: ERROR:  lwgeom_same: unknown geometry type: 13
psql:torturetest.sql:22555: ERROR:  lwgeom_same: unknown geometry type: 8


I've only tested against latest 1.4.  I'm not sure how hard it is to get
these to support circular or if its important, but should at least give the
type descriptor instead of number.

I also haven't checked log to see how many of these throw this error.



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


From codesite-noreply at google.com  Fri Jan 30 07:44:01 2009
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 30 Jan 2009 15:44:01 +0000
Subject: [postgis-devel] Issue 108 in postgis: ST_LineToCurve Crashing
Message-ID: <000e0cd40332f13edb0461b51289@google.com>

Updates:
	Status: Accepted
	Labels: Type-Defect Priority-High Milestone-1.3.X

Comment #1 on issue 108 by robe.... at cityofboston.gov: ST_LineToCurve  
Crashing
http://code.google.com/p/postgis/issues/detail?id=108

This fails on my 1.4 build too so still seems outstanding.  This may be a  
different
symptom of Issue 86.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings