A utilização de expressões condicionais no seu projeto de levantamento pode ser uma excelente forma de aumentar a precisão da recolha de dados no terreno. O uso QGIS pode ser uma ferramenta poderosa para melhorar a usabilidade do seu levantamento no terreno. Graças à flexibilidade do QGIS, existem muitas formas de utilizar esta ferramenta, mas iremos apresentar alguns exemplos para o ajudar a dar os primeiros passos.
Exemplo 1 - Restringir campos com expressões
Por vezes, os formulários de inquérito complexos podem tornar-se confusos ou difíceis de visualizar para os inquiridos que registam dados em ecrãs de dispositivos mais pequenos. Uma forma de tornar os seus formulários mais simples é utilizar expressões para mostrar apenas os campos a que o inquirido precisa de aceder.
Por exemplo, pode estar a realizar um levantamento de imóveis que exija o preenchimento de campos específicos, dependendo do tipo de imóvel. Obrigar o utilizador a percorrer cada secção do formulário até encontrar os campos necessários pode ser confuso e demorado para os responsáveis pelo levantamento. Em vez disso, pode utilizar expressões condicionais para apresentar apenas os campos obrigatórios, dependendo do tipo de imóvel que está a ser levantado.
Vamos começar com um projeto de exemplo simples para o nosso levantamento de propriedades. Temos um mapa de fundo e uma camada de pontos chamada «survey» para registar as informações de cada propriedade. A tabela da camada «survey» é a seguinte:
| Campo | Tipo | Descrição |
|---|---|---|
| fid | INT | chave_primária |
| uuid | texto | ID único |
| topógrafo | texto | Campo para registar o nome de utilizador do topógrafo |
equipa_de_inquérito | texto | Registar a equipa de levantamento topográfico designada para o imóvel |
| criado | data/hora | Data e hora em que o registo foi criado |
| última atualização | data/hora | Data e hora da última atualização da funcionalidade |
| n.º da rua | INT | Número da rua |
| nome_da_rua | texto | Nome da rua |
| código postal | texto | Código postal |
| pisos | INT | Número de andares |
| tipo | texto | Tipo de imóvel (comercial ou residencial) |
| nome_do_autocarro | texto | Nome da empresa |
| tipo de autocarro | texto | Tipo de negócio |
| tipo_de_registro | texto | Tipo de casa (bungalow, moradia geminada, casa de campo, etc.) |
| res_estacionamento | texto | Tipo de estacionamento disponível na casa (na rua, na entrada, na garagem) |
| res_occupeid | Booleano | A residência está ocupada? |
Uma forma de facilitar a utilização deste formulário pelo avaliador é organizar os campos em separadores, utilizando o Designer de Arrastar e Soltar. Podemos organizar o nosso inquérito em três separadores: Imobiliário, Empresarial e Residencial, com um campo para os dados do avaliador no primeiro separador:
Agora que os campos estão organizados, podemos dar mais um passo para tornar o formulário ainda mais responsivo às entradas do utilizador. Podemos utilizar uma expressão para ocultar os separadores «Comercial» e «Residencial» até que o utilizador escolha o tipo de imóvel. Para tal, selecione o separador e utilize o campo «Visibilidade do controlo por expressão» para definir uma expressão que mostre ou oculte o separador.
Na secção «Negócios», utilize:
"Tipo" = 'negócios'E, no separador «Residencial», utilize:
"Tipo" = 'residencial'
Agora, quando o utilizador estiver a introduzir dados no campo, só verá o separador «Propriedade» até selecionar uma opção para o campo «Tipo ». É também uma boa ideia definir uma restrição «Não nulo» no campo «Tipo», para que o utilizador se lembre de introduzir um valor para a propriedade; caso contrário, poderá não saber que há mais informações a recolher!
Veja o vídeo aqui.
Exemplo 2 - Restringir edições com expressões
Agora que melhorámos a nossa interface de levantamento com algumas expressões, podemos experimentar um método mais avançado para restringir quem pode editar elementos no nosso projeto. No nosso exemplo, queremos que apenas os topógrafos possam editar entradas criadas pela sua equipa de levantamento ou a ela atribuídas.
Já dispomos de um campo para registar o nome de utilizador do topógrafo e a equipa de levantamento que lhe foi atribuída. Vamos complementar isto com uma tabela não espacial que enumera o nome de utilizador de cada topógrafo e a sua equipa, com o seguinte aspeto:
| fid | INT | Chave primária |
|---|---|---|
| id_do_topógrafo | texto | UUID do registo do topógrafo |
| nome de utilizador | texto | O valor predefinido foi definido como @mm_username para registar o nome de utilizador do inquérito |
| equipa | texto | A equipa designada ao topógrafo; no nosso exemplo, existem três equipas: vermelha, azul e verde |
Na nossa tabela de inquéritos , o campo «inquiridor» está definido como não editável e utiliza uma expressão de valor padrão @mm_username, estando o campo configurado para aplicar o valor padrão aquando da atualização.
Em seguida, configuramos o campo survey_team como um widget de texto com a seguinte expressão de valor padrão:
atributo(get_feature('topógrafos','username',@mm_username), 'equipa')Nesta expressão, trabalhando de dentro para fora, utilizamos a função get_feature() para recuperar o elemento da tabela surveyors que corresponde ao nome de utilizador @mm_username do utilizador atual. Em seguida, utilizamos a função attribute() para devolver o valor do campo team desse elemento. Este valor predefinido é aplicado apenas uma vez, quando o elemento é criado. Desativamos a edição deste campo, ou pode utilizar uma expressão para permitir que apenas um utilizador administrador edite o elemento com uma expressão como (substitua o texto entre parênteses pelos nomes de utilizador dos utilizadores administradores):
@mm_username IN ('lista', 'de', 'admin', 'nomes de utilizador')
Neste exemplo, adicionamos também um campo booleano à camada do inquérito chamado «can_edit»; vamos configurar este campo com uma restrição de expressão que impedirá os utilizadores de guardar alterações num elemento se não fizerem parte da equipa do inquérito que criou ou à qual o elemento está atribuído.
Primeiro, vamos definir o valor padrão do campo can_edit com a seguinte expressão:
atributo(get_feature('topógrafos', 'username', @mm_username),'team') ILIKE "equipa_inquérito"
OU
@mm_username IN ('substitua isto por','admin','utilizadores')A expressão acima utiliza a mesma função usada para o valor padrão em ` survey_team ` para recuperar a associação do utilizador atual a uma equipa e verifica se esta corresponde ao valor da equipa de inquérito atribuída ao recurso. A instrução após o operador OR verifica se o utilizador é um utilizador administrador. Se o utilizador atual for um administrador ou membro da equipa associada ao recurso, o valor do campo será definido como verdadeiro; caso não pertença a nenhum desses grupos, será falso. Certifique-se de que o valor padrão está definido para ser aplicado na atualização.
A seguir, vamos criar uma restrição baseada numa expressão para que o elemento só possa ser guardado se o valor do campo can_edit for verdadeiro:
"can_edit" = truePor fim, certifique-se de desativar a edição nesse campo. As suas configurações devem ficar semelhantes a isto:
Como podemos ver no nosso exemplo, este utilizador, que faz parte da equipa de inquéritos vermelha, só pode editar os elementos atribuídos a essa equipa. Veja o exemplo aqui.
Muitas outras utilizações das configurações condicionais
Estes são apenas alguns exemplos de como pode utilizar condições no seu projeto para melhorar o fluxo de trabalho e garantir a qualidade dos dados. A utilização de condições permite uma maior personalização do seu projeto, como simbologia condicional, restrições temporais, preenchimento automático de campos com base em determinados valores e muito mais. Aproveitar todo o potencial do QGIS ajudá-lo a tirar o máximo partido do seu Mergin Maps !