Download de arquivos MX-INEGI

IgorEliezer commented 1 year ago

Sobre o material do INEGI, México (deu um trabalho para analizar) https://www.inegi.org.mx/app/mapas/#Busqueda_avanzada.

Tenho uma boa e uma má notícia:

A boa: o INEGI tem uma base de dados contendo pontos de endereços já geoposicionados na face de quadra, ruas, quadras, bairros, área urbana, POIs. Cobertura nacional dos 2400 municípios, somente área urbana (ver Observação).

A má: são 3480 arquivos zip. Normalmente há 2 zips para cada município: um zip da cidade (sede municipal, classificado como núcleo urbano), e um zip das vilas (sedes distritais, classificado como núcleos rurais). O zip urbano contém sempre 1 shp de endereços e vários shp de outras coisas (quadra, bairro etc.). O zip dos rural contém um jogo de arquivos shps para cada vila. Então o total de arquivos shapefiles pode passar dos 10.000. Mesmo assim temos a base de endereços urbanos de um país inteiro.

Observação: no México, os núcleos são classificados em núcleos urbanos e núcleos rurais, e assim também estão os arquivos. Os núcleos urbanos seriam as cidades; e núcleos rurais seriam as vilas (sedes de distritos subordinado à cidade). Isso para nós no Brasil seria tudo urbano. Não há nos arquivos pontos de endereços das áreas rurais (i.e. fora dos núcleos urbanos e núcleos rurais).

Está bem simples, dá para concatenar a string do link com o nome de estado e código na coluna URL do CSV. Abaixo está o arquivo CSV da listagem de zips (sem mostrar o que cada um contém internamente).

Mapas_2023719_214631165.csv

Nas outras colunas há dados que podem servir para popular os metadados de cada arquivo.

Prova de teste

0e1 commented 1 year ago

Comando para tratar o csv inicial:

grep -E -i '^[0-9]+' Mapas_2023719_214631165.csv | awk -F"[\.,]"  '{print $1","$3","$12}' | sed 's/, /,/g;s/Urbanas/urbana/;s/Rurales/rural/;s/ /_/g' > data.csv

Script para fazer o download

#! /bin/bash
while IFS="," read -r c1 c2 c3
do
  wget https://www.inegi.org.mx/contenidos/productos/prod_serv/contenidos/espanol/bvinegi/productos/geografia/${c2}/SHP_2/${c3}/${c1}_s.zip
done < data.csv

Download dos dados sendo realizado.

Próximo passo (após download): avaliar e manipular os arquivos para facilitar a ingestão.

crebollobr commented 1 year ago

Onde estão os downloads? Você vai fazer a ingestão deles?

IgorEliezer commented 1 year ago

@0e1

Próximo passo (após download): avaliar e manipular os arquivos para facilitar a ingestão.

Precisará duas avaliações: 1) por amostragem para ver se os dados carregam (no QGIS?); 2) constatar a cobertura territorial de todos os pontos de endereços carregados e para saber o total final de pontos.

Seria possível obter um link para puxar os dados do servidor para carregar no QGIS localmente?

0e1 commented 1 year ago

Onde estão os downloads? Você vai fazer a ingestão deles?

@crebollobr

Os arquivos estão em /home/claiton/inegi/arquivos.

Não vou fazer a ingestão ou avaliar os dados.

Meu papel é:

Manipular csv para servir de entrada para script de download (já concluído);
Fazer o download dos dados (já concluído);
Entender/reorganizar/renomear os arquivos de forma que a ingestão seja igual a outro caso (por exemplo parcel de São Paulo).

A ingestão propriamente dita e a avaliação dos dados ficam a cargo de vocês. Então:

Avaliem os dados, conforme comentado por @IgorEliezer
Se a avaliação for positiva vocês devem fazer o rascunho do _makeconf deixando em aberto o que for relacionado ao sha256 do arquivo, aguardando eu fornecer o arquivo manipulado.

Exemplo de como são constituídos os arquivos:

unzip -l 702825298340_s.zip
Archive:  702825298340_s.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
  5155154  2011-02-15 12:01   070890001.zip
   236158  2011-02-15 12:02   070890046.zip
   105380  2011-02-15 12:02   070890057.zip
   323174  2011-02-15 12:02   070890148.zip
   409524  2011-05-12 13:09   FICHA TРCNICA LOC  AMANZANADAS Y NUM  EXT (28feb2011).pdf
