A máquina que é a plataforma do BUPi (Balcão Único do Prédio) é composta por engrenagens de diferentes dimensões, engrenagens essas que sem as quais a máquina colapsa. Segundo os mais recentes e oficiais números, existem 789 pequenas engrenagens que põem a máquina a operar, em que apesar de parte dessas peças estejam inativas e por questões técnicas não podem ser reativadas, cria-se alguns duplicados do que já existia, mas sempre números muito residuais; existe também aquelas peças que chefiam as peças ao seu encargo, que apesar de não trabalharem - porque não é essa a sua função - estão lá para estabelecer o compasso àquelas que devem expor os dentes ao atrito e desgaste.
Para o normal decorrer dos procedimentos de RGG (representação gráfica georreferenciada) diversos workflows podem ser seguidos para além do método de charneira que existe apenas dependente de um explorador da internet. Um desses workflows é o que vou aqui expor, pois é o que eu sigo, e quem quiser é livre de ignorar ou adotá-lo.
Tudo começa fora da plataforma, e não é da parte documental que eu me refiro.
1. Configuração de um SIG para controlo interno.
Quando criar um webSIG é um missão demorada especialmente quando não se quer depender de um lobby da ESRI, começa-se simples e enverga-se para esse fim mais tarde, também por métodos open source, de preferência. Assim, recorrendo ao software QGIS e ao PostgreSQL, cria-se toda a estrutura de base para trabalhar: uma base de dados com ligação PostGIS, carrega-se para a mesma a geopackage/shapefile das RGG pedida à Estrutura de Missão do BUPi (cada Administrador concelhio tem o poder e o dever de o fazer, em vez de estar à espera que enviem), cria-se os devidos estilos de simbologia e, mais importante, de formulários de atributos! Podem ser coisas tão simples como auto-preenchimentos de códigos DICOFRE mediante seleção da freguesia no respetivo campo, incutindo limitações que novos polígonos não serão fechados sem levarem um número de Matriz na freguesia respetiva; no caso dos artigos omissos, uma regra de número de matriz '999999', por exemplo, serve também para assinalar no mapa e expor visualmente os polígonos com número omisso criados pelo(s) técnico(s).
Com recurso às camadas WMS das Ortofotos 2018 e 2021 da DGT, especialmente as 2018, o técnico dispõe das ferramentas mínimas para fazer tudo em SIG e, depois exportar para a plataforma. Deste modo, com o mínimo esforço e empenho, o técnico consegue assegurar que as geometrias se encontram corretas e assegurar, também, o cumprimento de regras topológicas, em vez de tal correção estar a ser feita a posteriori em Base de Dados pela equipa gestora da Plataforma BUPi, seja automática ou manualmente (deplorável se este último caso se aplicar).
Isto funciona individualmente quando todos os técnicos do Município têm os devidos conhecimentos e à-vontade com os softwares SIG e open source, o que nem sempre é verdade um ou outro, ou ambos.
 |
| Extrato do SIG construído, destacando a azul os prédios já com processos terminados com o número de matriz em destaque a amarelo; terrenos a vermelho assinalando os prédios criados pelo técnico que ainda não foram introduzidos em Plataforma, com a área da delimitação no topo da legenda e o artigo imediatamente abaixo; polígonos com preenchimento a amarelo assinalam os prédios com artigo omisso, que assim permanecerão até que o/a promotor(a) contacte o balcão local para términus do Processo pendente por estar com prédio omisso. |
A existência de dados LiDAR para certas zonas do país também permite um ajuda extra através da geração de subprodutos das nuvens de pontos, dando ao técnico a perceção de detalhes que de outra forma não seriam possíveis identificar unicamente por fotointerpretação. A utilização destes produtos de elevado detalhe permite obter a fisionomia mais ou menos aproximadas do que se encontra por baixo da vegetação, permitindo encontrar características que, de acordo com o relatar dos promotores, não seriam percetíveis de todo por imagens de satélite ou ortofotos.
 |
| A mesma zona, diferença recorrendo apenas a ortofoto e recorrendo a um hillshade (azimute 315º, 45º inclinação) do modelo digital de terreno obtido a partir e somente de pontos-terreno das nuvens de pontos obtidas por LiDAR. |
Esta configuração permite uma visualização de detalhes que em plataforma nem sempre é possível, facilitando em muito o trabalho ao técnico.
2. Automatização de processos em SIG
Após desenho das propriedades do promotor, estas podem ser exportadas em série para uma pasta no computador, e depois carregadas individualmente para a plataforma, em cada Processo.
Para tal, foi desenhado um script em Python para exportar cada uma das propriedades individualmente e em KML para uma pasta de destino, passando por selecionar todas as propriedades acabadas de desenhar (seleção confirmada quando a amarelo), e colando no campo de destino o caminho da pasta em questão.
 |
