Re: [postgis-users] Point in Polygon Problem

[pcreso]

Paul

I suggest you chaeck the XY coords in your data, it looks like you have 
mislabeled lat & lon, your "lat" values are > 90 & <180.

If you have loaded these into Postgis with the coords reversed, then they will 
not be in the correct location, which could be why ST_contains fails

Brent Wood

--- On Sat, 10/23/10, Marc Jansen  wrote:

From: Marc Jansen 
Subject: Re: [postgis-users] Point in Polygon Problem
To: postgis-users@postgis.refractions.net
Date: Saturday, October 23, 2010, 8:50 AM



  


  Hi Paul,



AFAICT you are using ST_Cointains correctly, and MultiPolygons
shouldn't be an issue. I assume that your geometries have the same
SRID, otherwise PostGIS would complain.



Can you post a full example (including the WKT of both geometries)
where you get false but expect true for ST_Contains(geomA, geomB)?



Something like:



SELECT ST_Contains('POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))',
'POINT(5 5)')  or

SELECT ST_Contains('MULTIPOLYGON(((0 0, 0 10, 10 10, 10 0, 0 0)))',
'POINT(5 5)')



so everyone can easily test this.



Both yield true for my -- ancient ;-) -- POSTGIS="1.3.5"
GEOS="3.0.3-CAPI-1.4.2" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS



Regards,

Marc









Am 22.10.2010 08:37, schrieb Marcos Paul:
Hi Folks, 

  

  I am trying to solve a simple problem: the point in polygon. First
  of all, I have a CSV file with the polygons in list similar to the
  WKT Format, that is something like: 

  

  
 
  
BUILT_UP_AREA_ID
VERTEX_SEQ
LATITUDE
LONGITUDE
  
  
1081
0
152.6657
-25.5206
  
  
1081
1
152.6662
-25.5211
  
  
1081
2
152.
-25.5216
  
  
1081
3
152.6673
-25.5224
  
  
1081
4
152.668
-25.523
  
  
1081
5
152.6694
-25.5247
  
  
1081
6
152.67
-25.5255
  
  
1081
7
152.6707
-25.5263
  
  
1081
8
152.6734
-25.5291
  
  
1081
9
152.6741
-25.5295
  
  
1081
10
152.6745
-25.5299
  
  
1081
11
152.675
-25.5301
  
  
1081
12
152.676
-25.5313
  
  
1081
13
152.6762
-25.5317
  
  
1081
14
152.6764
-25.5321
  
  
1081
15
152.6764
-25.5333
  
  
1081
16
152.6766
-25.534
  
  
1081
17
152.6766
-25.5341
  
  
1081
18
152.6771
-25.5341
  
  
1081
19
152.6774
-25.534
  
  
1081
20
152.6788
-25.5354
  
  
1081
21
152.6797
-25.5361
  
  
1081
22
152.6788
-25.5368


  

  
  

  

  From there I want to export that to my postgis data base, I solved
  that converting the CSV to a Shape file and then applying the
  shp2psql gui. 

  

  When I am trying to check if a particular point is inside my table
  I am just applying the following command: 

  

  select ST_ASTEXT(the_geom) as multipolygons FROM Table_Polygons
  WHERE ST_Contains(Table_Polygons.the_geom,
  ST_GeometryFromText('POINT(X,Y)')); 

  

  So after that, I am getting that the point X,Y is not inside one
  of the polygons of my file, when I am completely sure that this
  point is actually inside a polygon. 

  

  What I am doing wrong?  Does the fact that I am using
  Multipolygons affect at all? 

  

  Thank you for your help, 

  

  Paul

  

  

  
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users




  

-Inline At

Re: [postgis-users] Point in Polygon Problem

[Marc Jansen]

 Hi Paul,

AFAICT you are using ST_Cointains correctly, and MultiPolygons shouldn't 
be an issue. I assume that your geometries have the same SRID, otherwise 
PostGIS would complain.


Can you post a full example (including the WKT of both geometries) where 
you get false but expect true for ST_Contains(geomA, geomB)?


Something like:

SELECT ST_Contains('POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))', 'POINT(5 
5)')  or
SELECT ST_Contains('MULTIPOLYGON(((0 0, 0 10, 10 10, 10 0, 0 0)))', 
'POINT(5 5)')


so everyone can easily test this.

Both yield true for my -- ancient ;-) -- POSTGIS="1.3.5" 
GEOS="3.0.3-CAPI-1.4.2" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS


Regards,
Marc




Am 22.10.2010 08:37, schrieb Marcos Paul:

Hi Folks,

