[Qgis-developer] DB Manager and other PostGIS issues: notes from a course

Paolo Cavallini cavallini at faunalia.it
Mon Nov 21 03:06:48 PST 2016


Hi,
thanks Giovanni for the feedback. Replies below.

Il 21/11/2016 12:01, Giovanni Manghi ha scritto:

>> * DB Manager
>>   * create table: field types are limited; in particular, timestamptz is
>> missing
> 
> old issue, old as db manager, it only shows a subset of available datatypes.

do you know whether there is a ticket on this?

>>   * create table: SRID has to be entered by hand; the projection widget
>> should be added
> 
> 
> see above: it has always been so in DB manager.

same as above

>>   * edit table -> Table properties -> Field properties: the field
>> `Length` appears wrong; for geom it shows `geomtype,srid`, for
>> varchar(255) and others, adding a length will cause an error:
>> ALTER TABLE "public"."buffer_union" ALTER "round" TYPE varchar(255) (24)
>> length has to be entered by hand changing varchar(255) into e.g. varchar(20)
> 
> 
> see above: old as db manager. If you choose a datatype with a
> predefined length then manually changing the length causes an invalid
> query to be run.

same as above

>>   * we got frequent errors similar to [0]
> 
> 
> confirmed. This does not seems to be the case in LTR, so this
> configures as a regression.

OK, I'm opening a ticket; tanks for the confirmation.

>> * Browser
>>   * importing a shapefile of points results in a (generally undesirable)
>> MULTIPOINT, without a possibility of choice for the user
>>   * a table created with SRID=0
>> CREATE TABLE pt
>>  (id INTEGER, name text, geom GEOMETRY(Point,0,2));
>> INSERT INTO pt (id, name, geom)
>>  VALUES (1, 'Origin', ST_GeomFromText('POINT(0 0)', 0));
>> results in two entries: one with mouseover= geom as Point in 0 and one
>> geom as Point in -2147483648
>>
> 
> 
> confirmed down to 2.8.* so not sure is a regression.

is there an open ticket? if not, I'll open one

>> * Processing
>>   * there are two Import into Processing (one QGIS and one OGR)
> 
> 
> the OGR based tool is necessary because is the only one available that
> is fast enough. It is 8+ times faster than any other tool available in
> QGIS making it the only tool good enough to import into postgis large
> layers.

Yes, I know. Why keeping the other than?

>>   * for the first (QGIS), batch processing fails with `Missing parameter
>> value: Table to import to (leave blank to use layer name (row 1)`
> 
> the "table name" parameter has been incorrectly set as mandatory. This
> is not the case in LTR, so this is a regression.

OK, I'm opening a ticket

>>   * for the second (OGR), it also fails because it tries to write in the
>> spatial_ref_sys (CRS should default to source CRS) [1]
> 
> I will make the input/output CRS parameters mandatory.

why the input? it should be taken from the sources, isn't it?

>>   * the gdal output is not interpreted correctly (html and encoding) [1]
> 
> cannot confirm.

so in your cases html tags are interpreted?
Tahsnks again.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis


More information about the Qgis-developer mailing list