#20829 closed Bug (fixed)
Geodjango and PostGIS Exception Error
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | GIS | Version: | 1.5 |
| Severity: | Normal | Keywords: | |
| Cc: | 2059016j@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | yes | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
I have connected an existing POSTGIS database and when I run inspectdb I get Exception: Could not find a geometry or geography column for "raster_columns"."extent"
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
raster_columns is a view, which is part of the postgis extension for postgresql.
Using postgresql-9.2.4 and postgis-2.0.3
# \d
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+-------
public | geography_columns | view | harm
public | geometry_columns | view | harm
public | raster_columns | view | harm
public | raster_overviews | view | harm
public | spatial_ref_sys | table | harm
# \d+ raster_columns
View "public.raster_columns"
Column | Type | Modifiers | Storage | Description
------------------+--------------------+-----------+----------+-------------
r_table_catalog | name | | plain |
r_table_schema | name | | plain |
r_table_name | name | | plain |
r_raster_column | name | | plain |
srid | integer | | plain |
scale_x | double precision | | plain |
scale_y | double precision | | plain |
blocksize_x | integer | | plain |
blocksize_y | integer | | plain |
same_alignment | boolean | | plain |
regular_blocking | boolean | | plain |
num_bands | integer | | plain |
pixel_types | text[] | | extended |
nodata_values | double precision[] | | extended |
out_db | boolean[] | | extended |
extent | geometry | | main |
View definition:
SELECT current_database() AS r_table_catalog, n.nspname AS r_table_schema,
c.relname AS r_table_name, a.attname AS r_raster_column,
COALESCE(_raster_constraint_info_srid(n.nspname, c.relname, a.attname), ( SELECT st_srid('010100000000000000000000000000000000000000'::geometry) AS st_srid)) AS srid,
_raster_constraint_info_scale(n.nspname, c.relname, a.attname, 'x'::bpchar) AS scale_x,
_raster_constraint_info_scale(n.nspname, c.relname, a.attname, 'y'::bpchar) AS scale_y,
_raster_constraint_info_blocksize(n.nspname, c.relname, a.attname, 'width'::text) AS blocksize_x,
_raster_constraint_info_blocksize(n.nspname, c.relname, a.attname, 'height'::text) AS blocksize_y,
COALESCE(_raster_constraint_info_alignment(n.nspname, c.relname, a.attname), false) AS same_alignment,
COALESCE(_raster_constraint_info_regular_blocking(n.nspname, c.relname, a.attname), false) AS regular_blocking,
_raster_constraint_info_num_bands(n.nspname, c.relname, a.attname) AS num_bands,
_raster_constraint_info_pixel_types(n.nspname, c.relname, a.attname) AS pixel_types,
_raster_constraint_info_nodata_values(n.nspname, c.relname, a.attname) AS nodata_values,
_raster_constraint_info_out_db(n.nspname, c.relname, a.attname) AS out_db,
_raster_constraint_info_extent(n.nspname, c.relname, a.attname) AS extent
FROM pg_class c, pg_attribute a, pg_type t, pg_namespace n
WHERE t.typname = 'raster'::name AND a.attisdropped = false AND a.atttypid = t.oid AND a.attrelid = c.oid AND c.relnamespace = n.oid AND (c.relkind = 'r'::"char" OR c.relkind = 'v'::"char") AND NOT pg_is_other_temp_schema(c.relnamespace);
These views/tables contain metadata about tables/columns using geometric and/or geographic columns.
However they do not contain metadata about themselves so the type lookup always fails.
https://github.com/django/django/blob/master/django/contrib/gis/db/backends/postgis/introspection.py#L51
comment:4 by , 12 years ago
| Has patch: | set |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
Looks reasonable, someone more familiar with GIS will need to review it. Is there any way to add a test for this?
comment:5 by , 12 years ago
| Needs tests: | set |
|---|---|
| Patch needs improvement: | set |
Comment left on PR.
As for tests, there are examples in tests/inspectdb/tests.py. I'm not absolutely sure it's feasible, but worth looking into.
comment:6 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
What's the expected result? What's the type of the "extent" column?