Construindo uma lista de verificação de aceitação do GNSS Land Survey

Comece com o uso pretendido

Uma lista de verificação de aceitação deve expressar o que o projeto precisa do Land Survey e quais evidências suportam essa decisão. Não é simplesmente uma lista de mensagens de status do receptor. Um conjunto de dados usado para localização aproximada de ativos pode ter requisitos diferentes de um usado para transferir o controle ou dar suporte ao design sensível à altura. Defina os requisitos horizontais, verticais e de atributos separadamente para que a revisão não recolha várias questões diferentes em uma reivindicação de precisão vaga.

Concordar os critérios antes da produção, sempre que possível. A equipe precisa saber quais observações exigem repetições, quais verificações são independentes e como as exceções serão tratadas. Uma lista de verificação criada somente após a coleta dos dados pode expor as lacunas, mas nem sempre substitui as evidências de campo ausentes. Mantenha o plano de aceitação conectado ao método de coleta em vez de tratar a revisão final como uma atividade separada do escritório que repara todas as omissões anteriores.

Continue aprendendo Uma lista GNSS prática antes de registrar pontos

Verifique a base de referência

Confirme o sistema de referência de coordenadas, unidades, ordem do eixo e definição de altura. Revise a origem das coordenadas de base ou controle e de qualquer transformação local. Verifique se a revisão aprovada foi realmente usada durante cada período de trabalho. Um arquivo de coordenadas pode estar internamente organizado ao se referir ao sistema errado; portanto, a verificação de referência deve ocorrer antes dos resumos estatísticos ou da formatação cosmética.

Trace a geometria da antena como parte da mesma base. O revisor deve encontrar a identificação da antena, o método de medição de altura e os registros de configuração para sessões relevantes. Se um componente foi alterado, identifique o intervalo afetado. Não assuma que um modelo de receptor em uma lista de equipamentos estabelece a geometria física de cada sessão de medição. A lista de verificação deve solicitar evidências que possam ser vinculadas às observações, não apenas uma afirmação geral de que o equipamento foi usado corretamente.

Continue aprendendo Escrevendo um relatório de pesquisa GNSS Land que suporta a saída do projeto de coordenadas

Revise as evidências de qualidade do campo

Inspecione os resultados de verificação independentes e as sessões de medição repetidas de acordo com o plano do projeto. Compare os componentes horizontais e verticais, examine os padrões espaciais e mantenha as exceções. Uma pequena média geral não justifica ignorar uma grande discrepância em uma extremidade de um projeto. Confirme se os pontos usados para se adequar a uma transformação são distinguidos dos pontos reservados para testá-la, pois essas funções fornecem evidências diferentes.

Reveja os estados da solução, interrupções de correção e ambientes de observação difíceis, juntamente com as verificações externas. As estimativas internas do receptor podem apoiar a avaliação, mas seu significado depende do equipamento e do modelo. Mantê-los distintos da concordância comprovada com o controle. Se as verificações planejadas não foram concluídas, registre a lacuna e decida qual trabalho adicional é necessário, em vez de substituir as evidências que faltam por um adjetivo mais confiante no relatório.

Continue aprendendo Completar um projeto GNSS entrega dos resultados do projeto que outros podem usar

Examine a completude e o significado

Verifique se a área e os tipos de recursos necessários foram cobertos. Uma coordenada precisa não é útil se o ativo ou linha pretendido mostrando uma mudança na inclinação do terreno foi omitido. Compare registros de campo com o plano de trabalho, mapas e dicionário de recursos. Verifique os atributos obrigatórios e explique os valores desconhecidos. A revisão de aceitação deve preservar a incerteza em que a equipe não pôde observar um recurso, em vez de recompensar os valores inventados que apenas preenchem todas as células.

Inspecione os identificadores de pontos e as relações entre sessões de medição repetidas, fotografias e recursos finais. Confirme se as duplicatas foram resolvidas por meio de um processo documentado e que a renomeação não interrompeu os links de evidências. Para trabalhos de linha e polígonos, verifique a conectividade e a interpretação física, bem como os valores das coordenadas. Um arquivo pode conter geometria válida enquanto ingressa na sequência errada de pontos observados ou descreve uma parte diferente de um recurso do que o cliente espera.

Continue aprendendo Projetando um painel de qualidade de projeto GNSS

Verifique o processamento e o histórico de revisões

