Bug report #13159
wrong display of negative number values from a postGIS db
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
History
#1 Updated by Giovanni Manghi about 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 about 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 about 9 years ago
- File snapshot_qgis20_table_view.png added
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 about 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 about 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 about 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 about 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
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/