Dados X Qualidade, dores de cabeça evitáveis ao trabalhar e produzir dados
Quem nunca passou horas tentando fazer um processamento que sempre retornava um erro mencionando um tal de “caractere ASCII”, ou ficou dias tentando plotar algumas coordenadas geográficas usando um CSV que não desenhava na tela ou caiam em algum lugar errado.
Quem nunca tentou fazer um somatório de um campo que retornava um valor absurdo.
Pois é sobre isso que vou tratar nesse post de hoje, uma experiência que foi bem divertida de se ter, mas que rendeu boas dores de cabeça e muitas, muitas, xícaras de café até descobrir que era um nome de arquivo que não seguia algumas regrinhas básicas.
Na experiência que venho tendo nesses quase seis anos de trabalho com dados geográficos, e boa parte deles trabalhando na análise de dados produzidos, tanto dentro quanto fora do órgão, venho percebendo que essa parte importante vem sendo deixada de lado, a qualidade dos dados produzidos, seja por desconhecimento das ferramentas, a não observação de algumas regras de boas práticas ou a não observação das regras que aqueles que vão receber esses dados estipularam.
Esse conjunto de boas práticas pode agilizar o seu trabalho, facilitando a recuperação desses dados no futuro e bem como a continuação do seu trabalho por outros profissionais.
Tenha essas regras sempre por perto, e sempre, sempre recorra a elas antes, durante e depois do seu trabalho.
Vamos a elas:
Tamanho do “nome” do caminho do arquivo.
Pasta_1\
Pasta_2\
…
Pasta_100\ seu_arquivo
Esse item é um problema que incomoda bem, principalmente usuários do Windows.
Ao organizar os arquivos, as pessoas costumam ir colocando pastas dentro de pastas, e algumas vezes o S.O. não consegue lidar bem com isso e na hora de acessar o dado para ser recuperado, faz com que o arquivo comporte como se estivesse corrompido, ou quando vai copiar para um pendrive, o sistema dispara um erro impedindo a cópia, sendo necessário utilizar um programa que faça essa cópia contornando esse problema.
Portanto, evite organizar os dado usando pastas de pastas dentro de pastas.
Nomenclatura dos arquivos e pastas.
Nomes de arquivos, pastas, e até mesmo do seu usuário do sistema operacional utilizado, podem ser uma grande dor de cabeça por conta dos CARACTERES ESPECIAIS.
Acentos, pontuação, símbolos especiais, letras com acentos são considerados caracteres especiais e existe hoje uma quantidade imensa de formas de o seu computador processar a forma de como ele vai te mostrar esses caracteres, juntamente com essa quantidade uma infinidade de sistemas operacionais, S.O, não apenas Linux, Mac OS, Android e Windows e portanto, temos a necessidade de desenvolver softwares que operem em qualquer plataforma, um exemplo é o QGIS, que nasceu da necessidade de se trabalhar SIG em Linux e hoje funciona nesses sistemas mencionados.
E cada forma dessa de identificar os caracteres pelos computadores é chamada de ENCODING, no bom português, codificação (lembra da tabela de atributos???), as mais famosas são UTF-8 (padrão em sistemas baseados em Linux e diversos sites da internet, por exemplo) , WINDOWS-1252 (utilizado no Windows).
Cada S.O. pode definir qual codificação será adotada, e isso interfere no nosso trabalho, pois o “código” que faz com que o sistema interprete “ç”, por exemplo, em uma codificação pode fazer representar um outro caractere diferente em outra codificação, ou nem mesmo existir.
Isso faz com que sua tabela de atributos fique com aqueles caracteres esquisitos nos nomes dos campos e nos dados lá dentro, ou que cause algum problema durante o processamento do seu dado.
Mas, isso não acontece com os caracteres normais, sem acentos, como as letras de A a z, os números de 0 a 9 e o caractere que mais recebe nomes de todos: Underlinte, underscore, sublinhado, “tracinho em baixo”.
Esses caracteres são os mesmos em todas as codificações, portanto, utilizar eles reduz a chance de seu software travar, quebrar durante o processamento dos dados.
Portanto abusem da utilização desses caracteres, e utilize o “_” no lugar do espaço e evitem utilizar caracteres especiais.
E isso nos leva ao próximo tópico.
Nomenclatura dos campos das tabelas e de tabelas.
Outra grande dor de cabeça de quem precisa trabalhar os dados é essa parte.
Hoje com essa quantidade de sistemas operacionais, codificações e até mesmo a facilidade do uso de ferramentas de programação, como linguagem de programação (Python, por exemplo), banco de dados (Spatialite, Postgis…) SQL, linguagem utilizada para fazer consulta e manipulação dos bancos de dados, traz vários problemas ao se utilizar os dados produzidos.
A não observação dessa boa pratica, pode fazer com que o software/algorítimo/comando utilizado não consiga lê o campo correto, ou tabela, em função da presença de caracteres especiais, caracteres em caixa alta.
Fica aqui as boas práticas:
- Não utilize caracteres especiais (mesmo motivo do item anterior)
- Utilize os nomes em caixa baixa (é uma mão na roda principalmente quando usa-se SQL)
- Inicie os nomes com letras, e não números (alguns bancos de dados não lidam bem com números no começo de nomes de tabelas ou de campos, nem mesmo o “_”)
Essas regras também servem para o nome de arquivos, pois os arquivos, normalmente viram uma tabela em um banco de dados para serem analisados mais rápido.
Configuração do campo e tipo do dado.
Outra dor de cabeça, já tentou somar o campo área dentro de uma camada e o comando não funciona? Ou já tentou organizar um campo que contém apenas números mas os dados continuam fora da ordem? Então… esse é um dos motivos.
Durante a produção do dado, seja pela pressa ou desatenção acabamos cometendo o erro de não configurar o campo corretamente, de acordo com o tipo de dado que vai lá dentro.
Exemplo: O dado entre parênteses é a configuração do campo.
|
id (text, 2)
|
area (text, 20)
|
perimetro (text, 15)
|
|
1
|
50 ha
|
25.234,60
|
|
2
|
32
|
13,440.90
|
Nessa tabela acima encontramos muitos problemas, são eles.
- Tipo do dado X Configuração do campo.
Os campos estão configurados como texto mas o tipo dos dados lá dentro são todos numéricos.
Isso acarreta problemas na organização do dado, se a tabela possuísse 20 itens, por exemplo, ao tentarmos organizar em ordem crescente, pelo campo id, não teríamos o resultado esperado, pois os números seriam tratados como texto, e a sequencia ficaria aproximadamente na seguinte forma: 1, 10, 11, 12… Mas se o campo estivesse configurado com número inteiro, eles ficariam na ordem de 1 a 20.
- Dados numéricos misturados com texto.
Esse é um erro bem clássico, observe o campo “area”, teríamos problemas ao tentar somar as áreas da nossa camada pois temos textos misturado com número. Esse campo deveria ser configurado REAL, e a informação de que a unidade de medida é o HECTARE deveria vir no nome do campo, em um dicionario de dado ou metadado, que iremos tratar mais a frente.
- Falta de padronização dos dados numéricos e de data.
Esse é outro erro que sempre passa desapercebido de muitos, e que causa bastante dor de cabeça. No campo perímetro, o separador de decimal, hora aparece como virgula, hora aparece como ponto, ou mesmo com o separador de milhar.
É necessário tomar essa precaução sempre…
Uma dica é:
> Usar sempre o ponto como separador de decimal (seguindo os padrões dos bancos de dados)
> Coordenadas Geográficas sempre com o sinal de – indicando o semisfério. (-19.4322, -42.3556
> Coordenadas em Grau Minutos e Segundos (GMS) sempre separados por espaço ( -19 33 45.2347, -42 22 36.7775)
> Data, sempre utilize no seguinte formato AAAA-MM-DD, ou AAAA-MM, que é o formato aceito pelas bases de dados existentes hoje…
Outro problema enfrentado na geração e análise dos dados é referente a GEOMETRIA, que ficará para outro tópico, onde veremos os erros de geometria mais comuns e como tratá-los no QGIS…
Até a proxima!
#ThinkFree
Tagged with: Dados x Qualidade
4 thoughts on “Dados X Qualidade, dores de cabeça evitáveis ao trabalhar e produzir dados”