Dados da Neoenergia - Githubissues

crebollobr commented 1 year ago

Os dados são de postes. Precisaria criar um novo tipo de dado.

neoenergia

IgorEliezer commented 1 year ago

Não vejo utilidade para o projeto A4A o cadastro de postes. A não ser para importar no OpenStreetMap (a comunidade BR ficou interessada em uns sites de de iluminação pública - ex: 1 e 2) e, muito marginalmente, uma vez importado, para o Alertas Primeira Infância para análise a qualidade de iluminação das vias públicas para o uso das pessoas. (cc. @ppKrauss )

ppKrauss commented 1 year ago

Realmente não são tão importantes quanto endereços, mas foi a diretiva tomada na época e continua valendo:

Ajudam a confirmar e caracterizar faces de quadra, um dado importante, tornando mais precisos nossos algoritmos de inferência por face de quadra.
ao contrário dos portões de casa e centroides de lote, as posições de poste (com relação às vias) são mais padronizadas, a maior parte nas calçadas. Fornece uma referência para a "Linha de testada".
PS: a coleta de dados por GPS desses dados, todos pela mesma empresa, em geral apresenta incerteza uniforme e obedece a padrões mínimos de qualidade igualmente uniformes.
são relevantes para outros projetos e clientes, em particular operadoras de Telecomunicação podem somar esforços na gestão desses dados.

0e1 commented 11 months ago

Sobre quais dados trata a issue?

No repositório temos o pacote _pk0147.01 com dados da NeoEnergia. Criei o rascunho de make_conf. Falta o seguinte:

determinar o srid
entender como obter geom a partir de NOXPE e NOYPE
decidir se realmente são posições de postes

Observar que utilizei o layer geopoint para esses dados supondo que sejam postes. Esse layer foi criado em https://github.com/digital-guard/preserv/commit/6a0e5db6e0aca49ae9bf94052df2a7841c6996f4 com o respectivo layer cadastral cadgeopoint para elementos de tipo listados em https://github.com/digital-guard/preserv/issues/91

Extrato do arquivo:

head -n 100 NEOEKT_ADDRESSFORALL.csv 
"CONTA";"NOXPE";"NOYPE";"TIPO_LOGRADOURO";"LOGRADOURO";"NUMERO";"COMPLEMENTO";"BAIRRO";"CEP";"CIDADE"
"6405320";"955593,012";"7435941,216";"R";"PAPA PAULO VI";"113";"";"VL THAIS";"12942110";"ATIBAIA"
"1967746";"478107,343";"7674907,791";"R";"BENEDITO BEN-HUR LOUZADA";"218";"";"CENTRO";"16980000";"GUARACAI"
"1969536";"478267,352";"7674257,159";"R";"NOSSA SRA APARECIDA";"922";"";"CENTRO";"16980000";"GUARACAI"
"13341499";"580735,361";"7716881,903";"R";"CESARIO ALVES VIEIRA";"1145";"";"JD SORAIA";"15310000";"MAGDA"

No repositório temos ainda os pacotes _pk0148.01, _pk0149.01, _pk0150.01.

Também criei make_conf para eles, mas supus que são pontos de endereço. Fiz ajustes necessários para todos funcionarem, principalmente _pk0150.01.

Não fiz ingestão e publicação. É preciso que verifiquem os make_conf. Principalmente, srid, codec, se o tipo de layer está adequado, etc, antes de prosseguir com o workflow.

Ainda, dados da NeoEnergia (entre outros) já foram discutidos em https://docs.google.com/document/d/1jff3PeYXa9UJtSr6JvGuSG-9U4NWr7zciGmtR3-6g4M.

crebollobr commented 11 months ago

@0e1 Geopoint não funcionou

cd /var/gits/_dg/preserv/src
git pull
psql -U postgres
drop database ingest20 WITH (FORCE);
make ini_ingest pg_db=ingest20

cd /var/gits/_dg/preserv-BR/data/RN/_pk0149.01
git pull
make me pg_db=ingest20

