Opened 3 years ago

Closed 18 months ago

#7257 closed defect (wontfix)

CARTO driver does not run Cartodbfy for non-spatial table

Reported by: pramsey Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: OGR_SF Version: svn-trunk
Severity: normal Keywords:
Cc:

Description

Using ogr2ogr to import a table that has no spatial component, the process does not run CDB_CartodbfyTable(), resulting in the table not showing up in the UI. It looks like the culprit is this block in ogrcartodatasource

    if( bCartoify )
    {
        if( nSRID != 4326 )
        {
            if( eGType != wkbNone )
            {
                CPLError(CE_Warning, CPLE_AppDefined,
                        "Cannot register table in dashboard with "
                        "cdb_cartodbfytable() since its SRS is not EPSG:4326");
            }
            bCartoify = false;
        }
    }

Based on the warning text, it looks like the global should be set within the same block.

Change History (7)

comment:1 Changed 3 years ago by Even Rouault

Does cdb_cartodbfytable() work on a table without spatial column ?

comment:2 Changed 3 years ago by Even Rouault

@pramsey I manually tried to issue "ogrinfo carto:ogr2ogr-test -sql "select cdb_cartodbfytable('test')"" where test is a non-spatial table I created previously with ogr2ogr.

This errors out with

HTTP: These POSTFIELDS were sent:q=select cdb_cartodbfytable('test') LIMIT 500 OFFSET 0&api_key={redacted}
ERROR 1: RunSQL Error Message:HTTP error code : 400
CARTO: RunSQL Response:{"error":["Please set user quota before cartodbfying tables."]}

So either cartodbfy'ing doesn't work with a non-spatial table or some preliminary step is needed.

comment:3 Changed 3 years ago by pramsey

Something else is going on in your test, as I was able to run select cdb_cartodbfytable('foobar') via the SQL API and get a cartodbfy'ed table from a geometry-less input. I've seen the error you're reporting when working directly with the cdb_cartodbfytable function in a test database (where the session does in fact need to set up the user quota first), but not in the carto platform before.

comment:4 Changed 3 years ago by Even Rouault

@pramsey Actually, due to the account being a multiuser one, the correct command was "SELECT cdb_cartodbfytable('ogr2ogr-test', 'test')". This succeeds. The issue is that it adds a the_geom and the_geom_webmercator columns to the table, so this is no longer a geometry-less table...

Last edited 3 years ago by Even Rouault (previous) (diff)

comment:5 Changed 3 years ago by pramsey

That is very true... for the moment, it's the very presence of those columns that makes the table a "carto" table.

comment:6 Changed 3 years ago by Even Rouault

This is a bit unfortunate... The current behaviour is "correct" from a OGR point of view, since if I do

$ ogr2ogr -overwrite  carto:ogr2ogr-test test.csv

$ ogrinfo carto:ogr2ogr-test | grep test
1: test (None)

$ ogrinfo carto:ogr2ogr-test test
INFO: Open of `carto:ogr2ogr-test'
      using driver `Carto' successful.

Layer name: test
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
FID Column = cartodb_id
foo: String (0.0)
OGRFeature(test):100
  foo (String) = bar

The layer is correctly reported as non-spatial

Whereas if I run cdb_cartodbfytable(), I get:

$ ogrinfo carto:ogr2ogr-test | grep test
2: test

$ ogrinfo carto:ogr2ogr-test test
INFO: Open of `carto:ogr2ogr-test'
      using driver `Carto' successful.

Layer name: test
Geometry: Unknown (any)
Feature Count: 1
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
FID Column = cartodb_id
Geometry Column = the_geom
foo: String (0.0)
OGRFeature(test):100
  foo (String) = bar

Couldn't there a mechanism to insert the table name into a record in some carto 'system' table (or any other more appropriate solution), and not add any geometry column, so that the UI would still be able to show that geometry less tbable

comment:7 Changed 18 months ago by Even Rouault

Milestone: 2.2.4closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub?. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.