Uma maneira rápida de carregar o Arquivo de Endereço Nacional Geocodificado da Austrália (GNAF) completo e os Limites Administrativos Australianos no Postgres, simplificado e pronto para uso como dados de referência para geocodificação, análise, visualização e agregação.
Dê uma olhada nestes slides de introdução (PDF), bem como na página data.gov.au.
Execute o script Python load-gnaf e crie você mesmo o banco de dados em uma única etapa
Extraia o banco de dados do Docker Hub e execute-o em um contêiner
Baixe os arquivos de despejo GNAF e/ou Admin Bdys Postgres e restaure-os em seu banco de dados Postgres 14+
Use ou baixe arquivos Geoparquet e Parquet no S3 para seus fluxos de trabalho de dados e análises; seja na AWS ou em sua própria plataforma.
A execução do script Python leva de 30 a 120 minutos em um servidor Postgres configurado para aproveitar a RAM disponível.
Você pode processar a versão GDA94 ou GDA2020 dos dados - apenas certifique-se de baixar a mesma versão para o GNAF e para os Limites Administrativos. Se você não sabe o que é GDA94 ou GDA2020, baixe as versões GDA94 (para sua informação - são sistemas de coordenadas diferentes)
Para obter um bom tempo de carregamento, você precisará configurar seu servidor Postgres para desempenho. Há um bom guia aqui, observando que ele tem alguns anos e alguns dos parâmetros de memória podem ser aprimorados se você tiver RAM.
Postgres 14.x e superior com PostGIS 3.2+
Adicione o diretório bin do Postgres ao PATH do seu sistema
Python 3.6+ com Psycopg 3.x
Baixe Geoscape GNAF em data.gov.au (GDA94 ou GDA2020)
Baixe os limites administrativos do Geoscape em data.gov.au ( baixe a versão ESRI Shapefile (GDA94 ou GDA2020) )
Descompacte o GNAF em um diretório no seu servidor Postgres
Descompacte Admin Bdys para um diretório local
Altere a segurança nesses diretórios para conceder acesso de leitura ao Postgres
Crie o banco de dados de destino (se necessário)
Adicione PostGIS ao banco de dados (se necessário) executando o seguinte SQL: CREATE EXTENSION postgis
Verifique os argumentos disponíveis e necessários executando load-gnaf.py com o argumento -h (veja os exemplos de linha de comando abaixo)
Execute o script, volte em 30-120 minutos e divirta-se!
O comportamento do gnaf-loader pode ser controlado especificando várias opções de linha de comando para o script. Os argumentos suportados são:
--gnaf-tables-path especifica o caminho para os arquivos GNAF PSV extraídos. Este diretório deve ser acessível pelo servidor Postgres , e o caminho local correspondente do servidor para este diretório pode precisar ser definido por meio do argumento local-server-dir
--local-server-dir especifica o caminho local no servidor Postgres correspondente a gnaf-tables-path . Se o servidor estiver rodando localmente, este argumento poderá ser omitido.
--admin-bdys-path especifica o caminho para os arquivos de limite administrativo do Shapefile extraídos. Ao contrário de gnaf-tables-path , este caminho não precisa necessariamente estar acessível ao servidor Postgres remoto.
--pghost o nome do host do servidor Postgres. O padrão é a variável de ambiente PGHOST se definida, caso contrário, o padrão é localhost .
--pgport o número da porta do servidor Postgres. O padrão é a variável de ambiente PGPORT se definida, caso contrário, 5432 .
--pgdb o nome do banco de dados do servidor Postgres. O padrão é a variável de ambiente PGDATABASE se definida, caso contrário, geoscape .
--pguser o nome de usuário para acessar o servidor Postgres. O padrão é a variável de ambiente PGUSER se definida, caso contrário, postgres .
--pgpassword senha para acessar o servidor Postgres. O padrão é a variável de ambiente PGPASSWORD se definida, caso contrário, password .
--srid Define o sistema de coordenadas dos dados de entrada. Os valores válidos são 4283 (o padrão: lat/long GDA94) e 7844 (lat/long GDA2020).
--geoscape-version Número da versão do Geoscape no formato AAAAMM. O padrão é o ano atual e o último mês de lançamento. por exemplo, 202408 .
--previous-geoscape-version Número da versão anterior do lançamento do Geoscape como AAAAMM; usado para comparação de controle de qualidade. por exemplo, 202405 .
--raw-gnaf-schema nome do esquema para armazenar tabelas GNAF brutas. O padrão é raw_gnaf_ .
--raw-admin-schema nome do esquema para armazenar tabelas de limites administrativos brutos. O padrão é raw_admin_bdys_ .
--gnaf-schema nome do esquema de destino para armazenar tabelas GNAF finais. O padrão é gnaf_ .
--admin-schema nome do esquema de destino para armazenar tabelas finais de limites administrativos. O padrão é admin_bdys_ .
--previous-gnaf-schema Esquema com a versão anterior das tabelas GNAF. O padrão é gnaf_ .
--previous-admin-schema Esquema com a versão anterior das tabelas de limites administrativos. O padrão é admin_bdys_ .
--states lista de estados separados por espaço para carregar, por exemplo --states VIC TAS . O padrão é carregar todos os estados.
--prevacuum força a limpeza do banco de dados após a eliminação das tabelas. O padrão é desativado e especificar esta opção retardará o processo de importação.
--raw-fk cria chaves primárias e estrangeiras para as tabelas GNAF brutas. O padrão é desativado e retardará o processo de importação, se especificado. Utilize esta opção se pretende utilizar as tabelas GNAF brutas como algo mais do que uma etapa de importação temporária. Observe que as tabelas finais processadas sempre terão chaves primárias e estrangeiras apropriadas definidas.
--raw-unlogged cria tabelas GNAF brutas não registradas, acelerando a importação. O padrão é desativado. Especifique esta opção apenas se você não se importar com as tabelas de dados brutos após a importação - elas serão perdidas se o servidor travar!
--max-processes especifica o número máximo de processos paralelos a serem usados para o carregamento de dados. Defina isso para o número de núcleos no servidor Postgres menos 2, mas limite para 12 se tiver mais de 16 núcleos - há benefício mínimo além de 12. O padrão é 4.
--no-boundary-tag NÃO marque todos os endereços com alguns dos principais IDs de limite de administrador para criar agregados e mapas coropléticos.
Servidor Postgres local: python load-gnaf.py --gnaf-tables-path="C:tempgeoscape_202408G-NAF" --admin-bdys-path="C:tempgeoscape_202408Administrative Boundaries" Carrega as tabelas GNAF em um servidor Postgres em execução localmente. Os arquivos GNAF foram extraídos para a pasta C:tempgeoscape_202408G-NAF e os limites administrativos foram extraídos para a pasta C:tempgeoscape_202408Administrative Boundaries .
Servidor Postgres remoto: python load-gnaf.py --gnaf-tables-path="svrsharedgnaf" --local-server-dir="f:sharedgnaf" --admin-bdys-path="c:tempunzippedAdminBounds_ESRI" Carrega o Tabelas GNAF que foram extraídas para a pasta compartilhada svrsharedgnaf . Esta pasta compartilhada corresponde à pasta local f:sharedgnaf no servidor Postgres. Os limites administrativos foram extraídos para a pasta c:tempunzippedAdminBounds_ESRI .
Carregando apenas os estados selecionados: python load-gnaf.py --states VIC TAS NT ... Carrega apenas os dados de Victoria, Tasmânia e Território do Norte
Você pode carregar os limites administrativos sem GNAF. Para fazer isso: comente as etapas 1, 3 e 4 em def main.
Nota: você não pode carregar o GNAF sem o Admin Bdys devido às dependências necessárias para dividir Melbourne e para corrigir locality_pids fora dos limites nos endereços.
Ao usar os dados resultantes deste processo - você precisará cumprir os requisitos de atribuição nas páginas data.gov.au para GNAF e Admin Bdys, como parte dos requisitos de licenciamento de dados abertos.
Os scripts irão DROP ALL TABLES usando CASCADE nos esquemas GNAF e Admin Bdy e então os recriarão; o que significa que você PERDERÁ SUAS VISUALIZAÇÕES se tiver criado alguma! Se quiser manter os dados existentes - você precisará alterar os nomes dos esquemas no script ou usar um banco de dados diferente
Todas as tabelas GNAF brutas podem ser criadas UNLOGGED para acelerar o carregamento de dados. Isso os tornará irrecuperáveis se seu banco de dados estiver corrompido. Você pode executar esses scripts novamente para recriá-los. Se você acha que isso parece bom - defina o sinalizador unlogged_tables como True para um carregamento um pouco mais rápido
A marcação de limite (ativada por padrão) adicionará de 15 a 60 minutos ao processo se você tiver PostGIS 2.2+. Se você tiver PostGIS 2.1 ou inferior - pode levar HORAS porque as tabelas de limites não podem ser otimizadas!
Embora você possa escolher em quais quatro esquemas carregar os dados, não fiz controle de qualidade de todas as permutações. Fique com os padrões se você tiver experiência limitada com Postgres
Se não estiver executando o script Python no servidor Postgres, você precisará ter acesso a um caminho de rede para os arquivos GNAF no servidor de banco de dados (para criar a lista de arquivos a serem processados). A alternativa é ter uma cópia local dos arquivos brutos
O script sql 'criar tabelas' adicionará a extensão PostGIS ao banco de dados no esquema público, você não precisa adicioná-lo ao seu banco de dados
Existe uma opção para VACUUM o banco de dados no início, após eliminar as tabelas GNAF/Admin Bdy existentes - isso realmente não faz nada além de testes repetidos. (Tive preguiça de tirar isso do código, pois isso significava renumerar todos os arquivos SQL e gostaria de ir para a cama agora)
O GNAF e os limites administrativos estão prontos para uso no Postgres em uma imagem no Docker Hub.
Em seu ambiente docker, extraia a imagem usando docker pull minus34/gnafloader:latest
Execute usando docker run --publish=5433:5432 minus34/gnafloader:latest
Acesse o Postgres no contêiner pela porta 5433 . O login padrão é - usuário: postgres , senha: password
Nota: a imagem compactada do Docker tem 8 Gb, a descompactada tem 25 Gb
AVISO: A senha padrão de superusuário do postgres é insegura e deve ser alterada usando:
ALTER USER postgres PASSWORD '
Baixe os arquivos de despejo do Postgres e restaure-os em seu banco de dados.
Deve levar de 15 a 60 minutos.
Postgres 14+ com PostGIS 3.0+
Conhecimento dos parâmetros pg_restore do Postgres
Baixe o arquivo de despejo GNAF ou o arquivo de despejo GNAF GDA2020 (~2,0 Gb)
Baixe o arquivo de despejo Admin Bdys ou o arquivo de despejo Admin Bdys GDA2020 (~ 2,8 Gb)
Edite o script restore-gnaf-admin-bdys.bat ou .sh na pasta de arquivos de suporte para os nomes dos arquivos de despejo, parâmetros do banco de dados e para a localização do pg_restore
Execute o script, volte em 15 a 60 minutos e divirta-se!
As versões Geoparquet das tabelas espaciais, bem como as versões parquet das tabelas não espaciais, estão em um bucket S3 público para uso direto em um aplicativo ou serviço. Eles também podem ser baixados usando a AWS CLI.
As geometrias têm coordenadas lat/long WGS84 (SRID/EPSG:4326). Um exemplo de consulta para analisar os dados usando Apache Sedona, a extensão espacial do Apache Spark está na pasta spark .
Os arquivos estão aqui: s3://minus34.com/opendata/geoscape-202408/geoparquet/
Liste todos os conjuntos de dados: aws s3 ls s3://minus34.com/opendata/geoscape-202408/geoparquet/
Copie todos os conjuntos de dados: aws s3 sync s3://minus34.com/opendata/geoscape-202408/geoparquet/
Incorpora ou é desenvolvido usando G-NAF © Geoscape Australia licenciado pela Commonwealth of Australia sob o Contrato de Licença de Usuário Final do Open Geo-coded National Address File (G-NAF).
Incorpora ou é desenvolvido usando Limites Administrativos © Geoscape Australia licenciado pela Commonwealth of Australia sob licença Creative Commons Attribution 4.0 International (CC BY 4.0).
O GNAF e o Admin Bdys foram personalizados para remover algumas das pequenas limitações conhecidas dos dados. Os mais notáveis são:
Todos os endereços estão vinculados a uma localidade publicada que possui um limite. Esse pequeno número de endereços que não estão no GNAF bruto tiveram seu locality_pid alterado para um equivalente publicado no jornal
As localidades tiveram contagens de endereços e ruas adicionadas a elas
Bdys de subúrbio-localidade foram achatados em uma única camada contínua de localidades - Centenas da Austrália do Sul foram removidas e distritos ACT foram adicionados onde não há localidades publicadas
A localidade de Melbourne, VIC foi dividida em localidades de Melbourne, 3000 e Melbourne 3004 (os novos PIDs de localidade são loc9901d119afda_1 e loc9901d119afda_2 ). A divisão ocorre no rio Yarra (com base nos códigos postais dos endereços de Melbourne)
Uma camada de limites de códigos postais foi criada usando os códigos postais nas tabelas de endereços. Embora isso emule de perto os limites oficiais do código postal do Geoscape, existem várias centenas de endereços que estão no código postal errado. Não trate esses dados como oficiais
