headers
L Bogert-O'Brien | 1 Sep 2010 01:31
Picon
Favicon

ST_Difference and ST_Buffer queries

Hi,

When I used ST_Difference to clip one polygon from another where part 
of the border of the polygon used for clipping is coincident with 
part of the border of the one that is being clipped, I got a border 
left which was not part of the main part of the polygon I wanted to keep.

A simple example:
I want to clip this:

|
|            xxxxxxx
|            xxxxxxx
|            xxxxxxx
|            xxxxxxx
|            xxxxxxx
|            xxxxxxx
------------------------------------

With this:
|
|     oooooooooooooo
|     oooooooooooooo
|     oooooooooooooo
|
|
|
-------------------------------------

And I get this result:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Rykov | 1 Sep 2010 03:21
Picon
Gravatar

ERROR: You need GEOS-3.3.0 or up for ST_MakeValid

Hi, just updated GEOS to 3.3.0, but when try to use function
ST_MakeValid I get an error "ERROR:  You need GEOS-3.3.0 or up for
ST_MakeValid".
SELECT postgis_full_version() returns "POSTGIS="2.0.0SVN"
GEOS="3.3.0-CAPI-1.7.0" PROJ="Rel. 4.7.1, 23 September 2009"
LIBXML="2.7.6" USE_STATS"
Permalink | Reply | 1 comment |
headers
Denis Rykov | 1 Sep 2010 03:34
Picon
Gravatar

Size of .dbf file produced with pgsql2shp

Just updated pgsql2shp from svn and try to use it: pgsql2shp -f
arkhan.shp osm "SELECT st_intersection as geom  from arkhan_line_attr
WHERE tourism<>''"

If SELECT returns empty table I get notice:
ERROR: Could not determine geometry type (empty table).
Done (postgis major version: 2).
Output shape: Null Shape
Dumping: [0 rows].

At result pgsql2shp produce one .dbf file with 256 Bytes size. Some
days ago, before updating pgsql2shp, size of such .dbf file was 1
Byte.
I use size of this empty *.dbf file in my script. Need I change this
value to 226 or this is a bug?
Permalink | Reply | 13 comments |
headers
strk | 1 Sep 2010 11:30
Gravatar

Re: ST_Difference and ST_Buffer queries

On Tue, Aug 31, 2010 at 07:31:23PM -0400, L Bogert-O'Brien wrote:

> Does anyone have an alternate suggestion that would get rid of these 
> unwanted borders, that would not involve changing the size of the 
> polygon used for clipping?