I am trying to solve a simple problem: the point in polygon. First of 
all, I have a CSV file with the polygons in list similar to the WKT 
Format, that is something like:


BUILT_UP_AREA_IDVERTEX_SEQ  LATITUDELONGITUDE
10810   152.6657-25.5206
10811   152.6662-25.5211
10812   152.-25.5216
10813   152.6673-25.5224
10814   152.668 -25.523
10815   152.6694-25.5247
10816   152.67  -25.5255
10817   152.6707-25.5263
10818   152.6734-25.5291
10819   152.6741-25.5295
108110  152.6745-25.5299
108111  152.675 -25.5301
108112  152.676 -25.5313
108113  152.6762-25.5317
108114  152.6764-25.5321
108115  152.6764-25.5333
108116  152.6766-25.534
108117  152.6766-25.5341
108118  152.6771-25.5341
108119  152.6774-25.534
108120  152.6788-25.5354
108121  152.6797-25.5361
108122  152.6788-25.5368



From there I want to export that to my postgis data base, I solved 
that converting the CSV to a Shape file and then applying the shp2psql 
gui.


When I am trying to check if a particular point is inside my table I 
am just applying the following command:


select ST_ASTEXT(the_geom) as multipolygons FROM Table_Polygons WHERE 
ST_Contains(Table_Polygons.the_geom, ST_GeometryFromText('POINT(X,Y)'));


So after that, I am getting that the point X,Y is not inside one of 
the polygons of my file, when I am completely sure that this point is 
actually inside a polygon.


What I am doing wrong?  Does the fact that I am using Multipolygons 
affect at all?


Thank you for your help,

Paul



___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_Simplify

[Kevin Neufeld]

That's what I thought ... my morning coffee hadn't kicked in yet :)

It still looks like PostGIS might benefit from a 
ShiftCoordinates(linearring geometry) function to solve this particular 
problem.

-- Kevin

On 10/22/2010 10:45 AM, David William Bitner wrote:
D-P simplification is not going to modify your start/end points. For a 
bit of reference on the Douglas-Peuker simplification algorithm, see 
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm


On Fri, Oct 22, 2010 at 11:13 AM, Kevin Neufeld 
mailto:kneuf...@refractions.net>> wrote:


I don't see any pdf posted, but that's ok, I get the idea.

Isn't that interesting.  To me, this looks like a robustness issue
with ST_Simplify.  Here, the starting point of the polygon's
exterior ring is not on the corner.

select
 st_astext(
   st_simplify(
 'POLYGON ((
   25 300,
   275 300,
   300 300,It
   300 275,
   300 25,
   300 0,
   275 0,
   25 0,
   0 0,
   0 25,
   0 275,
   0 300,
   25 300
  ))', 1
   )
 );
   st_astext
--
 POLYGON((25 300,300 300,300 0,0 0,0 300,25 300))
(1 row)

I don't know why, but I too was expecting to see something like:
POLYGON (( 0 300, 300 300, 300 0, 0 0, 0 300 ))

You almost could use a function that shifts the ordinates in the
exterior linear ring ... you could probably put something together
fairly quickly in plpgsql (extract the exterior ring, use
ST_GetPointN and ST_SetPointN, and rebuild the polygon).
Once shifted, the starting ordinance would be on the corner and
the (25 300) vertex would disappear with a rerun of ST_Simplify.

JTS has the same issue.

-- Kevin



On 10/22/2010 2:33 AM, lplateandy wrote:

Hi Kevin,

Hopefully the attached (hopefully) PDF will help to show what
i mean.

In producing the PDF i think i can see why the issue happens.
It seems that
the start and end point of the polygon geometery are the node
i was hoping
might be removed during the simplify process.

Not sure if there is a way around this?

I do realise there are ways for a simple rectangle etc to fix
this but the
example is mainly for illustration as the issue is a problem
in more complex
geometries.

Thanks

Andy


Kevin Neufeld wrote:

Hi Andy,

Can you post a small example?
-- Kevin


On 10/21/2010 10:02 AM, lplateandy wrote:

Hi,

I have, in the simplest example, a square polygon of 1
by 1 kilometer
size
with nodes every 25 meters.

I can use ST_Simplify (the_geom,5) to remove most of
the points.

However, for some reason i end up with the four corner
nodes and a fifth
node 25m clockwise from the top left corner.

In itself, this would be fine - 5 nodes is better than
160.

However, on some of the polygons, there are more
complex boundaries which
i
wish to smooth out using simplify. I would do this
with  ST_Simplify
(the_geom,26) example - going over the minimum 25
metres between  any
nodes.