make geopoint pg_db=ingest20
make: *** No rule to make target 'geopoint'.  Stop.

crebollobr commented 11 months ago

@IgorEliezer não consegui achar o srid https://github.com/digital-guard/preserv-BR/issues/149 Tentei com o https://epsg.io/transform, projfinder.com e https://coordinates-converter.com/

0e1 commented 10 months ago

@0e1 Geopoint não funcionou

Adicionei aos templates em https://github.com/digital-guard/preserv/commit/f8a9153e4be2defdd6c78291c86cd1e95403e123. Agora existe o target.

É Importante resolver os problemas que listei em https://github.com/digital-guard/preserv-BR/issues/149#issuecomment-1747637405:

No repositório temos o pacote _pk0147.01 com dados da NeoEnergia. Criei o rascunho de make_conf. Falta o seguinte:
* determinar o srid

* entender como obter `geom` a partir de `NOXPE` e `NOYPE`

* decidir se realmente são posições de postes

IgorEliezer commented 10 months ago

A pedido de Luan Manoel, estou dando uma olhada nos arquivos da Neoenergia que estão no armazenamento de @ThierryAJean.

Primeiramente, estes arquivos não passaram por mim, portanto não tinha conhecimento do estado deles até hoje. Espero que sejam os mesmos que estão sendo discutidos nesta issue.

O que temos

4 zip/rars:

CSR_ADRESSFORALL.zip
NEO_BRASILIA.zip
NEO_COELBA.zip
NPE_ADRESSFORALL.rar

Diagnóstico

Por arquivo, cada um testado num workspace separado. Versão do QGIS: 3.32.3-Lima.

CSR_ADRESSFORALL.zip

Ref. a pk0149.01
Jurisdição BR-RN
1,3 milhões de pontos de endereço.
Posição correta.
SRID: EPSG:4326 (GCS_WGS_1984) - indicado pelo arquivo prj.
Resultado: OK

NEO_BRASILIA.zip

Sem pacote publicado (ver Resultado)
Jurisdição BR-DF (suposto)
1,1 milhões de pontos pelo contador, mas a tabela de atributos está vazia.
Não renderiza no QGIS.
SRID: EPSG:4674 (GCS_SIRGAS_2000) - indicado pelo arquivo prj.
Resultado: Com problema. Solicitar reenvio corrigido.

NEO_COELBA.zip

Ref. a pk0150.01
Jurisdição BR-BA
6,1 milhões de pontos de endereço.
Posição errada. Está caindo no Sudão, provavelmente as coordenadas lat/lon estão trocadas.
SRID: EPSG:4674 (GCS_SIRGAS_2000) - indicado pelo arquivo prj.
Resultado: Com problema. Solicitar reenvio corrigido.

NPE_ADRESSFORALL.rar

Ref. a pk0148.01
Jurisdição BR-PE (note que inclui o distrito estadual de Fernando de Noronha)
1,7 milhões de pontos de endereço. Porém há 1 ponto que está caindo perto da África.
Posição correta.
SRID: EPSG:4326 (GCS_WGS_1984) - indicado pelo arquivo prj.
Resultado: OK, com ressalva

Terminado.

ppKrauss commented 10 months ago

Espero que sejam os mesmos que estão sendo discutidos nesta issue

@IgorEliezer o make_conf é a peça fundamental, e ele é traduzido por robô para o Readme: ninguém na AddressForAll pode ter dúvida, só vale o que está no make_conf: no pior caso, se foi alterado depois do README, pedir para o Carlos gerar novo README a partir do make_conf.

IgorEliezer commented 10 months ago

Por orientação de @ppKrauss: @crebollobr e/ou @0e1 é possível gerar o README do pacote 147.1? O make_conf.yaml já existe. Eu quero depois comparar o resultado com o que descrevi acima, para confirmar que os erros dos arquivos que achei não passaram para o csv final.

0e1 commented 10 months ago