---------                     -------
  6229390                     5 files

Seria possível obter um link para puxar os dados do servidor para carregar no QGIS localmente?

@IgorEliezer

É possível. A lista com links para download de todos os arquivos está em inegi_serv_links.csv.

0e1 commented 1 year ago

Precisará duas avaliações: 1) por amostragem para ver se os dados carregam (no QGIS?); 2) constatar a cobertura territorial de todos os pontos de endereços carregados e para saber o total final de pontos.

Seria possível obter um link para puxar os dados do servidor para carregar no QGIS localmente?

Conforme reunião, a avaliação será feita após a ingestão preliminar.

Vou proceder com a reorganização dos arquivos para viabilizar a ingestão. Em paralelo vou trabalhar em https://github.com/digital-guard/preserv/issues/139.

IgorEliezer commented 1 year ago

Conforme reunião, a avaliação será feita após a ingestão preliminar.

Então quando for feita a ingestão preliminar, dê um @ para eu ficar sabendo.

0e1 commented 1 year ago

@IgorEliezer

Pacote de dados do INEGI disponível em https://github.com/digital-guard/preserv-MX/tree/main/data/_pk0002.01.

Separei os dados em 9 conjuntos. Um para cada tipo de dado;
Escrevi o make_conf inicial. Listei todos os campos disponíveis na chave sql_select;
Gerei o README.md inicial;
Ingestão dos layer está funcionando;
Preenchi o necessário em donor.csv e donatePack.csv.

O que ainda falta:

Verificar/confirmar o srid dos dados;
Verificar o codec dos dados;
Verificar o subtype de cada layer. Inicialmente, todos estão com subtype: full;
Verificar quais campos possuem equivalente no formato padronizado (exemplo disponível no layer nsvia);
Verificar a licença dos dados.

Sobre o SRID

A projeção dos dados retornada pelo ogrinfo foi a seguinte (usei 1 arquivo como exemplo):

ogrinfo -so -al 300320001a.shp
INFO: Open of `300320001a.shp' using driver `ESRI Shapefile' successful.

Layer name: 300320001a
Metadata: DBF_DATE_LAST_UPDATE=2011-01-26
Geometry: Polygon
Feature Count: 24
Extent: (3224673.930001, 731095.289989) - (3227814.950535, 733555.211861)
Layer SRS WKT:
PROJCRS["ccl_itrf92",
    BASEGEOGCRS["ITRF_1992",
        DATUM["International Terrestrial Reference Frame 1992",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]],
            ID["EPSG",6651]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["Degree",0.0174532925199433]]],
    CONVERSION["unnamed",
        METHOD["Lambert Conic Conformal (2SP)",
            ID["EPSG",9802]],
        PARAMETER["Latitude of false origin",12,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8821]],
        PARAMETER["Longitude of false origin",-102,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8822]],
        PARAMETER["Latitude of 1st standard parallel",17.5,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8823]],
        PARAMETER["Latitude of 2nd standard parallel",29.5,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8824]],
        PARAMETER["Easting at false origin",2500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8826]],
        PARAMETER["Northing at false origin",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8827]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]]

A projeção que consta no arquivo prj é:

