Bug report #13159

wrong display of negative number values from a postGIS db

Added by c m over 9 years ago. Updated over 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Data Provider/PostGIS
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:21222

Description

since QGIS v2.x, if you open a postGIS table (with a geometry column) containing some other (integer) attribute field
when you click on table display showing all values from all fields in a table view, the negative values (<0) coming from a numeric field inside postgis are not displayed (error or a wrond large number instead of the real negative value.
In the same data field, positive values are displayed correctly

snapshot_qgis20_table_view.png (2.74 KB) c m, 2015-07-31 04:33 AM

History

#1 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Open to Feedback

Hi,

it is not clear to me, the problem affects values in "integer" or "numeric" fields?

could you please a sample (a table dump would be ok), thanks.

#2 Updated by c m over 9 years ago

Sorry for the unclear description.
I just check the real case scenario and the postgresql field (containing negative and positive values) is of type "bigint"

#3 Updated by c m over 9 years ago

It's the same with field of type "integer" : negative values are shown as "ERROR" in the QGIS table"s view

#4 Updated by c m over 9 years ago

nb : there's a (unique, btree) index on the field that causes the issue
I don't know if it has any relation with the current issue. I didn't try to reproduce the issue when removing the index. I'll do it asap.

#5 Updated by Giovanni Manghi over 9 years ago

c m wrote:

nb : there's a (unique, btree) index on the field that causes the issue
I don't know if it has any relation with the current issue. I didn't try to reproduce the issue when removing the index. I'll do it asap.

Hi thanks for the report. Could you add a dump of the problematic table? thanks.

#6 Updated by c m over 9 years ago

Here's a script that you could use to reproduce the issue :

DROP TABLE IF EXISTS public.to_delete cascade;

CREATE TABLE public.to_delete
(
  id integer NOT NULL,
  the_geom geometry,
  CONSTRAINT id_idx_primkey PRIMARY KEY (id),
  CONSTRAINT id_idx_unique UNIQUE (id),
  CONSTRAINT enforce_dims_the_geom CHECK (st_ndims(the_geom) = 2),
  CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'LINESTRING'::text OR the_geom IS NULL),
  CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = 4326)  
);

SELECT Populate_Geometry_Columns('public.to_delete'::regclass);

insert into public.to_delete values (1, ST_GeomFromText('LINESTRING(-71.160281 42.258729,-71.160837 42.259113,-71.161144 42.25932)', 4326));
insert into public.to_delete values (-1, ST_GeomFromText('LINESTRING(-71.161144 42.25932,-71.160837 42.259113,-71.160281 42.258729)', 4326));

Then connect a QGIS v2.x to view this table
open the table's view and you'll see an "ERROR" value for field "id" in line 2

#7 Updated by Giovanni Manghi over 9 years ago

  • Category changed from Attribute table to Data Provider/PostGIS
  • Affected QGIS version changed from 2.0.1 to master
  • Status changed from Feedback to Open

Confirmed.

#8 Updated by Giovanni Manghi about 9 years ago

replicate is easy: import with osm2pgsql a osm dataset, the "osm_id" field (int8) will show this wrong behavior.

#9 Updated by Giovanni Manghi over 7 years ago

  • Regression? set to No
  • Easy fix? set to No

#10 Updated by Giovanni Manghi over 5 years ago

  • Resolution set to end of life
  • Status changed from Open to Closed

Also available in: Atom PDF