[Gfoss] View in postgis per qgis

L’opzione di usare un altro visualizzatore è da scartare perchè l’operazione è inserita in un contesto più ampio che si appoggia su grass/qgis.
Ho provato a porre contraints sulla view. Di sicuro non è (giustamente) possibile definire chiavi, ma da quello che ho trovato neanche unicità di un campo (e in effetti su una view queste operazioni hanno poco senso).

il suggerimento di emilia è ottimo (visto che mi riferisco allo stesso contesto reali del monitoraggio della fauna). Ma non una soluzione valida in generale.

Però. Continuo a non capire perchè qgis non accetti un campo che “di fatto” è un int4 unico.
Forse in caso non sia definito in postgres, qgis potrebbe chiedere quale è il campo che si vuole usare come “chiave” ed eventualmente verificare che sia unico nella tabella, e solo allora rifiutare di visualizzare.

Così come stanno le cose, e mi pare che voi confermiate, è una forte limitazione con mi sembra poche ragioni pratiche.

grazie delle risposte

F.

On Ter Jun 5 7:33 , Emilia Venturato

Ciao Ferdinando,
la mia soluzione non e’ elegantissima ma quando mi ci sono trovata ho
fatto cosi’ :slight_smile:

Una volta mi era capitato un caso simile con i fagiani. Facevo un group
by id_fagiano della tabella fix.
Ho usato quindi un join su una tabella in cui avevo tutti gli animali
con una chiave primaria.

Non so se hai modo di riferirti ad una tabella in cui ci sia un record
per ogni id_linea. Usandola in un join dovrebbe andare.

Se mi viene in mente altro ti faccio sapere.
ciao
lia

feurbano@clix.pt ha scritto:

Salve a tutti.
Da una serie di punti (ordinati per timestamp) voglio ricostruire in
pstgres/postgis una traiettoria.

CREATE OR REPLACE VIEW prova AS
select nextval(‘contatore’)::int4 as ID,
makeline(geometria)
from (select geometria, id_linea from fix_caprioli
where hr_code is not null order by time_stamp) as foo
group by id_linea;
ALTER TABLE prova OWNER TO postgres;

la cosa funziona perfettamente in postgres.

se però provo a visualizzare in postgis mi dice:
“Qgis requires that the view has a column that can be used as a unique key.
Such a column should be derived from a table column of type int4 and be a
primary key, have a unique constraint on it, or be a PostgreSQL oid column.”
Il che va bene, è noto. M più che aver creato un contatore e pure assicurato
che fosse un int4 non saprei che fare. ovviamente data la funzione makeline
non posso riferirmi alla primary key della tabella di origine, visto che si
utilizza un group by.

Qualcuno ha suggerimenti?

Grazie

Ferdinando




Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss


Emilia Venturato
email+jabber: venturato@faunalia.it
www.faunalia.it
Tel: (+39) 347-2770007 Tel+Fax: (+39) 0587-213742
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy
http://www.faunalia.it/ev


feurbano@clix.pt ha scritto:

Ho provato a porre contraints sulla view. Di sicuro non è (giustamente) possibile definire chiavi, ma da quello che ho trovato neanche unicità di un campo (e in effetti su una view queste operazioni hanno poco senso).

Beh, in postgres non è possibile, in Oracle si, ad esempio.

il suggerimento di emilia è ottimo (visto che mi riferisco allo stesso contesto reali del monitoraggio della fauna). Ma non una soluzione valida in generale.

Però. Continuo a non capire perchè qgis non accetti un campo che "di fatto" è un int4 unico.

Se il codice somiglia un po' a quello di Geoserver, farà una richiesta
al server per sapere qual'e' la chiave primaria della tabella che
gli è stato chiesto di visualizzare. Non c'e', e qui si arrende.
In Geoserver a quel punto ci inventiamo una chiave fasulla giusto per
poter rispondere alle chiamate WMS e WFS, forse in QGis manca questo
fallback perchè il campo chiave serve per le identify (che cosa c'è
qui?) e per l'editing (entrambe cose che non permettiamo nemmeno
in Geoserver se non c'e' il campo chiave).