In the example of the square with 5 nodes, the problem
i find then is
that
the top left node is removed and the one 25m clockwise
remains. The
result
is that i no longer have a 1km square but sloping
Western boundary
correctly
going 1km North South but incorrectly veering across
25m to the East.

Is there a way to remove the stray node so i am more
likely to maintain
my
overall polygon shape. I did try
st_simplifiypreservetopology but saw no
noticeable difference.

Hope that makes sense, any help much appreciated

Andy

___
postgis-users mailing list
postgis-users@postgis.refractions.net

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


http://old.nabble.com/file/p30027046/ST_simplify_issue.pdf
ST_simplify_issue.pdf

___
postgis-users mailing list
postgis-users@postgis.refractions.net

Re: [postgis-users] ST_Simplify

[David William Bitner]

D-P simplification is not going to modify your start/end points. For a bit
of reference on the Douglas-Peuker simplification algorithm, see
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm

On Fri, Oct 22, 2010 at 11:13 AM, Kevin Neufeld wrote:

> I don't see any pdf posted, but that's ok, I get the idea.
>
> Isn't that interesting.  To me, this looks like a robustness issue with
> ST_Simplify.  Here, the starting point of the polygon's exterior ring is not
> on the corner.
>
> select
>  st_astext(
>st_simplify(
>  'POLYGON ((
>25 300,
>275 300,
>300 300,
>300 275,
>300 25,
>300 0,
>275 0,
>25 0,
>0 0,
>0 25,
>0 275,
>0 300,
>25 300
>   ))', 1
>)
>  );
>st_astext
> --
>  POLYGON((25 300,300 300,300 0,0 0,0 300,25 300))
> (1 row)
>
> I don't know why, but I too was expecting to see something like:
> POLYGON (( 0 300, 300 300, 300 0, 0 0, 0 300 ))
>
> You almost could use a function that shifts the ordinates in the exterior
> linear ring ... you could probably put something together fairly quickly in
> plpgsql (extract the exterior ring, use ST_GetPointN and ST_SetPointN, and
> rebuild the polygon).
> Once shifted, the starting ordinance would be on the corner and the (25
> 300) vertex would disappear with a rerun of ST_Simplify.
>
> JTS has the same issue.
>
> -- Kevin
>
>
>
> On 10/22/2010 2:33 AM, lplateandy wrote:
>
>> Hi Kevin,
>>
>> Hopefully the attached (hopefully) PDF will help to show what i mean.
>>
>> In producing the PDF i think i can see why the issue happens. It seems
>> that
>> the start and end point of the polygon geometery are the node i was hoping
>> might be removed during the simplify process.
>>
>> Not sure if there is a way around this?
>>
>> I do realise there are ways for a simple rectangle etc to fix this but the
>> example is mainly for illustration as the issue is a problem in more
>> complex
>> geometries.
>>
>> Thanks
>>
>> Andy
>>
>>
>> Kevin Neufeld wrote:
>>
>>> Hi Andy,
>>>
>>> Can you post a small example?
>>> -- Kevin
>>>
>>>
>>> On 10/21/2010 10:02 AM, lplateandy wrote:
>>>
 Hi,

 I have, in the simplest example, a square polygon of 1 by 1 kilometer
 size
 with nodes every 25 meters.

 I can use ST_Simplify (the_geom,5) to remove most of the points.

 However, for some reason i end up with the four corner nodes and a fifth
 node 25m clockwise from the top left corner.

 In itself, this would be fine - 5 nodes is better than 160.

 However, on some of the polygons, there are more complex boundaries
 which
 i
 wish to smooth out using simplify. I would do this with  ST_Simplify
 (the_geom,26) example - going over the minimum 25 metres between  any
 nodes.

 In the example of the square with 5 nodes, the problem i find then is
 that
 the top left node is removed and the one 25m clockwise remains. The
 result
 is that i no longer have a 1km square but sloping Western boundary
 correctly
 going 1km North South but incorrectly veering across 25m to the East.

 Is there a way to remove the stray node so i am more likely to maintain
 my
 overall polygon shape. I did try st_simplifiypreservetopology but saw no
 noticeable difference.

 Hope that makes sense, any help much appreciated

 Andy

>>> ___
>>> postgis-users mailing list
>>> postgis-users@postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>
>>>  http://old.nabble.com/file/p30027046/ST_simplify_issue.pdf
>> ST_simplify_issue.pdf
>>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



-- 

David William Bitner
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Database restore fails with missing liblwgeom

[Paragon Corporation]

Lee,

No you can't ignore the type geometry does not exist error.

We usually do compressed tar  backups since you have more control over what
you restore and whether to ignore errors, overwrite etc etc.

I haven't tried restoring full dumps in a while, but they are mostly
designed for disaster recovery when you need to restore the whole server.  I
suspect its just overwriting the databases entirely so your new postgis
installs are being wiped out.

Couple of options come to mind
Option 1
 If you still have your old install do postgresql compressed  backup using
pg_dump   of the database and restore as we described
This might help
http://www.postgresonline.com/journal/archives/63-PostgreSQL-8.3-Pg_dump-Pg_
Restore-Cheatsheet-Overview.html

Option 2
1) Macro replace your dumpfile -- all references to liblwgeom.so change to
postgis-1.5.so
(You can use sed or perl or whatever you feel comfortable with) -- don't
recall the commands off hand.
2) then run the soft upgrade script in share/contrib/postgis-1.5 folder

The second option should work (then afterward do a soft upgrade) -- though
keep in mind haven't tested it but you will get some errors with functions
that have been removed etc.

Leo
http://www.postgis.us





-Original Message-
From: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Lee
Hughes
Sent: Thursday, October 21, 2010 6:55 PM
To: postgis-users@postgis.refractions.net
Subject: Re: [postgis-users] Database restore fails with missing liblwgeom

The databases were created by restoring the pg_dumpall backup, so I
installed Postgis (psql -d [yourdatabase] -f postgis.sql) in all of them and
tried the restore again, with the same errors. In addition to the liblwgeom
errors (below), which presumably I can ignore, the restore also errors with
"type geometry does not exist". Can I ignore those errors too?

Thanks for the help.

> Date: Tue, 19 Oct 2010 20:17:25 -0400
> From: "Paragon Corporation" 
> Subject: Re: [postgis-users] Database restore fails with missing
>   liblwgeom
> To: "'PostGIS Users Discussion'"
>   
> Message-ID: <61923d39edd5403cb5f5c31abab20...@j>
> Content-Type: text/plain; charset="us-ascii"
>
> Lee,
>
> The liblwgeom.so was renamed in postgis 1.4 to postgis-1.4... So, 
> postgis-1.5... So
>
> The easiest way to restore your data is to
>
> 1) Create a new database
> 2) install PostGIS 1.5  (the install files should bie in
> share/contrib/postgis-1.5
> 3) Then restore your data on top
> 4) You'll should then get errors that the functions already exist and 
> they will be skipped.  You may get some errors too about the 
> liblwgeom, but those you can ignore (unless you are using them)  since 
> they represent functions long ago deprecated that got taken out of
> postgis-1.5
>
> Leo
> http://www.postgis.us
>
>
>
> -Original Message-
> From: postgis-users-boun...@postgis.refractions.net
> [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of 
> Lee Hughes
> Sent: Tuesday, October 19, 2010 7:15 PM
> To: postgis-users@postgis.refractions.net
> Subject: [postgis-users] Database restore fails with missing liblwgeom
>
> Restoring a pg_dumpall backup from a Postgres 8.1.3 + Postgis 1.1.4 
> server on a Postgres 9 + Postgis 1.5.2 server fails with
>
> could not access file "$libdir/liblwgeom.so.1.1": No such file or 
> directory
>
> Postgis compiled/installed fine, and make check passed all tests.
> There are no files like liblwgeom.so anywhere on the server, just 
> liblwgeom.a and liblwgeom.h in /usr/local/src/postgis-1.5.2/liblwgeom/.
>
> Any ideas greatly appreciated.
>
> Thanks-
>
> Lee

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_Simplify

[Kevin Neufeld]

I don't see any pdf posted, but that's ok, I get the idea.

Isn't that interesting.  To me, this looks like a robustness issue with 
ST_Simplify.  Here, the starting point of the polygon's exterior ring is 
not on the corner.


select
  st_astext(
st_simplify(
  'POLYGON ((
25 300,
275 300,
300 300,
300 275,
300 25,
300 0,
275 0,
25 0,
0 0,
0 25,
0 275,
0 300,
25 300
   ))', 1
)
  );
st_astext
--
 POLYGON((25 300,300 300,300 0,0 0,0 300,25 300))
(1 row)

I don't know why, but I too was expecting to see something like:
POLYGON (( 0 300, 300 300, 300 0, 0 0, 0 300 ))

You almost could use a function that shifts the ordinates in the 
exterior linear ring ... you could probably put something together 
fairly quickly in plpgsql (extract the exterior ring, use ST_GetPointN 
and ST_SetPointN, and rebuild the polygon).
Once shifted, the starting ordinance would be on the corner and the (25 
300) vertex would disappear with a rerun of ST_Simplify.


JTS has the same issue.

-- Kevin


