[Gfoss] Editing in PostGIS

G. Allegri giohappy a gmail.com
Gio 19 Apr 2012 13:57:16 CEST


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 a 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 a 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 a 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 a 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
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120419/f5b7e6ed/attachment.html>


Maggiori informazioni sulla lista Gfoss