What you could do is drop all components of your geometry where
the area is below a given value (including holes, I'd say).

It'd be useful to have the above functionality in a function,
possibly taking the threshold as a factor of total area.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
Permalink | Reply | 0 comments |
headers
strk | 1 Sep 2010 11:32
Gravatar

Re: ERROR: You need GEOS-3.3.0 or up for ST_MakeValid

On Wed, Sep 01, 2010 at 08:21:30AM +0700, Denis Rykov wrote:
> Hi, just updated GEOS to 3.3.0, but when try to use function
> ST_MakeValid I get an error "ERROR:  You need GEOS-3.3.0 or up for
> ST_MakeValid".
> SELECT postgis_full_version() returns "POSTGIS="2.0.0SVN"
> GEOS="3.3.0-CAPI-1.7.0" PROJ="Rel. 4.7.1, 23 September 2009"
> LIBXML="2.7.6" USE_STATS"

You need to configure, build and install postgis library 
again for that function to work.

--strk;
Permalink | Reply | 0 comments |
headers
Mark Cave-Ayland | 1 Sep 2010 13:03
Picon

Re: Size of .dbf file produced with pgsql2shp

Denis Rykov wrote:

> Just updated pgsql2shp from svn and try to use it: pgsql2shp -f
> arkhan.shp osm "SELECT st_intersection as geom  from arkhan_line_attr
> WHERE tourism<>''"
> 
> If SELECT returns empty table I get notice:
> ERROR: Could not determine geometry type (empty table).
> Done (postgis major version: 2).
> Output shape: Null Shape
> Dumping: [0 rows].
> 
> At result pgsql2shp produce one .dbf file with 256 Bytes size. Some
> days ago, before updating pgsql2shp, size of such .dbf file was 1
> Byte.
> I use size of this empty *.dbf file in my script. Need I change this
> value to 226 or this is a bug?

Checking the resulting file size is not the right way to be trying to 
detect whether the query returned > 0 rows. It strikes me that the best 
way to detect this would be to return a different exit code from 
pgsql2shp if no rows are returned - would this work for you?

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
(Continue reading)

Permalink | Reply | 12 comments |
headers
strk | 1 Sep 2010 16:49
Gravatar

Re: Size of .dbf file produced with pgsql2shp

On Wed, Sep 01, 2010 at 12:03:36PM +0100, Mark Cave-Ayland wrote:
> Denis Rykov wrote:
> 
> >ERROR: Could not determine geometry type (empty table).
> >Done (postgis major version: 2).
> >Output shape: Null Shape
> >Dumping: [0 rows].
>
> Checking the resulting file size is not the right way to be trying to 
> detect whether the query returned > 0 rows. It strikes me that the best 
> way to detect this would be to return a different exit code from 
> pgsql2shp if no rows are returned - would this work for you?

I'd go stricter to "if an ERROR occurred" rather than 
"if no rows are returned".

Just in case one day we'll add a flag to specify the geometry type
thus allowing creation of empty-but-structuted shapefiles starting
from a table "template".

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
Permalink | Reply | 5 comments |
headers
Denis Rykov | 1 Sep 2010 18:59
Picon
Gravatar

Re: Size of .dbf file produced with pgsql2shp

It would be great if you can add an exit code for 0 records dbfs,
it'll make my life so much easier.

2010/9/1 Mark Cave-Ayland <mark.cave-ayland <at> siriusit.co.uk>:
> Denis Rykov wrote:
>
>> Just updated pgsql2shp from svn and try to use it: pgsql2shp -f
>> arkhan.shp osm "SELECT st_intersection as geom  from arkhan_line_attr
>> WHERE tourism<>''"
>>
>> If SELECT returns empty table I get notice:
>> ERROR: Could not determine geometry type (empty table).
>> Done (postgis major version: 2).
>> Output shape: Null Shape
>> Dumping: [0 rows].
>>
>> At result pgsql2shp produce one .dbf file with 256 Bytes size. Some
>> days ago, before updating pgsql2shp, size of such .dbf file was 1
>> Byte.
>> I use size of this empty *.dbf file in my script. Need I change this
>> value to 226 or this is a bug?
>
> Checking the resulting file size is not the right way to be trying to detect
> whether the query returned > 0 rows. It strikes me that the best way to
> detect this would be to return a different exit code from pgsql2shp if no
> rows are returned - would this work for you?
>
>
> ATB,
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Cave-Ayland | 1 Sep 2010 19:29
Picon

Re: Size of .dbf file produced with pgsql2shp

strk wrote:

>> Checking the resulting file size is not the right way to be trying to 
>> detect whether the query returned > 0 rows. It strikes me that the best 
>> way to detect this would be to return a different exit code from 
>> pgsql2shp if no rows are returned - would this work for you?
> 
> I'd go stricter to "if an ERROR occurred" rather than 
> "if no rows are returned".
> 
> Just in case one day we'll add a flag to specify the geometry type
> thus allowing creation of empty-but-structuted shapefiles starting
> from a table "template".
> 
> --strk;

This is exactly how the new code in trunk currently works - you get an 
exit code of 0 to indicate success, and an exit code of 1 if an error 
occurred. I was thinking of adding a new exit code of 2 to indicate 
success, but also that 0 records were processed.

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Cave-Ayland | 1 Sep 2010 19:41
Picon

Re: Size of .dbf file produced with pgsql2shp

Denis Rykov wrote:

> It would be great if you can add an exit code for 0 records dbfs,
> it'll make my life so much easier.

Okay done - it was quite a simple patch in the end. Can you update to 
SVN r5888 and confirm that you get an exit code of 0 on success, and 2 
if 0 records were processed?

ATB,

Mark.

--

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

Sirius Labs: http://www.siriusit.co.uk/labs
Permalink | Reply | 4 comments |

Gmane