[postgis-users] where has the wkb type gone?

[Richard Taylor]

On Tuesday 23 Aug 2005 10:03, Mark Cave-Ayland wrote:
> > -----Original Message-----
> > From: postgis-users-bounces at postgis.refractions.net
> > [mailto:postgis-users-bounces at postgis.refractions.net] On
> > Behalf Of Richard Taylor
> > Sent: 22 August 2005 22:11
> > To: postgis-users at postgis.refractions.net
> > Subject: [postgis-users] where has the wkb type gone?
> >
> >
> > Hi
> >
> > I am converting a Python library from a rather old version of postgis to
>
> the
>
> > latest release. The library relies upon the oid of the columns returned
>
> from
>
> > a select query to know whether the data is in WKT or WKB. The type oid
>
> used
>
> > to be 'wkb' for a WKB return and 'geometry' for a WKT return.  At some
>
> point
>
> > during the development of postgis the 'wkb' type has been removed.
> >
> > Is there anyway in the latest release that I can work out whether the
>
> format
>
> > of the return from a select query is in WKT or WKB?
> >
> > Regards
> >
> > Richard
>
> Hi Richard,
>
> Could you try and give us a better idea of the API your Python library uses
> to obtain results and the types of query that it issues?
>
> With the latest 1.0.x series of PostGIS, the assumption is that the
> PostgreSQL "native" type (i.e. what you see when you do "SELECT geom_column
> FROM geom_table") is an internal representation and could change. It is up
> to the client to ask the database which format is required by wrapping the
> geom_column with either AsText()/AsBinary() for OGC-compliant output or
> AsEWKT()/AsEWKB() for PostGIS "Extended" formats which also includes
> information such as Z/M coordinates and SRID information.

The library implements a EWKT and a EWKB parser. It also implements a 
collection of classes that implement all the geometry objects (e.g. OGPoint 
etc.). 

The access to the database is done through a seperate Python database library 
called psycopg that in turn uses libpq to access postgres/postgis. 

The queries are standard SQL strings passed into the psycopg library. 

For insert/update queries there is a little extra magic that enables Python 
objects to be passed as format strings. A method is called on the Python 
object by the psycopg library to convert the object into a EWKT 
representation that is then inserted into the query string. All of this works 
fine.

For select queries there are two ways of performing the query. Both start with 
a conventional SQL query. e.g.

	cursor.execute("SELECT AsEWKT(col) FROM table")
	result = cursor.fetchall()

The result is a list of result rows and the columns will be strings of type 
'text'. The result can then be passed to the EWKT parser to produce the 
collection of Python objects that the geometry string represents. This works 
fine.

However, pycopg offers the possibility of hooking the parser into the select 
path so that it is automatically called for any row that has a given type 
(oid). This means that the results will not be a list of strings but a list 
of Python greometry collection objects.

In older versions of postgis the returns of AsBinary and AsText on a geometry 
column was of type 'geometry' and 'wkb'. These types (oids) were unique to 
the postgis types. So it was straight forward to hook the EWKT and EWKB 
parsers to those oids and the type conversion happened transparently to the 
code issuing the select query.

In the new version of postgis the type (oid) of AsEWKT and AsEWKB as 'text' 
and 'bytea'. If I hook the parser on to these types it will attempt to parse 
all 'text' and 'bytea' columns on any select query, which is unlikely to be 
want the user is expecting. 

I can not see anyway, in the new postgis, to detect whether the column in the 
result of select query is of EWKT or EWKB type. 

I hope I have explained things clearly enough.

Regards

Richard

-- 
You can normally find me on Jabber as RichardTaylor at jabber.org