On 10/22/2010 2:33 AM, lplateandy wrote:

Hi Kevin,

Hopefully the attached (hopefully) PDF will help to show what i mean.

In producing the PDF i think i can see why the issue happens. It seems that
the start and end point of the polygon geometery are the node i was hoping
might be removed during the simplify process.

Not sure if there is a way around this?

I do realise there are ways for a simple rectangle etc to fix this but the
example is mainly for illustration as the issue is a problem in more complex
geometries.

Thanks

Andy


Kevin Neufeld wrote:

Hi Andy,

Can you post a small example?
-- Kevin


On 10/21/2010 10:02 AM, lplateandy wrote:

Hi,

I have, in the simplest example, a square polygon of 1 by 1 kilometer
size
with nodes every 25 meters.

I can use ST_Simplify (the_geom,5) to remove most of the points.

However, for some reason i end up with the four corner nodes and a fifth
node 25m clockwise from the top left corner.

In itself, this would be fine - 5 nodes is better than 160.

However, on some of the polygons, there are more complex boundaries which
i
wish to smooth out using simplify. I would do this with  ST_Simplify
(the_geom,26) example - going over the minimum 25 metres between  any
nodes.

In the example of the square with 5 nodes, the problem i find then is
that
the top left node is removed and the one 25m clockwise remains. The
result
is that i no longer have a 1km square but sloping Western boundary
correctly
going 1km North South but incorrectly veering across 25m to the East.

Is there a way to remove the stray node so i am more likely to maintain
my
overall polygon shape. I did try st_simplifiypreservetopology but saw no
noticeable difference.

Hope that makes sense, any help much appreciated

Andy

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



http://old.nabble.com/file/p30027046/ST_simplify_issue.pdf
ST_simplify_issue.pdf

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] issue while building postgis-1.5.2 with pg-9

[Mark Cave-Ayland]

Dharmendra Goyal wrote:


Hi Mark,

I added one CFLAG /GS- and security cookie related warnings went away 
but following symbols still could not be found:


