L'uso di espressioni condizionali nel vostro progetto di rilevamento può essere un ottimo modo per aumentare l'accuratezza della raccolta dei dati sul campo. L'uso QGIS può rivelarsi uno strumento potente per migliorare l'usabilità del vostro rilevamento sul campo. Grazie alla flessibilità di QGIS, questo strumento può essere utilizzato in molti modi, ma vi mostreremo un paio di esempi per aiutarvi a muovere i primi passi.
Esempio 1 - Limitazione dei campi tramite espressioni
A volte i moduli di sondaggio complessi possono risultare disordinati o confusi per gli intervistatori che inseriscono i dati su schermi di dispositivi di piccole dimensioni. Un modo per rendere i moduli più chiari è quello di utilizzare espressioni per visualizzare solo i campi a cui l'intervistatore deve accedere.
Ad esempio, potresti trovarti a compilare un questionario immobiliare che richiede la compilazione di campi specifici a seconda del tipo di immobile. Costringere l'utente a scorrere ogni sezione del modulo fino a trovare i campi necessari può creare confusione e richiedere molto tempo ai compilatori. Invece, puoi utilizzare espressioni condizionali per visualizzare solo i campi obbligatori in base al tipo di immobile oggetto del questionario.
Cominciamo con un semplice progetto di esempio per il nostro rilevamento catastale. Abbiamo una mappa di sfondo e un livello di punti denominato «survey» per registrare le informazioni relative a ciascun immobile. La tabella del livello «survey» è la seguente:
| Campo | Tipo | Descrizione |
|---|---|---|
| fid | INT | chiave primaria |
| uuid | testo | ID univoco |
| geometra | testo | Campo per inserire il nome utente del geometra |
gruppo_di_ricerca | testo | Registrare il team incaricato del rilevamento assegnato all'immobile |
| creato | data/ora | Data e ora di creazione del record |
| ultimo_aggiornamento | data/ora | Data e ora dell'ultimo aggiornamento della funzione |
| numero civico | INT | Numero civico |
| nome_via | testo | Nome della via |
| codice postale | testo | Codice postale |
| piani | INT | Numero di piani |
| tipo | testo | Tipo di immobile (commerciale o residenziale) |
| nome_autobus | testo | Nome dell'azienda |
| tipo_di_autobus | testo | Tipo di attività |
| tipo_risorsa | testo | Tipo di abitazione (bungalow, villetta a schiera, cottage, ecc.) |
| parcheggio | testo | Tipo di parcheggio disponibile presso l'abitazione (in strada, nel vialetto, in garage) |
| res_occupato | Booleano | L'abitazione è occupata? |
Un modo per rendere questo modulo più facile da usare per il perito è quello di organizzare i campi in schede utilizzando il Drag and Drop Designer. Possiamo suddividere il nostro questionario in tre schede: "Immobili", "Attività commerciali" e "Residenziale", con un campo dedicato alle informazioni sul perito nella prima scheda:
Ora che i campi sono stati organizzati, possiamo fare un ulteriore passo avanti per rendere il modulo ancora più reattivo agli input dell'utente. Possiamo utilizzare un'espressione per nascondere le schede "Commerciale" e "Residenziale" finché l'utente non seleziona il tipo di immobile. Per farlo, seleziona la scheda e utilizza il campo "Visibilità controllo tramite espressione " per impostare un'espressione che mostri o nasconda la scheda.
Per la scheda "Azienda" utilizzare:
"Tipo" = 'azienda'E per la scheda "Residenziale" utilizzare:
"Tipo" = 'residenziale'
Ora, quando l'utente inserisce i dati nel campo, vedrà solo la scheda "Proprietà" finché non seleziona un'opzione per il campo "Tipo"; è inoltre consigliabile impostare un vincolo "Not null" sul campo "Tipo", in modo che l'utente si ricordi di inserire un valore per la proprietà, altrimenti potrebbe non rendersi conto che ci sono altre informazioni da inserire!
Guarda il video qui.
Esempio 2 - Limitare le modifiche con le espressioni
Ora che abbiamo migliorato l'interfaccia del sondaggio con alcune espressioni, possiamo provare un metodo più avanzato per limitare chi può modificare gli elementi nel nostro progetto. Nel nostro esempio, vogliamo che solo i rilevatori possano modificare le voci create dal proprio team di rilevamento o assegnate a esso.
Abbiamo già un campo in cui registrare il nome utente del rilevatore e il team di rilevamento a lui assegnato. Lo integreremo con una tabella non spaziale che elenca il nome utente di ciascun rilevatore e il relativo team, che si presenta così:
| fid | INT | Chiave primaria |
|---|---|---|
| ID geometra | testo | UUID del record del geometra |
| nome utente | testo | Il valore predefinito è impostato su @mm_username per registrare il nome utente del partecipante al sondaggio |
| squadra | testo | Il team assegnato al geometra; nel nostro esempio ci sono tre team: rosso, blu e verde |
Nella nostra tabella di sondaggio , il campo «surveyor» è impostato come non modificabile e utilizza un'espressione di valore predefinito pari a @mm_username; inoltre, è impostato in modo da applicare il valore predefinito al momento dell'aggiornamento.
Successivamente, configuriamo il campo `survey_team ` come widget di testo con la seguente espressione per il valore predefinito:
attributo(get_feature('surveyors','username',@mm_username), 'team')In questa espressione, procedendo dall'interno verso l'esterno, utilizziamo la funzione get_feature() per recuperare l'elemento nella tabella surveyors che corrisponde al nome utente @mm_username dell'utente corrente. Quindi utilizziamo la funzione attribute() per restituire il valore del campo team per quell'elemento. Questo valore predefinito viene applicato una sola volta al momento della creazione dell'elemento. Disabilitiamo la modifica per questo campo, oppure è possibile utilizzare un'espressione per consentire solo a un utente amministratore di modificare la feature con un'espressione del tipo (sostituire il testo tra parentesi con i nomi utente degli amministratori):
@mm_username IN ('list', 'di', 'admin', "nomi utente")
In questo esempio, aggiungiamo anche un campo booleano al livello del sondaggio denominato «can_edit»; configureremo questo campo con un vincolo di espressione che impedirà agli utenti di salvare le modifiche apportate a un elemento se non fanno parte del team del sondaggio che ha creato o a cui è stato assegnato tale elemento.
Per prima cosa, imposteremo il valore predefinito del campo ` can_edit ` utilizzando la seguente espressione:
attributo(get_feature('surveyors', 'username', @mm_username),'team') MI PIACE "survey_team"
OR
@mm_username IN ('sostituiscilo con','admin','utenti')L'espressione sopra riportata utilizza la stessa funzione impiegata per il valore predefinito nel campo `survey_team` per recuperare l'associazione del team dell'utente corrente e verifica che corrisponda al valore del team di sondaggio assegnato alla funzionalità. L'istruzione che segue l'operatore OR verifica se l'utente è un amministratore. Se l'utente corrente è un amministratore o un membro del team associato alla feature, il valore del campo verrà impostato su true; se non appartiene a nessuno di questi gruppi, sarà false. Assicurati che il valore predefinito sia impostato per essere applicato all'aggiornamento.
Successivamente, creeremo un vincolo basato su un'espressione in modo che l'elemento possa essere salvato solo se il valore del campo can_edit è true:
"can_edit" = veroInfine, assicurati di disabilitare la modifica del campo. Le tue impostazioni dovrebbero essere simili a queste:
Come possiamo vedere nel nostro esempio, questo utente, che fa parte del team rosso incaricato del sondaggio, può modificare solo gli elementi assegnati a quel team. Guarda l'esempio qui.
Molti altri utilizzi delle impostazioni condizionali
Questi sono solo alcuni esempi di come è possibile utilizzare le condizioni nel proprio progetto per migliorare il flusso di lavoro e garantire la qualità dei dati. L'uso delle condizioni consente di personalizzare ulteriormente il progetto, ad esempio con la simbologia condizionale, i vincoli temporali, il riempimento automatico dei campi in base a determinati valori e molto altro ancora. Sfruttando appieno le potenzialità di QGIS ottenere il massimo dal vostro Mergin Maps !