Por orientação de @ppKrauss: @crebollobr e/ou @0e1 é possível gerar o README do pacote 147.1? O make_conf.yaml já existe. Eu quero depois comparar o resultado com o que descrevi acima, para confirmar que os erros dos arquivos que achei não passaram para o csv final.

O readme não trará informação nova que já não conste no make_conf (todavia, gerei os readme).

Se existe dúvida, verificar se estamos falando dos mesmos arquivos via comparação de sha256.

Passos:

Gerar sha256 para os 4 arquivos da Neoenergia que estão no armazenamento de @ThierryAJean (item 6 do Guia_do_sha256)
Comparar o shas256 do item 1. com o sha256 dos pacotes _pk0147.01, _pk0148.01, _pk0149.01, _pk0150.01. As jurisdições dos pacotes foram especificas em donatedPack.

Os quatro arquivos citados nos make_conf dos quatro pacotes podem ser obtidos pelos links eternos https://dl.digital-guard.org/{sha256}. Esse trabalho foi feito pelo Luis.

IgorEliezer commented 10 months ago

Obrigado,

@crebollobr e @0e1, consegui determinar o SRID do _pk0147.01: EPSG:31982 (SIRGAS 2000 / UTM 22S)

Ref. a pk0147.01
Jurisdição: BR-MS(parcial),SP
2,85 milhões de pontos de endereço.
SRID: EPSG:31982 (SIRGAS 2000 / UTM 22S - descoberto.
Posição correta.
Resultado: OK

Como os dados deste pacote não são tão óbvios de se carregar no QGIS, deixo um guia que pode ser útil:

crebollobr commented 10 months ago

https://github.com/digital-guard/preserv-BR/tree/main/data/PE/_pk0148.01#-geoaddress

não é geoaddress, nem poste e não parece ser medidor de energia.

crebollobr commented 10 months ago

https://github.com/digital-guard/preserv-BR/blob/main/data/RN/_pk0149.01/qgis.png

não parece poste e nem geoaddress

crebollobr commented 10 months ago

Não parece geoaddress e nem postes https://github.com/digital-guard/preserv-BR/blob/main/data/BA/_pk0150.01/make_conf.yaml

crebollobr commented 10 months ago

Não parece poste e nem geoaddress

https://github.com/digital-guard/preserv-BR/tree/main/data/_pk0147.01

IgorEliezer commented 10 months ago

Na realidade são geoaddress, mas tudo fora do lugar. Acho que os pontos foram coletados com GPS de celular.

A solução seria mover os pontos pra a frente do lote, mas para qual?

Para mim, na forma que estão, este pontos são só úteis na área rural.

ppKrauss commented 10 months ago

Esse tipo de "nuvem de pontos" de GPS se presta apenas a estatística... Precisamos avaliar a precisão média dos GPS utilizados (celular aleatório ou instrumento padrão da empresa?) e fixar confiabilidade de um endereço em função da proximidade com GPS... Seria um verificação do tipo: "se o ponto oficial a menos de 100 metros do GPS então tem confiabilidade minima".

IgorEliezer commented 10 months ago

@crebollobr @0e1: O que, de fato, temos no servidor sobre a NeoEnergia? Por favor, me lista os pacotes da que já estão no servidor. Acho que temos outros da NeoEnergia no drive de Thierry que não foram enviados para ingestão. Preciso comparar. Temos cerca de 10 milhões de pontos no total da NeoEnergia .

0e1 commented 10 months ago

@crebollobr @0e1: O que, de fato, temos no servidor sobre a NeoEnergia? Por favor, me lista os pacotes da que já estão no servidor. Acho que temos outros da NeoEnergia no drive de Thierry que não foram enviados para ingestão. Preciso comparar. Temos cerca de 10 milhões de pontos no total da NeoEnergia .

Esses são os pacotes referentes a NeoEnergia:

0e1 commented 10 months ago

Obrigado,

@crebollobr e @0e1, consegui determinar o SRID do _pk0147.01: EPSG:31982 (SIRGAS 2000 / UTM 22S)

Como os dados deste pacote não são tão óbvios de se carregar no QGIS, deixo um guia que pode ser útil:

Segui a orientação e atualizei o make_conf em https://github.com/digital-guard/preserv-BR/commit/c0583f0991301c818d8bdadd6138abc6e58f0e55.

Mas, surgiu um problema.

O arquivo listado é um csv conforme make_conf:

files:
- file: 07cf6cbb22f6b48f0d2331f124ac34b37fc7db53508565fb1ca576f14eb1156b.csv
  name:
  p: 1

Até o momento, são suportados apenas arquivos em formatos compactados nessa lista.

@ppKrauss @crebollobr Minha sugestão para esse é atualizar a lista usando um arquivo em formato compactado.

IgorEliezer commented 10 months ago

O post a seguir é meramente informativo.

Estado do material da NeoEnergia

pk0147.01: Pontos de consumidores do estado de São Paulo e Mato Grosso do Sul (leste) | 2,85 milhões | com link.
pk0148.01: Pontos de consumidores do estado de Pernambuco | 1,7 milhões | sem link.
pk0149.01: Pontos de consumidores do estado de Rio Grande do Norte | 1,3 milhões | sem link.
pk0150.01: Pontos de consumidores do estado da Bahia | 6,1 milhões | sem link.
Sem pacote: Pontos de consumidores do Distrito Federal | 1,1 milhões | arquivo veio corrompido - já pedi para reenviar.

Total de pontos de endereço em potencial: 13,05 milhões.

"Sem link" ou "com link" indica se o pacote está com link em https://addressforall.org/en/downloads/.

0e1 commented 9 months ago

Obrigado, @crebollobr e @0e1, consegui determinar o SRID do _pk0147.01: EPSG:31982 (SIRGAS 2000 / UTM 22S) Como os dados deste pacote não são tão óbvios de se carregar no QGIS, deixo um guia que pode ser útil:

Segui a orientação e atualizei o make_conf em c0583f0.

Mas, surgiu um problema.

O arquivo listado é um csv conforme make_conf:
files:
- file: 07cf6cbb22f6b48f0d2331f124ac34b37fc7db53508565fb1ca576f14eb1156b.csv
  name:
  p: 1
Até o momento, são suportados apenas arquivos em formatos compactados nessa lista.

@ppKrauss @crebollobr Minha sugestão para esse é atualizar a lista usando um arquivo em formato compactado.

Conforme reunião:

Em casos que o arquivo original doado não for compactado:

compactar (em zip, preferencialmente), informar o hash do arquivo compactado ao doador (repondendo email)
preservar o arquivo compactado
usar hash do arquivo compactado no make_conf

IgorEliezer commented 9 months ago

Em casos que o arquivo original doado não for compactado:

Sobre isso, existe página na wiki documentando estes procedimentos de ingestão?

EDIT: isso não iria aqui? https://wiki.addressforall.org/doc/dg:Workflow

0e1 commented 9 months ago

Em casos que o arquivo original doado não for compactado:

Sobre isso, existe página na wiki documentando estes procedimentos de ingestão?

EDIT: isso não iria aqui? https://wiki.addressforall.org/doc/dg:Workflow

Não existe. Primeira vez que surgiu um caso assim. Entendimento foi dado na reunião de hoje. Sim, faz parte do flow. Cabe na fase de pré-ingestão.

IgorEliezer commented 9 months ago

Cabe na fase de pré-ingestão.

Documentado: https://wiki.addressforall.org/doc/dg:Workflow#Arquivos_n%C3%A3o_compactados

IgorEliezer commented 9 months ago

Sem pacote: Pontos de consumidores do Distrito Federal | 1,1 milhões | arquivo veio corrompido - já pedi para reenviar.

Chegou pacote novo de dados de Distrito Federal. Foi aprovado e enviado para ingestão.

Ver issue #183.

digital-guard / preserv-BR

Dados da Neoenergia #149

O que temos

Diagnóstico

CSR_ADRESSFORALL.zip

NEO_BRASILIA.zip

NEO_COELBA.zip

NPE_ADRESSFORALL.rar