PROJCS["ccl_itrf92",GEOGCS["ITRF_1992",DATUM["D_ITRF_1992",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",2500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-102.0],PARAMETER["Standard_Parallel_1",17.5],PARAMETER["Standard_Parallel_2",29.5],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",12.0],UNIT["Meter",1.0]]

IgorEliezer commented 1 year ago

Check-list.

O que ainda falta:

[x] 1 - Verificar/confirmar o srid dos dados;

[x] 2 - Verificar o codec dos dados;

[x] 3 - Verificar o subtype de cada layer. Inicialmente, todos estão com subtype: full;

[x] 4 - Verificar quais campos possuem equivalente no formato padronizado (exemplo disponível no layer nsvia);

[ ] 5 - Verificar a licença dos dados.

Respondo abaixo:

1- Verificar/confirmar o srid dos dados

No arquivo PRJ e no PDF Ficha Técnica que veio em alguns zips, está CCL ITRF92, que me parece equivalente ao EPSG:6362. Fiz um teste no QGIS, não houve qualquer alteração da posição. Adotaria 6362 como código de referência para ccl_itrf92.

2- Verificar o codec dos dados:

Um o set completo de arquivos shapefiles deveria conter um arquivo cpg para cada arquivo shp. Como o arquivo cpg é optional para abrir no QGIS, ele costuma não vir, que é o caso do México. Na falta dele, QGIS usa a codificação padrão do sistema, que aqui é Windows-1252, como mostra a janela "Propriedades da Camada" no QGIS. Mudei manualmente para UTF-8, e parou de reconhecer os acentos.

3 - Verificar o subtype de cada layer. Inicialmente, todos estão com subtype: full;

Dei uma olhada aqui https://github.com/digital-guard/preserv-MX/tree/main/data/_pk0002.01. Estão corretos.

4 - Verificar quais campos possuem equivalente no formato padronizado (exemplo disponível no layer nsvia);

(falta responder)

5 - Verificar a licença dos dados.

Já encaminhei para solicitarem do doador.

@0e1 uma pergunta: quando você baixou os zips do site, vieram com um arquivo PDF?

0e1 commented 1 year ago

@0e1 uma pergunta: quando você baixou os zips do site, vieram com um arquivo PDF?

Sim. Ver exemplo: https://www.inegi.org.mx/contenidos/productos/prod_serv/contenidos/espanol/bvinegi/productos/geografia/rural/SHP_2/Coahuila_de_Zaragoza/702825272463_s.zip

IgorEliezer commented 1 year ago

Campos relevantes.

geoaddress:

CVEGEO (string): clave de estadística INEGI para la dirección.
NOMASEN (string): nombre del asentamiento.
NOMVIAL (string): nombre de la vía en mayúsculas, con acentuación y abreviaturas. Sin nombre es representado como "NINGUNO".
NUMEXT (string): número de dirección externo. Sin número es representado como "SN".
TIPOASEN (string): tipo del asentamiento (barrio, colonia etc.).
TIPOVIAL (string): tipo vial.

block:

CVEGEO (string): clave de estadística INEGI para la manzana.

nsvia:

CVEASEN (string): clave de estadística INEGI para el asentamiento.
NOMASEN (string): nombre del asentamiento.
TIPOASEN (string): tipo del asentamiento (barrio, colonia etc.).

via:

NOMVIAL (string): nombre de la vía en mayúsculas, con acentuación y abreviaturas. Sin nombre es representado como "NINGUNO".
TIPOVIAL (string): tipo vial.

Terminado. Se precisar de algo, dê um @.

0e1 commented 1 year ago

@IgorEliezer

Traduzi sua listagem para o make_conf usando como referencia os campos padrão (ver https://docs.google.com/spreadsheets/d/13Rxw7ry9bU2tpg1jUaeoGXWP5Vn2wr0Uw3AGo6zyMsg/edit#gid=644252560. Conteúdo dessa tabela pode ir para a wiki!).

Dúvidas adicionais:

TIPOVIAL + espaço + NOMVIAL formam o nome completo da via?
SENTIDO, presente em shapefile de vias pode ser entendido como o campo padrão oneway? Por exemplo, se sentido=un sentido então oneway=yes, caso contrário oneway=null;

@IgorEliezer @ppKrauss

Como lidar com situações onde NOMVIAL=NINGUNO e TIPOVIAL=(por exemplo)CALLE:
- via=CALLE NINGUNO
- via=CALLE
- via=null
?

IgorEliezer commented 1 year ago

TIPOVIAL + espaço + NOMVIAL formam o nome completo da via?

Sim.

SENTIDO, presente em shapefile de vias pode ser entendido como o campo padrão oneway? Por exemplo, se sentido=un sentido então oneway=yes, caso contrário oneway=null;

Quase certo. oneway=no é a tag para confirmar que via não é mão-única. E na ausência de oneway=*, presume-se que a via é oneway=no.

Mas isso é necessário para o projeto? Só uma curiosidade.

Como lidar com situações onde NOMVIAL=NINGUNO e TIPOVIAL=(por exemplo)CALLE:

Parece que são caso de vias sem nome. Aí para não deixarem NULL colocaram como nome "Nenhum".

Também há casos de TIPOVIAL = OTROS e TIPOVIAL = PRIVADA.

Como trataria um CALLE NINGUNO? Talvez colocaria entre parênteses para indicar que não é exatamente um nome oficial: "(CALLE SIN NOMBRE)". Ou deixa em branco (NULL) já que se trata de via sem nome mesmo.

E há casos raros de TIPOVIAL=OTROS + NOMVIAL={um nome real aqui}, exemplo: "OTRO CARMEN SERDÁN". Aqui não sei o que faria. Não achei nada nos PDFs do INEGI.

0e1 commented 1 year ago

Quase certo. oneway=no é a tag para confirmar que via não é mão-única. E na ausência de oneway=*, presume-se que a via é oneway=no.

No caso, oneway=null é no contexto do banco de dados. Na verdade, só apareceria a chave oneway quando pudermos determinar se realmente é sentido único. Se não der, ela não aparecerá. E aí o usuário usa a convensão do OSM (se não for =yes então é mão dupla) ou trata como incerto.

Mas isso é necessário para o projeto? Só uma curiosidade.

Lembra que você e Luis elegeram várias campos do OSM (listados na planilha)? Eu entendi a listagem que fizeram como uma extensão dos campos padrão existentes. Aí, se o dado original tem a informação e nós temos uma etiqueta para ele, não vejo motivo pra não etiquetar. Talvez para o projeto não seja, diretamente. Mas para a comunidade OSM, sentido de rua é uma informação muito interessante.

0e1 commented 1 year ago

Como lidar com situações onde NOMVIAL=NINGUNO e TIPOVIAL=(por exemplo)CALLE:

Sem estatística não inferir que ninguno é igual a null . Assim, até ser possível gerar estatística, deixar como está.

0e1 commented 1 year ago

Ingestão de dados realizada, tendo como base o make_conf.yaml.

Curiosidades: foram necessários cerca de 65GB de espaço livre para aplicar a função _anyload nos layer geoaddress.

Próxima etapa: publicação.

IgorEliezer commented 1 year ago

Vi que México está no downloads do site.

E conversando agora com @ThierryAJean, perguntamos se é possível gerar umas estatísticas do material do MX: número de objetos por data type, número de objetos e pontos com endereços.

0e1 commented 1 year ago

Vi que México está no downloads do site.

Cuidado. https://addressforall.org/downloads lista arquivos preservados e filtrados. Se um pacote está nessa lista tem arquivo preservado listado. Mas, pode não ter arquivo filtrado listado.

No caso dos dados no INEGI, estão listados apenas os dados preservados. Ou seja, os dados que fizemos o download e reagrupamos em 9 tipos.

Não estão listados os dados filtrados. Filtrado é quando o pacote de dados é ingerido e publicado no preservCutGeo do país.

INEGI está sendo publicado. E dificuldades na publicação precisam ser contornadas.

E conversando agora com @ThierryAJean, perguntamos se é possível gerar umas estatísticas do material do MX: número de objetos por data type, número de objetos e pontos com endereços.

Sim, é possível. Após a ingestão já temos estatísticas.

Seguem a quantidade de elementos ingeridos:

block: 869718
via: 52138
geoaddress: 14615100
nsvia: 24323

0e1 commented 1 year ago

Atualização:

Publicados no preservCutGeo-MX2021 os layers: geoaddress, block, nsvia e via

0e1 commented 12 months ago

Considero concluída publicação.

Links:

Links canônicos para vizualização: https://viz.addressforall.org/MX/_pk0002.01/nsvia https://viz.addressforall.org/MX/_pk0002.01/block https://viz.addressforall.org/MX/_pk0002.01/geoaddress https://viz.addressforall.org/MX/_pk0002.01/via

IgorEliezer commented 11 months ago

Considero concluída publicação.

@ThierryAJean para o INEGI.

0e1 commented 11 months ago

Falta ainda ajustar a licença, conforme @ThierryAJean falou na reunião.

digital-guard / preserv

Download de arquivos MX-INEGI #138

Prova de teste