missing geometry field in postgis query

[john.floyd@…]

gdal-1.2.6

In using grass-6.0.0 could not load postgis (through ogr) layer due to missing
geomtry field. 

Q? In 
file:       ogr/ogrsf_frmts/pg/ogrpgtablelayer.cpp 
function:   ReadTableDefinition()
line:       approx 239 ...

        else if( EQUAL(oField.GetNameRef(),"WKB_GEOMETRY") )
        {
            bHasWkb = TRUE;
            if( EQUAL(pszType,"OID") )
                bWkbAsOid = TRUE;
            continue;
        }

Is this 
----->>     pszGeomColumn = CPLStrdup( oField.GetNameRef());
missing?

It appears that if we have a WKB_GEOMETRY field then pszGeomColumn is undefined
which is used in many other parts to assemble results.

[warmerdam]

John,

I'm not sure how closely you tracked the code through, but my understanding
was that GRASS actually issues a query using ExecuteSQL() and that this
uses the ogrpgresultlayer.cpp instead of ogrpgtablelayer.cpp.  

In GDAL 1.2.6 this result layer code is incompatible with PostGIS 1.0 geometries
and so the geometries were just discarded.  I have recently corrected this issue
in GDAL CVS so you might want to try a nightly snapshot and see if it behaves
differently.

The particular code you highlight is intended to support WKB columns that
are unrelated to PostGIS, but still stored in a PostgreSQL table.  This
code is essentially vestigal at this time and I haven't tested it in recent
memory.  It may well not work, but I am not too concerned about that any 
more since PostGIS is the prefferred way of handling geometry in Postgres. 

I am leaving this bug open for now, but I would appreciate it if you could
close it if you find a nightly build solves your problem.

PS. there have been a variety of other PostGIS 1.0 and other improvements 
to the OGR PostGIS driver since 1.2.6 which I would also appreciate testing
and feedback on.

[john.floyd@…]

(In reply to comment #1)
Frank,

I set up Grass debug, and gdal(ogr) debug output and it definitely went
thru this routine.  I have since made the change adding the suggested
line and then grass loaded all the geometries.  Though this may beak
some other functionality that I know nothing about.  It just seemed odd
that even though a geometry column was present its reference
kept, even though other code seemed to act on the type of geom data that
was in the column.

I have to admit that I am just becoming familiar with grass, ogr and
postgis, so I expect to make mistakes and can be easily mistaken.

Though this one worked and thought that rather than giving a fix just
put it as a suggestion.  I had thougt that it was quite possible that grass
6 was using some other path in the interface as well.

John

[warmerdam]

John,

I have committed your change, but I'm still not sure why it is getting
into the logic in question. The previous if statement checking the type
and determining that it is "geometry" should have identified the geometry
field if it is using PostGIS types. 

I am wondering if it is possible that the geometry field was created with
a more specific geometry type and that is the issue.  Would you mind adding
a line like:

  fprintf( stderr, "Field=%s, type=%s", oField.GetNameRef(), pszType );

In the "WKB_GEOMETRY" case so we can see what type this field is, and run
that?  If there are more specific geometry types that can now appear as 
column types I may need to alter the previous cases logic. 

[warmerdam]

Closing as we have no further feedback.