c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridinfo.obj):(.text+0x6e7): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridinfo.obj):(.text+0x6fc): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridinfo.obj):(.text+0xade): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridinfo.obj):(.text+0xaf3): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridlist.obj):(.text+0x1a2): 
undefined reference to `_imp___wassert'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(PJ_tmerc.obj):(.text+0x917): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(PJ_robin.obj):(.text+0x2e): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(PJ_robin.obj):(.text+0x181): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(nad_intr.obj):(.text+0x21): 
undefined reference to `_ftol2_sse'
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(nad_intr.obj):(.text+0x42): 
undefined reference to `_ftol2_sse'

collect2: ld returned 1 exit status

This is coming at the time of linking:
dllwrap -o postgis-1.5.dll --dllname postgis-1.5.dll  --def 
libpostgis-1.5dll.def lwgeom_pg.o lwgeom_debug.o lwgeom_accum.o 
lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o 
lwgeom_inout.o lwgeom_estimate.o lwgeom_functions_basic.o lwgeom_gist.o 
lwgeom_btree.o lwgeom_transform.o lwgeom_box.o lwgeom_box3d.o 
lwgeom_box2dfloat4.o lwgeom_chip.o lwgeom_geos.o lwgeom_geos_prepared.o 
lwgeom_export.o lwgeom_svg.o lwgeom_gml.o lwgeom_kml.o lwgeom_geojson.o 
lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_triggers.o lwgeom_dump.o 
lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o 
geography_inout.o geography_gist.o geography_btree.o 
geography_estimate.o geography_measurement.o 
 -Lc:/PGINST~1.PUN/PGSQL-~1.1/lib -Wl,--allow-multiple-definition 
 -L/C/pgBuild/krb5/lib/i386 -L/C/pgBuild/OpenSSL/lib 
-L/C/pgBuild/zlib/lib -Wl,--as-needed   
-L/C/pginstaller.pune-repo/geos-3.1.1.staging/lib 
-L/C/pginstaller.pune-repo/proj-4.7.0.staging/lib -lgeos_c -lproj 
-L/c/pgBuild/libxml2_mingw/lib -lxml2 -lws2_32 ../liblwgeom/liblwgeom.a 
-Lc:/PGINST~1.PUN/PGSQL-~1.1/lib -lpostgres


Any clue...??

Regards,
Dharmendra


Sorry, I don't think I can help you any more :(

All the builds I have done in the past (as well as the current builds) 
are all done using MingW and they all appear to work fine. I guess it 
must be related something in your particular build environment. My 
suspicion would be that its something in the MSVC PROJ.4 project 
settings somewhere, but you'd need to ask someone who uses MSVC for more 
help.



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
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS Raster: Spec. for WKT and WKB?

[Pierre Racine]

>Great. But I also specifically meant if the way of binary encoding is stable?
>That's probably important for those application which read/write WKB
>with their own means i.a. without PostGIS libraries.

I am pretty confident it will stay stable until we add new stuff to it. 
Probably not before PostGIS 3.0 which is far away.

Pierre
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS Raster: Spec. for WKT and WKB?

[Stefan Keller]

> Exact. There are lots of things that we could include/discuss in WKB for 
> raster like:

Great. But I also specifically meant if the way of binary encoding is stable?
That's probably important for those application which read/write WKB
with their own means i.a. without PostGIS libraries.

-S.

2010/10/22 Pierre Racine :
>>> As I said: no. They are not specified in public. I wish there would have 
>>> been a public spec to tell
>>me how to store raster but there is not.
>>
>>I'd like to understand and support this better:
>>
>>1. You write "They are not specified in public.": But now they are at
>>least in the sense of "PostGIS WKB", aren't they?
>>Now there is the PostGIS documentation
>>(http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01) as well
>>as the source code publicly available.
>
> Ok. Yes in this sence they are public. But they are in no way issued by a 
> standardisation organism.
>
>>2. Wen you say "I wish there would have been a public spec to tell me
>>how": Do you mean that there code/encoding gives still much room fore
>>enhancements? This would be an opportunity to be discussed but it also
>>would mean that "PostGIS WKB" would'nt be stable.
>
> Exact. There are lots of things that we could include/discuss in WKB for 
> raster like:
>
> -I plan to add soon a flag to say if a band is only no data value.
> -Band's stats. Mean, max, min and maybe histogram.
> -More than one nodata value per band.
> -Band's name so we can refer to them by a name instead of by a number.
> -Color scheme descriptor.
> -Adding a table of nominal values. A kind of generalization of what is a 
> color table but able to store nominal values as well.
>
> Etc...
>
> Pierre
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS Raster: Spec. for WKT and WKB?

[Pierre Racine]

>> As I said: no. They are not specified in public. I wish there would have 
>> been a public spec to tell
>me how to store raster but there is not.
>
>I'd like to understand and support this better:
>
>1. You write "They are not specified in public.": But now they are at
>least in the sense of "PostGIS WKB", aren't they?
>Now there is the PostGIS documentation
>(http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01) as well
>as the source code publicly available.

Ok. Yes in this sence they are public. But they are in no way issued by a 
standardisation organism.

>2. Wen you say "I wish there would have been a public spec to tell me
>how": Do you mean that there code/encoding gives still much room fore
>enhancements? This would be an opportunity to be discussed but it also
>would mean that "PostGIS WKB" would'nt be stable.

Exact. There are lots of things that we could include/discuss in WKB for raster 
like:

-I plan to add soon a flag to say if a band is only no data value.
-Band's stats. Mean, max, min and maybe histogram.
-More than one nodata value per band.
-Band's name so we can refer to them by a name instead of by a number.
-Color scheme descriptor.
-Adding a table of nominal values. A kind of generalization of what is a color 
table but able to store nominal values as well.

Etc...

Pierre

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS Raster: Spec. for WKT and WKB?

[Stefan Keller]

Salut Pierre, Hallo Peter

Many thanks for your explanations.

Pierre answered:
> >=> Do you mean by WKB that these formats are specified in public
> >accessible specs.?
>
>
> As I said: no. They are not specified in public. I wish there would have been 
> a public spec to tell me how to store raster but there is not.

I'd like to understand and support this better:

1. You write "They are not specified in public.": But now they are at
least in the sense of "PostGIS WKB", aren't they?
Now there is the PostGIS documentation
(http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01) as well
as the source code publicly available.

2. Wen you say "I wish there would have been a public spec to tell me
how": Do you mean that there code/encoding gives still much room fore
enhancements? This would be an opportunity to be discussed but it also
would mean that "PostGIS WKB" would'nt be stable.

Yours. S.


2010/10/13 Pierre Racine :
> Hi Stefan,
>
>>I'm aware of WKT and WKB in vector knowing OGC Simple Feature Spec.
>>I'm now wondering about the usage of the notion Well Known Text (WKT)
>>and Well Known Binary (WKB) for raster.
>
> There is no WKT, WKB standards for raster and there is no standard (that I 
> know of) to store raster in a database. WKT raster borrowed the WKT, WKB 
> concepts to provide a way to directly create and read raster stored in the 
> database.
>
> You will find the specification for our WKB format in this document: 
> http://trac.osgeo.org/postgis/browser/trunk/raster/doc/RFC2-WellKnownBinaryFormat
>
> No specifications for WKT have been defined yet even if it was planned 
> originally and it gave WKT raster its names. Note that we renamed the type 
> "PostGIS Raster".
>
> WCS defines ways to query coverage data in general (raster, vector, point 
> cloud, etc...) but in no way tells you what should be a raster and how to 
> store it. It should not be too complicated to implement WCS as SQL functions 
> over WKT Raster.
>
>>What I understand from the PostGIS Raster project home page
>>(http://trac.osgeo.org/postgis/wiki/WKTRaster) that JPEG and TIFF
>>formats are supported.
>
> PostGIS Raster does not "supports" other raster formats. It is a format (or 
> better a "type") in itself. We have a Python "converter" (or a "loader" in DB 
> terminology) that convert (or load) raster from any raster format supported 
> by GDAL (in read mode) to PostGIS Raster. In this sence, it "supports" all 
> those raster formats.
>
>>=> Do you mean by WKB that these formats are specified in public
>>accessible specs.?
>
> As I said: no. They are not specified in public. I wish there would have been 
> a public spec to tell me how to store raster but there is not.
>
>>=> How about the spec. of WKT raster?
>
> You will find the best description of PostGIS Raster in those pages:
>
> http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01
>
> Hope this help.
>
> Pierre
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_Simplify

[lplateandy]

Hi Kevin,

Hopefully the attached (hopefully) PDF will help to show what i mean.

In producing the PDF i think i can see why the issue happens. It seems that
the start and end point of the polygon geometery are the node i was hoping
might be removed during the simplify process.

Not sure if there is a way around this?

I do realise there are ways for a simple rectangle etc to fix this but the
example is mainly for illustration as the issue is a problem in more complex
geometries.

Thanks

Andy


Kevin Neufeld wrote:
> 
> Hi Andy,
> 
> Can you post a small example?
> -- Kevin
> 
> 
> On 10/21/2010 10:02 AM, lplateandy wrote:
>> Hi,
>>
>> I have, in the simplest example, a square polygon of 1 by 1 kilometer
>> size
>> with nodes every 25 meters.
>>
>> I can use ST_Simplify (the_geom,5) to remove most of the points.
>>
>> However, for some reason i end up with the four corner nodes and a fifth
>> node 25m clockwise from the top left corner.
>>
>> In itself, this would be fine - 5 nodes is better than 160.
>>
>> However, on some of the polygons, there are more complex boundaries which
>> i
>> wish to smooth out using simplify. I would do this with  ST_Simplify
>> (the_geom,26) example - going over the minimum 25 metres between  any
>> nodes.
>>
>> In the example of the square with 5 nodes, the problem i find then is
>> that
>> the top left node is removed and the one 25m clockwise remains. The
>> result
>> is that i no longer have a 1km square but sloping Western boundary
>> correctly
>> going 1km North South but incorrectly veering across 25m to the East.
>>
>> Is there a way to remove the stray node so i am more likely to maintain
>> my
>> overall polygon shape. I did try st_simplifiypreservetopology but saw no
>> noticeable difference.
>>
>> Hope that makes sense, any help much appreciated
>>
>> Andy
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> 
http://old.nabble.com/file/p30027046/ST_simplify_issue.pdf
ST_simplify_issue.pdf 
-- 
View this message in context: 
http://old.nabble.com/ST_Simplify-tp30021514p30027046.html
Sent from the PostGIS - User mailing list archive at Nabble.com.

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Measure distance to nearest border

[Andreas Forø Tollefsen]

Thanks. Solved!
That worked like a charm.
Exactly what i wanted.

Andreas

2010/10/21 Nicklas Avén 

>  Ok
>
> still don't get the second query. If I understand you right you could try
> this:
>
> CREATE TABLE borddisttest2 AS
> select a.gid, a.cell, MIN(ST_Distance(a.centroid, b.the_geom)) AS distance
> FROM pgfinal2008 a, cshapes b, cshapes c WHERE a.gwcode != b.gwcode AND
> b.gwsyear <= 2008 AND b.gweyear >= 2008 and a.gwcode = c.gwcode and
> st_intersects(b.the_geom, c.the_geom)
> GROUP BY a.gid LIMIT 1;
>  Here I assume that every country only have one representation in cshape.
> What I do is that I try to only get the countries that intersects with the
> country that has the same gwcode as the cell you are calculating.
>
> Here it is essential to have spatial index on the country-polygons and the
> centriod-point
> You should also have index on gwsyear, gweyear and gwcode in both
> pgfinal2008 and cshapes.
>
> I guess your limit 1 is just for testing purposes
>
> Probably you could make it quite a lot faster if you could trick it to inly
> do the intersection process once per country and not once per cell.
>
> Right now I don't see any good way to do that. Hopefully someone else sees
> a solution to that, or I will return if it comes to me.
>
> But maybe, if I recall right there were some discussions here that
> postgresql can cache results from one row to another. If soo it should work
> by itself or at least if you order your query by the gwcode so it takes all
> grid cells from one country first.
>
> /Nicklas
>
>
> 2010-10-21 Andreas Forø Tollefsen wrote:
>
> Ok. I will try to explain more in detail.>
> I have a vector grid consisting of 64818 grid cells. Each of these cells
> are stored in the pgfinal2008 table, with two geometries variables: centroid
> (point) and cell (polygon).
> >
> Each grid cell have a gwcode variable which is the country code.
> >
>
> >
> >
> In addition i have a table with all countries represented by polygons, and
> a table with all countries represented by their boundaries (line).
> >
>
> >
> >
> What i want to do is to measure the distance from each cell to the closest
> border..
> >
>
> >
> >
> While a simple measure of ST_Distance(pgfinal2008.centroid,
> cshapes.the_geom) WHERE pgfinal2008.gwcode != cshapes.gwcode will measure
> the distances, it will measure to all the polygons where the gwcode is
> different.
> >
> However, I can apply a MIN() function to select the nearest of these,
> though this will take considerable time since every cell need to be measured
> to every country.
> >
>
> >
> >
> What i need to solve is how to limit the distance to measuring only to
> neighbouring countries of the country the cell is located.
> >
>
> >
> >
> Thanks for your help Nicklas.
> >
>
> >
> >
>
> >
> >>
> 2010/10/21 Nicklas Avén 
> > >
> >
> hmm, I have to admit I don't really understand what you are trying to do,
> but there are some thingsI don't think you really mean.
> >
> >
>
> >
> select a.gid, MIN(ST_Distance(a.centroid, b.the_geom)) AS distance FROM
> pgfinal2008 a, cshapes b, cshapes c WHERE a.gwcode != b.gwcode AND b.gwsyear
> <= 2008 AND b.gweyear >= 2008 GROUP BY a.gid LIMIT 1;
> >
>
> > Why do you have, cshapes c, there. if you have 200 countries in it taking
> away that will reduce the querytime to 1/200
> >
> What you get here is theclosest country from your first grid cell.
> >
> >
>
> >
> >
> SELECT pgfinal2008.cell, borddisttest2.gid, MIN(borddisttest2.distance)
> FROM borddisttest2, pgfinal2008 WHERE borddisttest2.gid = pgfinal2008.gid
> GROUP BY pgfinal2008.cell, borddisttest2.gid;
> >
> >
> This I don't get. Do you have many rows in pgfinal2008 with the same value
> in pgfinal2008.cell but different pgfinal2008.gid. What is "cell"?
> >
>
> >
> /Nicklas
> >
> >
>
> >
> >
>
> >
>
> > 2010-10-21 Andreas Forø Tollefsen wrote:
> >
> > Thanks.>
> >
> I have found a way to do this calculation.
> > >
> However, since i gave 64818 cells and almost 200 countries, the distance
> from every cell to every country is calculated before the minimum distance
> is selected.
> > >
> This takes awful lot of time.
> > >
>
> > >
> > >
> Any ideas on how to increase the performance?
> > >
>
> > >
> > >
> > >
> DROP TABLE IF EXISTS borddisttest2;
> > >
> CREATE TABLE borddisttest2 AS
> > >
> select a.gid, MIN(ST_Distance(a.centroid, b.the_geom)) AS distance FROM
> pgfinal2008 a, cshapes b, cshapes c WHERE a.gwcode != b.gwcode AND b.gwsyear
> <= 2008 AND b.gweyear >= 2008 GROUP BY a.gid LIMIT 1;
> > >
>
> > >
> > >
> DROP TABLE IF EXISTS borddist2008;
> > >
> CREATE TABLE borddist2008 AS
> > >
> SELECT pgfinal2008.cell, borddisttest2.gid, MIN(borddisttest2.distance)
> FROM borddisttest2, pgfinal2008 WHERE borddisttest2.gid = pgfinal2008.gid
> > >
> GROUP BY pgfinal2008.cell, borddisttest2.gid;
>
> > >> >
> 2010/10/13 Nicklas Avén 
> > > > >
> > >
> Hi
> > >
>
> > >
> You can not cast to geography that way (if I haven't missed something
> essential)
> > > And if you could you w