| Cinco prédios prestes a ser exportados, estando todos selecionados. Janela de diálogo aberta aguarda o caminho da pasta para exportação de um ficheiro KML para cada artigo rústico. |
Como forma de agilização do processo aos menos instruídos em scripts Python ou para não se sujeitarem a danificar o script por algum engano no manuseamento do mesmo, dei um passo em frente e libertei-o como um plug-in do QGIS. Este plug-in tem o exato mesmo comportamento do script, estando simplesmente integrado numa interface e acessibilidade gráfica, que apenas requer uns cliques por parte do utilizador para exportar os KML de cada prédio desenhado por meio do QGIS.
Este plug-in encontrar-se-á listado no repositório do QGIS com o nome "Exportador KML Matriz", com o logotipo do BUPi diretamente associado, e tem funcionalidade vinculativa a quem executa a delineação de prédios usando este software, recorrendo à shapefile dos polígonos distribuída pela Estrutura de Missão, usando campo identificador o campo 'NumMatriz'.
, não sendo sabido, segundo o meu melhor conhecimento, de mais algum plug-in do BUPi no repositório. Eis como funciona:
1. Ter a camada das RGG selecionada no painel das camadas - a camada não deve estar em edição e as alterações devem estar guardadas; a omissão deste passo quando se clica no botão do plug-in lançará este aviso:
2. Selecionar a ou as features dos terrenos desenhados, de modo a que fiquem com marcação (preenchimento) a amarelo;
3. Colar o caminho direto da pasta ou usar o botão 'Procurar' da interface para navegar até à pasta onde se pretende exportar os KML.
 |
| Neste exemplo, um polígono pronto a ser exportado, bastando apenas definir o caminho e carregar no OK |
A divulgação do plug-in no repositório do QGIS encontra-se pendente até que a minha conta OSGEO seja aceite (fornecimento de um mantra) para poder carregá-lo para lá. Até lá, divulgo o plug-in sob a forma de uma pasta comprimida, que pode ser carregada para o QGIS seguindo uns simples passos.
Link para o plug-in AQUI
3. O pós-Processo do BUPi
Sempre num ponto de vista de automatizar, encontra-se sempre forma de haver tanta intervenção manual especialmente após uma série de Processos acabados. Quando se dá o caso de ter 20 ou 30 prédios desenhados e transformados em Processos, vai dar origem a 20 ou 30 impressões para o/a promotor(a) assinar. Obviamente que para o técnico é um mal menor, pois produziu toda essa quantidade numa manhã ou numa tarde, mas para finalizar deverá digitalizar todos os termos de responsabilidade assinados, em série ou individualmente, dependendo do tipo de máquina que tenha ao seu dispor ou o que o respetivo software permita fazer.
A fim de precaver os casos em que temos 20, 30, 40, 50, 60 ou mais processos digitalizados e individualmente, para sabermos a qual pertence (para depois submeter Termo de Responsabilidade e fechar o Processo) devemos, à luz da mais recente Plataforma do BUPi, remeter os Termos com o número de Processo. Antes desta mais recente alteração, renomeava os Termos de outro modo, ficando os nomes algo como "Termo[espaço]{Nº Processo}[espaço]{artigo matricial}.pdf". A meu ver, e para gestão pessoal, este seria o método mais correto, uma vez que agora os números de Processo (se do mesmo promotor) se encontram com números sequenciais seguidos.
Fazer isto à mão é moroso e irritante, então para tal desenvolvi um programa em Python, agora compilado e em formato .EXE (executável do Windows). Não o fiz para MacOS porque sinceramente........ continuo à espera de um balcão municipal do BUPi que trabalhe com Macintosh. Quando expandir para os técnicos privados, aí mediante requisito dos leitores e, por sua vez, utilizadores de MacOS, poderei fazer a devida compilação!
Este programa no entanto só vai funcionar se um requisito muito importante for cumprido: os PDF têm que ter OCR realizado (Optical Character Recognition), disponível em vários softwares do hardware usado para digitalizar (da Canon, Epson, HP, etc.). No entanto, o programa, já na sua 4ª versão, conta com uma funcionalidade de OCR em si embutida, disponível para quem não tiver essa possibilidade nos seus balcões de atendimento do BUPi; ainda assim, a lógica do programa mantém-se, tendo apenas sido acrescentado um mecanismo de reconhecimento de caracteres.
Esta nova versão e anterior pode ser consultada acedendo AQUI.
A ferramenta não é à prova de falhas, pelo que a sua eficácia apenas depende da qualidade da digitalização e de um método de OCR bem aplicado.
E apesar de qualquer aviso, não contém qualquer vírus, apenas contém um script Python que manipula dados (os PDF) na pasta que indicar no sistema, logo pede acesso à biblioteca 'os'.
Para breve outras novidades irão surgir, nomeadamente modelos do QGIS para permitir fazer controlo de qualidade ao que se encontra já georreferenciado nos Municípios.
O meu e-mail encontra-se disponível para todos os esclarecimentos necessários.
Fim, para já.