Il problema è che, anche ipotizzando il caso più generale della creazione di una nuova feature (come ora avviene), non è banale definire il nuovo id. <div>
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.</div>
<div><br></div><div>giovanni<br>
<div><br><div class="gmail_quote">Il giorno 19 aprile 2012 12:48, Luca Lanteri <span dir="ltr"><<a href="mailto:mescal72@gmail.com" target="_blank">mescal72@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<div>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 ?<div>


<div><br><div><br><div class="gmail_quote">Il giorno 19 aprile 2012 11:57, Andrea Peri <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>
<pre>>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. 
</pre>E' un problema concettualmente particolare.<br><br>A mio parere il sezionamento dovrebbe generare una multigeometria.<br>Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.<br><br>Pero' se la tabella non e' multigeometria questo non è possibile.<br>



E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida . :(<br><br>Non è facile trovare un comportamento generalizzabile.<br><br>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.<br>



Se siamo in una tale situazione, pero' non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.<span><font color="#888888"><br><br>-- <br>-----------------<br>Andrea Peri<br>
. . . . . . . . . <br>qwerty àèìòù<br>
-----------------<br><br>
</font></span><br></div></div>_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
Non inviate messaggi commerciali.<br>
I messaggi di questa lista non rispecchiano necessariamente<br>
le posizioni dell'Associazione GFOSS.it.<br>
584 iscritti al 7.4.2012<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
Non inviate messaggi commerciali.<br>
I messaggi di questa lista non rispecchiano necessariamente<br>
le posizioni dell'Associazione GFOSS.it.<br>
584 iscritti al 7.4.2012<br></blockquote></div><br></div></div>