• Nenhum resultado encontrado

VALIDAÇÃO DAS INFORMAÇÕES EXTRAÍDAS A PARTIR DE LEVANTAMENTO MOBILE MAPPING

Atividade de Gabinete: base de dados

7 VALIDAÇÃO DAS INFORMAÇÕES EXTRAÍDAS A PARTIR DE LEVANTAMENTO MOBILE MAPPING

Antes de falar de completude, consistência e exatidão, é preciso relembrar alguns conceitos importantes pré-definidos para o cadastro. Os Pontos de Iluminação Pública (PIPs) representam os apoios de luz provenientes de cada ponto de luz, esteja ele em uma luminária ou projetor. Dessa maneira, podemos encontrar apoios com mais do que um ponto de luz. A partir do software Orbit, foi feito um levantamento cadastral e geográfico de todos os pontos de luz (PIPs), entretanto, quando esses PIPs eram transportados para a base de dados no software PgAdmin, eles se conectavam ao seu respectivo apoio (poste, braço, MUPI, etc). Ou seja, o apoio pode ter dois tipos de conexão: estar ligado a somente um PIP, ou estar ligado a vários PIPs. Essa conexão se estabelece através dos campos “id_pip” e “temp_id”.

O shape utilizado no software Orbit como base para o levantamento dos PIPs, foi o shape cedido pela CMO em parceria com a EDP, que localizava em forma de pontos todos os apoios de iluminação pública do município de Oeiras, e trazia consigo uma identificação no campo “id_pip” que foi preservada. Entretanto, essa shape só trazia informação de uma luminária ou projetor para o apoio. Sendo assim, quando tínhamos mais do que um ponto de luz (PIP) para o mesmo apoio, era necessário replicar o ponto já previamente plotado como apoio, para que fosse possível preencher as informações referentes ao cadastro do PIP. Mas ao conectar a base de dados, os PIPs também precisavam conectar com o seu respectivo apoio. Para tal, foi desenvolvido um parâmetro:

Se o apoio tiver mais do que um PIP, o primeiro PIP cadastrado irá manter o “id_pip” e preencher o campo “temp_id” com um atributo único. Para os outros PIPs a serem cadastrados a seguir, o “id_pip” terá que ser obrigatoriamente zero, e o “temp_id” igual ao primeiro PIP deste apoio. Para as situações em que os PIPs identificados não apresentam um apoio já plotado previamente na shape, foram criados pontos. Como os novos pontos não terão atributos para o campo “id_pip”, foi estabelecido que toda vez que um apoio novo fosse criado, o valor a ser inserido para o “id_pip” era “50000”. Uma vez que todos os novos apoios foram criados sob o mesmo atributo, foi utilizado o campo “temp_id” para diferenciá-los. Se o novo apoio também tiver mais do que um PIP, o processo a ser realizado é o mesmo realizado nos PIPs que possuem apoios previamente plotados. Para melhor ilustrar as situações exemplificadas, foram elaboradas tabelas com valores fictícios, que serão apresentadas a seguir (Tabelas 2, 3 e 4).

Tabela 2: Representação dos valores a serem inseridos para situações em que o Apoio apresenta mais do que um PIP associado

Tabela 3: Representação dos valores a serem inseridos para situações em que será criado um apoio novo com apenas um PIP associado.

Tabela 4: Representação dos valores a serem inseridos para situações em que será criado um apoio novo com mais do que um PIP associado.

A fim de possibilitar a reprodução desse tipo de situação em outros trabalhos, bem como a total compreensão do que foi apresentado anteriormente, será demostrado a seguir as linhas de comando utilizadas no software PgAdmin durante o processo de importação dos dados extraídos a partir do software Orbit.

 Inserção de novos Apoios:

insert into iluminacao_publica.ponto_iluminacao_publica (the_geom,altura, n_bracos, n_luminari, obs_gerais, rua, temp_id, tipo_rede, tipo_apoio, tipo_coluna)

FROM apoio.ip_medidas_30 as t where t.id_pip = 50000;

 Inserção de novos PIPs no Apoio já existente:

insert into iluminacao_publica.ip_luminaria (obs_gerais, braco_comp, braco_altu, braco_incl, braco_obs, largura_rua, larg_pass_adj, larg_pass_op, estacionam_adj, estacionam_op,

dist_lancil, dist_apoio_anterior, dist_edificio, medidas_obs, modelo, rua, temp_id )

SELECT t.obs_gerais, t.braco_comp, t.braco_altu, t.braco_incl, t.braco_obs, t.largura_ru, t.larg_pass_, t.larg_pas_1, t.estacionam, t.estacion_1,

t.dist_lanci, t.dist_apoio, t.dist_edifi, t.medidas_ob, t.modelo_lum::integer, t.rua::integer,t.temp_id FROM apoio.ip_medidas_3 as t

where t.id_pip = 0;

update iluminacao_publica.ip_luminaria as l set cod_ent_ligacao = t.cod_entidade

from iluminacao_publica.ponto_iluminacao_publica as t where l.cod_ent_ligacao is null and l.temp_id = t.temp_id

7.1 Completude

A validação final entre os dados extraídos em gabinete e o mundo real, é feita em campo. Uma vez que todo dado extraído é importado para a base de dados, que se conecta com o portátil, podendo então ser verificado ponto a ponto durante a atividade de campo. Em gabinete o controle feito para identificar excesso ou ausência de dados é realizado através de um controle de qualidade, que conta com queries de restrições e alertas. Sendo elas:

 Se o número de braços for maior do que um, o número de PIPs no apoio tem que ser igual ao número de braços. Ou seja, a quantidade de vezes em que o “temp_id” se repetir para um determinado apoio, tem que ser igual ao número de braços.

 Se o número de braços for igual a zero, o PIP só poderá apresentar alguns modelos específicos de luminárias. Não sendo, o programa irá emitir um alerta para que a situação seja conferida, já que pode haver exceções

7.2 Consistência:

Para estabelecer uma boa concordância dos dados com as regras do modelo, foram criadas tabelas com parâmetros e restrições que afirmassem a consistência conceitual, de formato, domínio e topológica.