Numerical differences ogr -sql versus postreSQL

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Numerical differences ogr -sql versus postreSQL

Thomas Windholz

Numerical differences in, for example, buffer:

 

I noticed numerical differences between an sql statement through the ogr library versus directly through postgreSQL (I thought the sqlexecute goes through?). Has anyone noticed these differences as well? In the following dataset these numerical differences produce sort of ears that are equal to the radius of the buffer (so not really negligible and quite visible).

 

Here is an example (other number combinations are less visible, but still produce errors):

 

Buffer of Point(3.0 -3.7) results:

 

C:\Program Files\FWTools0.9.9>ogr2ogr -f "ESRI Shapefile" -sql "SELECT buffer(Ge

omFromText('POINT(3.0 -3.7)'), 1.0,4)" buffer.shp "PG:user=postgres password=xxx

dbname=xxx host=localhost port=5432"

 

In numbers:

4.0000000000000000,-3.6999999999999957

3.9238604590292496,-4.0820349338195641

3.6289817765446712,-4.2508567811706746

3.3826834323961990,-4.6238413855257363

3.0000000000437552,-4.7000000000000002

2.6173153755938636,-4.6238413855600982

2.2928932188610727,-4.2508567812341678

2.0761204675187801,-4.0820349339023796

2.0000000000000000,-3.7000000000716033

2.0761204674499845,-2.0673165677282341 … ear 1 … should be around 2.07.., -3.06..

2.2928932187340854,-2.9928932188928199

2.6173153754279466,-2.7761192754430666

2.9999999998653095,-2.6999999999999957

3.3826834322302819,-2.7761192753399788

3.6289817810754332,-2.9928932187023385

3.9238604586694903,-2.0673165674793625 … ear 2 … should be around 3.92.., -3.06..

4.0000000000000000,-3.6999999998204118

4.0000000000000000,-3.6999999999999957

 

Initially, I thought this might be a PostGIS or Geos issue, so I tested the same sql

statement directly in PostgreSQL using:

 

SELECT AsText(buffer(GeomFromText('POINT(3.0 -3.7)'), 1.0,4))

 

"POLYGON((

4 -3.7

3.92387953251558 -4.08268343235472

3.70710678120242 -4.40710678117067

3.3826834323962   -4.6238795324984

3.0000000000449   -4.7

2.61731656768676 -4.62387953253276

2.29289321886107 -4.40710678123417

2.07612046751878 -4.08268343243768

2                              -3.70000000008979

2.07612046745006 -3.31731656772824

2.29289321873409 -2.99289321889282

2.61731656752084 -2.77612046753596

2.99999999986531 -2.7

3.38268343223028 -2.77612046743287

3.70710678107543 -2.99289321870234

3.92387953244686 -3.31731656747936

4                              -3.69999999982041

4                              -3.7

))"

 

The PostGIS buffer function did not reproduce the ears on the buffer. Also,

overall there are some differences between the datasets created through ogr2ogr

versus directly in PostgreSQL. The shapefile is not really an issue since I also tested reading the results directly through ogr ...

 

...any hints/help is appreciated!

 

Thanks,

Thomas

 


Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Numerical differences ogr -sql versus postreSQL

Frank Warmerdam
On 9/19/05, Thomas Windholz <[hidden email]> wrote:

>  
>
> Numerical differences in, for example, buffer:
>
>  
>
> I noticed numerical differences between an sql statement through the ogr
> library versus directly through postgreSQL (I thought the sqlexecute goes
> through?). Has anyone noticed these differences as well? In the following
> dataset these numerical differences produce sort of ears that are equal to
> the radius of the buffer (so not really negligible and quite visible).

Thomas,

I see what you mean, but I have no idea why this is happening.
The buffering is happening in PostGIS in both cases.  I have no
idea why some points are altered when read back through OGR.
I don't think I have a geos enabled PostGIS setup here so I can't
easily test the same thing myself.

If you are in a position to do so, I would suggest stepping through
the OGR code.   In particular, I suspect should break in
gdal/ogr/ogrsf_frmts/pg/ogrpglayer.cpp in the RecordToFeature()
method.  There is a spot in a block commented as "Handle PostGIS
geometry" that either calls HEXToGeometry() or createFromWkt().
If it goes through the createFromWkt() it would be interesting to
see if the Wkt it gets is corrupt already.  However, I suspect it will
got through the HEXToGeometry() method which is pretty new and
might a bug of some sort.   The HEXToGeometry() method is pretty
new, and used (I think) only for user sql requests.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev