>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split.
E’ un problema concettualmente particolare.
A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.
Pero’ se la tabella non e’ multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida . 
Non è facile trovare un comportamento generalizzabile.
La scelta di mettere sempre un nuovo record e’ probabilmente legata alla considerazione che e’ un caso piu’ generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero’ non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Quando un utente divide la gemetria in 2 parti è per assegnarli un significato (e quindi un attributo) diverso, quindi la multigeometria non è una soluzione valida.
A me pare un caso uso talmente comune che mi mette in crisi doverlo gestire. Se qgis vuole, giustamente, un gid univoco per ogni geometria, non dovrebbe generarne uno anche quando divide le geometrie visto che a tutti gli effetti ne genera una nuova. O forse già lo fa ma sbaglio io in qualcosa ?
Il giorno 19 aprile 2012 11:57, Andrea Peri <aperi2007@gmail.com> ha scritto:
>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split.
E’ un problema concettualmente particolare.
A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.
Pero’ se la tabella non e’ multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida .
Non è facile trovare un comportamento generalizzabile.
La scelta di mettere sempre un nuovo record e’ probabilmente legata alla considerazione che e’ un caso piu’ generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero’ non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
Il problema è che, anche ipotizzando il caso più generale della creazione di una nuova feature (come ora avviene), non è banale definire il nuovo id.
Immagino che l’unico modo robusto sarebbe delegare la cosa ai provider, che dovrebbero esporre un proprio metodo per ottenere un nuovo gid. Ad es. nel caso di una vista PostGIS e di un gid autoincrementante, il provider dovrebbe interrogare il currval() per sapere il prossimo id disponibile.
giovanni
Il giorno 19 aprile 2012 12:48, Luca Lanteri <mescal72@gmail.com> ha scritto:
Quando un utente divide la gemetria in 2 parti è per assegnarli un significato (e quindi un attributo) diverso, quindi la multigeometria non è una soluzione valida.
A me pare un caso uso talmente comune che mi mette in crisi doverlo gestire. Se qgis vuole, giustamente, un gid univoco per ogni geometria, non dovrebbe generarne uno anche quando divide le geometrie visto che a tutti gli effetti ne genera una nuova. O forse già lo fa ma sbaglio io in qualcosa ?
Il giorno 19 aprile 2012 11:57, Andrea Peri <aperi2007@gmail.com> ha scritto:
>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split.
E’ un problema concettualmente particolare.
A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.
Pero’ se la tabella non e’ multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida .
Non è facile trovare un comportamento generalizzabile.
La scelta di mettere sempre un nuovo record e’ probabilmente legata alla considerazione che e’ un caso piu’ generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero’ non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
2012/4/19 G. Allegri <giohappy@gmail.com>:
Il problema è che, anche ipotizzando il caso più generale della creazione di
una nuova feature (come ora avviene), non è banale definire il nuovo id.
Immagino che l'unico modo robusto sarebbe delegare la cosa ai provider, che
dovrebbero esporre un proprio metodo per ottenere un nuovo gid. Ad es. nel
caso di una vista PostGIS e di un gid autoincrementante, il provider
dovrebbe interrogare il currval() per sapere il prossimo id disponibile.
No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.
Se si divide un poligono, e' vero che i due poligoni hanno uno stesso
id, ma questo avviene fino al momento del commit, dopo il commit uno dei due
conserva l'id iniziale, l'altro ottiene il progressivo da PostGIS.
Tra l'altro non e' nemmeno (ovviamente) possibile modificare
manualmente l'id, essendo gestito con un serial.
ciao
p
--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Quando commito mi restituisce l’errore:
1 feature(s) not added.
Provider errors:
PostGIS error while adding features: duplicate key violates unique costraint conoidi_piemonte_pkey
Il giorno 19 aprile 2012 14:57, Paolo Corti <pcorti@gmail.com> ha scritto:
2012/4/19 Luca Lanteri <mescal72@gmail.com>:
mmm… allora non mi torna qualcosa, perche anch’io mi aspetterei il
comportamento che dici tu invece non è così:
questa è la mia tavola
CREATE TABLE conoidi.conoidi
(
gid serial NOT NULL,
id_conoide integer,
tipo double precision,
poligenico character varying(4),
valanga character varying(4),
corsoacqua character varying(50),
the_geom geometry,
modifica integer,
autore_modifica character varying(50),
area integer,
fonte integer,
cod_macrobacino character varying(10),
CONSTRAINT conoidi_piemonte_pkey PRIMARY KEY (gid),
CONSTRAINT enforce_dims_the_geom CHECK (st_ndims(the_geom) = 2),
CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) =
‘POLYGON’::text OR the_geom IS NULL),
CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = 32632)
quando inserico un nuovo record nel campo gid ritrovo, giustamente:
nextval(‘conoidi.conoidi_gid_seq’::regclass) essendo il valore di default
quando faccio uno split, no! sulle nuove geometrie create il gid rimane
quello vecchio per entrambe i poligoni. Inserendolo a mano tutto funziona ma
ritorno nel problema di prima.
si ma non hai committato le modifiche (e quindi non hai interrogato
PostGIS per ottenere il nuovo id). Se chiudi la sessione di editing e
riguardi gli id, vedrai che tutto torna 
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
No, in realta’ (ed ho anche verficato che e’ effettivamente cosi’),
l’implementazione (corretta) e’ richiedere l’id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
Quando faccio un nuovo inserimento funziona tutto
ma se divido un poligono già esistente in più parti con la funzione “Split
feature” il valore di gid viene assegnato ad entrambe i nuovi poligoni.
Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
posso più salvare fino a quando non assegno manualmente un nuovo valore al
campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l’id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all’originale…
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Acc… forse si svela l’arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.
Il giorno 19 aprile 2012 15:03, G. Allegri <giohappy@gmail.com> ha scritto:
No, in realta’ (ed ho anche verficato che e’ effettivamente cosi’),
l’implementazione (corretta) e’ richiedere l’id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
Quando faccio un nuovo inserimento funziona tutto
ma se divido un poligono già esistente in più parti con la funzione “Split
feature” il valore di gid viene assegnato ad entrambe i nuovi poligoni.
Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
posso più salvare fino a quando non assegno manualmente un nuovo valore al
campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l’id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all’originale…
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Confermo, ho appena riprodotto l’errore. Vado a vedere cos’è cambiato a livello di codice…
giovanni
Il giorno 19 aprile 2012 15:08, Luca Lanteri <mescal72@gmail.com> ha scritto:
Acc… forse si svela l’arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.
Il giorno 19 aprile 2012 15:03, G. Allegri <giohappy@gmail.com> ha scritto:
No, in realta’ (ed ho anche verficato che e’ effettivamente cosi’),
l’implementazione (corretta) e’ richiedere l’id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
Quando faccio un nuovo inserimento funziona tutto
ma se divido un poligono già esistente in più parti con la funzione “Split
feature” il valore di gid viene assegnato ad entrambe i nuovi poligoni.
Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
posso più salvare fino a quando non assegno manualmente un nuovo valore al
campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l’id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all’originale…
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.
Grazie mille come al solito a tutti dell’aiuto tempestivo.
Luca
Il giorno 19 aprile 2012 15:13, G. Allegri <giohappy@gmail.com> ha scritto:
Confermo, ho appena riprodotto l’errore. Vado a vedere cos’è cambiato a livello di codice…
giovanni
Il giorno 19 aprile 2012 15:08, Luca Lanteri <mescal72@gmail.com> ha scritto:
Acc… forse si svela l’arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.
Il giorno 19 aprile 2012 15:03, G. Allegri <giohappy@gmail.com> ha scritto:
No, in realta’ (ed ho anche verficato che e’ effettivamente cosi’),
l’implementazione (corretta) e’ richiedere l’id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
Quando faccio un nuovo inserimento funziona tutto
ma se divido un poligono già esistente in più parti con la funzione “Split
feature” il valore di gid viene assegnato ad entrambe i nuovi poligoni.
Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
posso più salvare fino a quando non assegno manualmente un nuovo valore al
campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l’id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all’originale…
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Ciao Luca,
2012/4/20 Luca Lanteri <mescal72@gmail.com>:
Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.
se il problema e' confermato e' bene aprire un ticket.
In questo modo si tiene traccia del problema, si evita che venga
dimenticato e soprattutto si evita che piu' persone spendano tempo
a correggere lo stesso identico problema.
Saluti.
Grazie mille come al solito a tutti dell'aiuto tempestivo.
Luca
Il giorno 19 aprile 2012 15:13, G. Allegri <giohappy@gmail.com> ha scritto:
Confermo, ho appena riprodotto l'errore. Vado a vedere cos'è cambiato a
livello di codice...
giovanni
Il giorno 19 aprile 2012 15:08, Luca Lanteri <mescal72@gmail.com> ha
scritto:
Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema
limitato sulla versione di sviluppo.
Il giorno 19 aprile 2012 15:03, G. Allegri <giohappy@gmail.com> ha
scritto:
No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al
provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
> Quando faccio un nuovo inserimento funziona tutto
> ma se divido un poligono già esistente in più parti con la funzione
> "Split
> feature" il valore di gid viene assegnato ad entrambe i nuovi
> poligoni.
> Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
> posso più salvare fino a quando non assegno manualmente un nuovo
> valore al
> campo gid. Facendo così la sequence non sia aggiorna ed al prossimo
> nuovo
> inserimento mi trovo di nuovo con il gid duplicato. Insomma come si
> dice
> cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo
negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco
perché lui ottenga un gid uguale all'originale...
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
--
Giuseppe Sucameli
ok, allora provvedo.
Grazie
^L^
Il giorno 20 aprile 2012 12:06, Giuseppe Sucameli <brush.tyler@gmail.com> ha scritto:
Ciao Luca,
2012/4/20 Luca Lanteri <mescal72@gmail.com>:
Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.
se il problema e’ confermato e’ bene aprire un ticket.
In questo modo si tiene traccia del problema, si evita che venga
dimenticato e soprattutto si evita che piu’ persone spendano tempo
a correggere lo stesso identico problema.
Saluti.
Grazie mille come al solito a tutti dell’aiuto tempestivo.
Luca
Il giorno 19 aprile 2012 15:13, G. Allegri <giohappy@gmail.com> ha scritto:
Confermo, ho appena riprodotto l’errore. Vado a vedere cos’è cambiato a
livello di codice…
giovanni
Il giorno 19 aprile 2012 15:08, Luca Lanteri <mescal72@gmail.com> ha
scritto:
Acc… forse si svela l’arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema
limitato sulla versione di sviluppo.
Il giorno 19 aprile 2012 15:03, G. Allegri <giohappy@gmail.com> ha
scritto:
No, in realta’ (ed ho anche verficato che e’ effettivamente cosi’),
l’implementazione (corretta) e’ richiedere l’id incrementale al
provider
al momento del commit, altrimenti si rischiano conflitti.
Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:
Quando faccio un nuovo inserimento funziona tutto
ma se divido un poligono già esistente in più parti con la funzione
“Split
feature” il valore di gid viene assegnato ad entrambe i nuovi
poligoni.
Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
posso più salvare fino a quando non assegno manualmente un nuovo
valore al
campo gid. Facendo così la sequence non sia aggiorna ed al prossimo
nuovo
inserimento mi trovo di nuovo con il gid duplicato. Insomma come si
dice
cornuto e mazziato!
Dal codice mi sembra di capire che Qgis fornisce un id temporaneo
negativo [1], e poi delega l’id definitivo a PostGIS, quindi non capisco
perché lui ottenga un gid uguale all’originale…
Forse non ho capito il problema?
giovanni
[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
ciao
p
–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
584 iscritti al 7.4.2012
–
Giuseppe Sucameli