Closed crebollobr closed 2 years ago
Eu recomendo refazer o processo para o layer geoaddress. Não por existir algo errado, mas porque podemos extrair mais dos dados. Especialmente, por se tratar de geoaddress
, core da A4A.
Explico.
O procedimento manual realizado, descrito em https://github.com/digital-guard/preserv-BR/tree/main/data/SP/Guarulhos/_pk0081.01#procedimento-de-join-geoaddress-e-via, acaba desconsiderando dados, não aproveitando as capacidades do software atualmente existente e dificultando a reprodutibilidade.
Acaba desconsiderando dados porque os nomes de rua foram obtidos nos dados filtrados e não nos dados brutos. Como a diferença do segundo para o primeiro pode ser não vazia, pode-se perder nomes de rua.
Com isso, e levando em conta o que eu disse em https://github.com/digital-guard/preserv-BR/issues/92#issuecomment-1117848586, eu adaptei o make_conf.yaml em https://github.com/digital-guard/preserv-BR/commit/b67a7c083e22708d36deb536395046b07bd2adf0.
Assim, teremos 288374 pontos com nome de rua, ao invés de 284101:
any_load
-------------------------------------------
From file_id=1 inserted type=address_cmpl+
in cadastral_asis 7195 items.
(1 row)
any_load
------------------------------------------------------------------------
From file_id=2 inserted type=geoaddress_ext. +
Resulting in feature_asis: 289917 +
(1 row)
------------------------------------------
------ Join entre geoaddress_ext e address_cmpl ------
psql postgres://postgres@localhost/ingest88 -c "SELECT ingest.join('geoaddress_ext','cod_log','1641b8c5fe5a2e9141939bb7353bda4fda1ea04d7a631a4d012e4759d1bf8447.zip','address_cmpl','cod_log','47910adcd297a9ba875d89dacc91bc6b2a37d6eab4910964253e117c1484b4c5.zip')"
join
--------------------
Join 288374 items.
(1 row)
Então, com a modificação no make_conf, você pode utilizar make join-geoaddress
e desconsiderar o procedimento manual.
Corrigido no readme
Fiz a atualização de geoaddress e o merge da branch.
Validar a publicação da branch 20220506