Revise as conversões do material, transformações e correções de coordenadas. Preserve os arquivos de origem e a base de cada revisão aceita. Se um erro foi corrigido, verifique o escopo afetado e as verificações no resultado revisado. Um rótulo final não deve apagar a diferença entre as observações coletadas corretamente e as observações posteriormente reparadas por meio de um processo aprovado. Ambos podem ser utilizáveis, mas seus históricos de evidências devem permanecer compreensíveis.

Confirme se as saídas provisórias e substituídas estão claramente marcadas. Se os dados de observação do GNSS não processados aguardarem o processamento, mantenha-os fora da entrega de coordenadas aceitas, a menos que o status seja explícito e apropriado para a entrega dos resultados do projeto. A lista de verificação deve impedir que um arquivo seja aprovado apenas porque está em uma pasta chamada Final. A aprovação pertence a um conjunto de dados definido e a revisão suportada por uma revisão registrada.

Continue aprendendo Uma lista GNSS prática antes de registrar pontos

Teste o formato de entrega

Abra a saída do projeto no software de destino pretendido e inspecione os registros representativos. Verifique o posicionamento das coordenadas, alturas, unidades, identificadores, atributos e codificação de caracteres. Uma importação bem-sucedida confirma que o programa aceitou a sintaxe; Isso não prova que os dados significam o que o usuário assume. Compare os pontos e recursos conhecidos após a importação com a interpretação do teste, bem como a legibilidade do arquivo.

Verifique os metadados e os links de suporte da entrega do local dos resultados do projeto. Um índice de fotos que aponta para uma unidade local temporária não é uma entrega completa. Para GeoJSON ou outros formatos padronizados, siga os requisitos de formato em vez de assumir que qualquer tupla de coordenadas é aceitável. Preserve as configurações de exportação e identifique os arquivos de saída aprovados em um manifesto para que o cliente possa distingui-los de arquivos de trabalho e formatos alternativos.

Continue aprendendo Escrevendo um relatório de pesquisa GNSS Land que suporta a saída do projeto de coordenadas

Lidar com exceções explicitamente

Crie um registro conciso de exceção com identificadores afetados, razão, consequência e resolução. Algumas exceções podem ser aceitáveis no escopo do projeto; Outros exigem medição ou processamento adicional. O revisor deve ser capaz de ver a base dessa decisão. Evite ocultar pontos não resolvidos em uma isenção de responsabilidade geral que não fornece uma maneira prática de localizá-los no conjunto de dados.

Se uma exceção alterar a adequação de um uso específico, indique essa consequência claramente. Por exemplo, um invertido de drenagem não observado não deve ser tratado como uma altura medida na análise posterior. O processo de aceitação deve conectar as evidências a serem usadas, incluindo limitações. É melhor liberar um conjunto de dados honesto e claramente limitado do que implicar uma confiança uniforme em pontos coletados em condições materialmente diferentes ou não verificadas.

Continue aprendendo Completar um projeto GNSS entrega dos resultados do projeto que outros podem usar

Registre a decisão de aprovação

Identifique o revisor, a revisão do conjunto de dados, a data de revisão e os registros de suporte de acordo com o fluxo de trabalho do projeto. Inclua ações não resolvidas e quaisquer condições de uso. Mantenha a lista de verificação suficientemente concisa para ser aplicada de forma consistente, com links para evidências detalhadas em vez de relatórios duplicados. Um formulário preenchido deve representar uma avaliação real, não uma assinatura adicionada porque cada caixa pode ser marcada sem abrir os arquivos.

Como teste prático, pergunte se outro colega pode identificar o sistema de coordenadas aprovado, verificações e exceções relevantes sem falar com a equipe de medição externa. Caso contrário, melhore o pacote antes do lançamento. A aceitação da pesquisa em terras é uma decisão fundamentada com base em definições de referência, observações, processamento e uso pretendido. A lista de verificação é bem-sucedida quando torna essa decisão concreta, reproduzível e compreensível para as pessoas que dependerão das coordenadas.

Verifique se todos os formatos de saída do projeto representam a mesma revisão aprovada. Uma camada GIS corrigida e uma planilha mais antiga podem parecer finais enquanto discordam. Compare identificadores e coordenadas representativos nas exportações e, em seguida, liste os arquivos liberados em um manifesto. Isso evita que um problema de pesquisa de terras resolvido reapareça por meio de um formato alternativo substituído.

Continue aprendendo Projetando um painel de qualidade de projeto GNSS