Forse in caso non sia definito in postgres, qgis potrebbe chiedere quale è il campo che si vuole usare come "chiave" ed eventualmente verificare che sia unico nella tabella, e solo allora rifiutare di visualizzare.

Fai una richiesta agli sviluppatori di QGis :slight_smile:

Così come stanno le cose, e mi pare che voi confermiate, è una forte limitazione con mi sembra poche ragioni pratiche.

La ragione è evidente a mio avviso: vai fuori del caso più comune, e nessuno ha speso tempo per implementare quell'extra di funzionalità
che ti serve. Mica ce l'hanno con te, cosa si sviluppa dipende da
interessi, tempo, necessità, ecc. :slight_smile:

Ciao
Andrea

On Tue, Jun 05, 2007 at 10:59:35AM +0200, Andrea Aime wrote:

feurbano@clix.pt ha scritto:
> Ho provato a porre contraints sulla view. Di sicuro non è (giustamente)
> possibile definire chiavi, ma da quello che ho trovato neanche unicità
> di un campo (e in effetti su una view queste operazioni hanno poco senso).

Beh, in postgres non è possibile, in Oracle si, ad esempio.

Con un decimo del costo di licenza Oracle e' sicuramente possibile ottenere
la stessa funzionalita in postgres (se non gia' possibile).

--strk;

strk ha scritto:

On Tue, Jun 05, 2007 at 10:59:35AM +0200, Andrea Aime wrote:

feurbano@clix.pt ha scritto:

Ho provato a porre contraints sulla view. Di sicuro non è (giustamente) possibile definire chiavi, ma da quello che ho trovato neanche unicità di un campo (e in effetti su una view queste operazioni hanno poco senso).

Beh, in postgres non è possibile, in Oracle si, ad esempio.

Con un decimo del costo di licenza Oracle e' sicuramente possibile ottenere
la stessa funzionalita in postgres (se non gia' possibile).

La mia non voleva essere una critica a Postgres, volevo solo far presente che alcuni database consentono di impostare una primary key
su una vista, ovvero, che è necessariamente una cosa priva di senso,
tutto qui.
Per il resto, personalmente uso Postgres tutte le volte in cui
me lo posso permettere.

Ciao
Andrea

On Tue, Jun 05, 2007 at 01:04:55PM +0200, Andrea Aime wrote:

strk ha scritto:
> On Tue, Jun 05, 2007 at 10:59:35AM +0200, Andrea Aime wrote:
>> feurbano@clix.pt ha scritto:
>>> Ho provato a porre contraints sulla view. Di sicuro non è (giustamente)
>>> possibile definire chiavi, ma da quello che ho trovato neanche unicità
>>> di un campo (e in effetti su una view queste operazioni hanno poco senso).
>> Beh, in postgres non è possibile, in Oracle si, ad esempio.
>
> Con un decimo del costo di licenza Oracle e' sicuramente possibile ottenere
> la stessa funzionalita in postgres (se non gia' possibile).

La mia non voleva essere una critica a Postgres, volevo solo far
presente che alcuni database consentono di impostare una primary key
su una vista, ovvero, che è necessariamente una cosa priva di senso,
tutto qui.

Immagino tu intenda che *non* e' necessariamente ...
Le chiavi primarie servono sia come vincolo di unicita' che come
indice. Il vincolo puo' essere espresso con la query che definisce
la vista, l'indice non ha senso a meno che non si parli di
"materialized view". Ne ho sentito solo parlare delle "materialized",
mai provate, ma puo' darsi siano gia' implementate in postgres.
In tutti i modi possono essere implementate dall'utente con un
set ti trigger sulle tabelle originali.

Ad ogni modo, avere degli indici sulle tabelle che *compongono* la view
da' modo all'optimizer di scegliere la migliore strategia di join, senza
ridondare nei dati (mat. view).

--strk;