Python |

Struggling to Download Sentinel-2 Level 1C `.SAFE` Files with Python and AWS CLI

Mon, 22 Sep 2025 00:00:00 +0000

TL;DR

I initially struggled to download the full Sentinel-2 Level 1C .SAFE package (with metadata) for ACOLITE atmospheric correction.
The solution, kindly shared by my friend Luis Sadeck, was to configure S3 access keys directly in my Copernicus Data Space account.
👉 You don’t need an AWS account for this — just generate your access_key and secret_key inside your Data Space profile, then use them when accessing the S3 bucket.
Docs: Copernicus Data Space S3 API
Now the entire process works smoothly with a single Python library. 🎉
Big thanks to everyone who reached out with suggestions and support!

I’ve been trying to download Sentinel-2 Level 1C data programmatically with Python, instead of manually going to the Sentinel Hub website. The goal is to get the entire .SAFE package, including metadata, so I can later run atmospheric correction with ACOLITE.

So far, here’s what I’ve tried:

Attempt 1: Using the sentinelhub Python library

With the sentinelhub Python package, I was able to find the asset I needed. It even provides an href pointing to the AWS S3 bucket for the .SAFE product:

s3://EODATA/Sentinel-2/MSI/L1C_N0500/2023/01/15/S2B_MSIL1C_20230115T133829_N0510_R124_T21HWD_20240728T040848.SAFE/

At first, this looked promising. But when I tried downloading the data with the AWS CLI, I only got the bands and a few additional elements — not the full .SAFE structure.

Unfortunately, that’s a problem: ACOLITE requires all metadata, not just the imagery.

Attempt 2: Using STAC from Copernicus Dataspace

Next, I tried going through the Copernicus Dataspace STAC API.

This was encouraging: it actually lists the full .SAFE structure, and I can see hrefs for each element. So it looked like the full dataset might be accessible.

However, when I attempted to download it using the AWS CLI, I ran into issues. Here’s the command I used:

aws s3 cp --recursive \
 s3://eodata/Sentinel-2/MSI/L1C_N0500/2023/01/15/S2B_MSIL1C_20230115T133829_N0510_R124_T21HWD_20240728T040848.SAFE/GRANULE/L1C_T21HWD_A030609_20230115T135051/IMG_DATA/T21HWD_20230115T133829_B01.jp2 \
 ./S2B_MSIL1C_20230115T133829_N0510_R124_T21HWD_20240728T040848.SAFE/ \
 --request-payer requester

Has anyone successfully managed to download the entire Sentinel-2 Level 1C .SAFE package, including metadata, directly through Python or AWS CLI, in a way that works for running ACOLITE atmospheric correction?

Any hints, scripts, or alternative approaches would be hugely appreciated!

Lessons Learned during the developtmen of `corssfire` Python package

Sat, 30 Mar 2024 00:00:00 +0000

The crossfire package was first developed in 2021, during the #Hacktoberfest. Since this first version I have recieved support from @cuducos. Last year, the crossfire API was updated, and thus the package should be updated as well. Again, I asked for Cuducos’ help, and he kindly accepted to mentor me during the development of the new version of the package. This time, I can see that I have learned a lot of things that I would like to share here, in a not so structured form…. My idea here is to write down some thoughts, notes, and comments about the process of developing the package.

Debuging in test

I already knew about the importance of debugging, althought I never used it. But something that I didn’t know is that I could debug the test, also. This can be done by importing pytest to the source code, and adding pytest.set_trace() before the line that I want to debug. Then, we can run the test with the -k parameter, which will run only the test that I want to debug.

poetry run pytest -k test_client_load_states

The set_trace makes the test stop and leave the terminal so we can call the objects and functions to confirm if they are as expected.

here (in Pt-Br)

TDD is about exploring issues rather than a solution

At some point during the package development, I was facing an issue when trying to set a return value for a mocked function. After a long time analysing my code and not identifying the issue, I found in Stack Over Flow (yes, I still using it :) a suggestion of setting the autospec parameter to True. Of course I looked up at the pytest documentation to [try to] understand what does it do, but all I got was some glue about it. I decided, anyway, to use it and commit the code beliving I have solved [apparently] the issue. So, then, Cuducos adviced me:

Ok, so never add code you don’t understand. Never. You can use it to ask: hey, I noticed that when I add that, it works for you. But this is a way to explore the issue rather than a solution. (@cuducos) here

Flat path to success

o flat path to success foi mencionado no processo de revisão do código e básicamente se refere a:

escrever o código de forma clara e direta, evitando aninhamentos e complexidades, onde o propósito principal do código é facilmente discernível sem mergulhar em estruturas aninhadas.

Instalando versão pacote Python a partir do GitHub

No processo de desenvolvimento é importante sempre testar o código em um ambiente diferente daquele no qual se está desenvolvendo a solução. Para isso, podemos instalar a versão do pacote diretamente do GitHub, especificando a branch a ser usada, conforme o exemplo abaixo.

pip install git+https://github.com/username/repo.git@branch_name

CROSSFIRE PYTHON CLIENT

Sat, 23 Dec 2023 00:00:00 +0000

SAILING ANALYSIS

Fri, 25 Aug 2023 00:00:00 +0000

DOMESTIC ECONOMY CHATBOT

Tue, 01 Aug 2023 00:00:00 +0000

Combinando Duas Paixões: Análise de Dados e Velejar.

Wed, 14 Jun 2023 00:00:00 +0000

Artigo publicado também no linkedin.

Olás! Tem algum tempo que gostaria de compartilhar com vocês um projeto pessoal, chamado “Sailing Analysis”. Neste projeto, busco unir duas paixões: análise de dados e velejar. Através do poder da tecnologia e da ciência de dados, estou explorando maneiras de aprimorar minha performance em regatas e compreender os fatores que influenciam os resultados.

Para dar vida ao “Sailing Analysis”, estou utilizando a linguagem de programação Python e uma variedade de bibliotecas especializadas. Vou guiar vocês através do processo que tenho seguido até agora: 1. 2. Exportação de Dados: Começo exportando os dados das minhas regatas, salvos em formato GPX, que é um padrão amplamente utilizado para representar informações de GPS, ao PostGIS, um banco de dados espacial, para armazenar e gerenciar esses dados. No entanto, caso você não esteja familiarizado com o PostGIS, também é possível trabalhar com um formato Geopackage. 2. Análise de Trajetória: Utilizando a biblioteca MovingPandas, desenvolvido pela Anita Graser, converto os pontos da rota realizada (track points) em uma estrutura de dados chamada “trajectory”. A partir disso posso calcular diversos atributos relevantes, como aceleração, diferença angular, direção e velocidade. Essas informações me ajudam a compreender melhor o desempenho do barco em diferentes momentos da regata. 3. Persistência de Dados: Após a análise da trajetória, persisto os dados no banco de dados PostGIS ou Geopackage. Essa etapa é fundamental para manter um registro completo das regatas e permitir análises futuras. 4. Dados Meteorológicos: Como as condições meteorológicas têm um papel crucial nas regatas, integro tais informações ao meu projeto. Através de duas fontes diferentes, obtenho dados meteorológicos relevantes. Primeiro, acesso a estação meteorológica mais próxima para obter informações atualizadas a cada hora. Além disso, utilizo um modelo meteorológico para obter previsões de vento para cada posição do barco ao longo da regata. 5. Visualização e Mapeamento: Por fim, utilizo as bibliotecas Pandas, Geopandas e Matplotlib para elaborar mapas detalhados das regatas. Esses mapas me permitem visualizar toda a rota ou partes específicas das regatas, com base nas horas de início e fim, junto com as infomações de condição do vento (figura 1).

Para tornar todo o processo mais eficiente e replicável, optei por usar tecnologias como Docker, que me permite criar um ambiente de desenvolvimento isolado e fácil de configurar. Além disso, utilizo o SQLAlchemy para mapear objetos Python ao banco de dados PostGIS e o Alembic para gerenciar as migrações do banco de dados. Quanto aos dados meteorológicos, faço uso das APIs do Open Weather Map e do Meteostat, que me fornecem acesso a informações detalhadas sobre o clima. Este projeto tem me proporcionado uma oportunidade única de combinar minhas paixões pessoais com habilidades técnicas. Através da análise de dados, estou ganhando insights valiosos sobre o meu desempenho na vela, identificando áreas de melhoria e descobrindo padrões que podem me ajudar a obter melhores resultados. No futuro, planejo expandir o “Sailing Analysis” e compartilhar minhas descobertas com outros velejadores. Acredito que a análise de dados pode beneficiar toda a comunidade náutica, proporcionando uma compreensão mais profunda das estratégias de regata, das condições ideais de vento e de outros fatores importantes. Se você também é apaixonado por velejar ou análise de dados, adoraria trocar experiências e ideias com você. Vamos nos conectar e impulsionar o potencial dessa combinação fascinante! Para saber mais sobre o projeto “Sailing Analysis” e acompanhar o seu desenvolvimento, visite o repositório no GitHub: Sailing Analysis.

Abraço e até breve!

Aprendendo sobre datetime, SQLAlchemy e PostgreSQL a partir de bugs

Wed, 15 Jun 2022 00:00:00 +0000

Há algum tempo comecei a perceber um “comportamento estranho” (ainda que tenha colocado o termo bug no título, acho que não é o caso. Foi para atrir mais atenção, mesmo:) relacionado aos dados de data e hora num sistema que estava desenvolvendo. Minha reação inicial, praticamente um instinto de sobrevivência, foi simplesmente resolver a situação contornando o problema. Mas chegou um momento que precisei entender a origem do mesmo. Mais uma vez tive que fazer um exercício de seguir/isolar o problema que me assombrava (veja outros artigos que produzi sobre bugs/comportamentos estranhos) para tentar compreender o motivo da sua existência. Esse processo tomou-me alguns dias e, claro, proporcionou alguns aprendizados.

Ainda que agora, tendo resolvido e entendido as causas e origens desse comportamento, tudo parece óbvio, decidi compartilhar um pouco deste processo, pois nessa busca por soluções não encontrei nada que me ajudasse de forma objetiva.

Criei um ambiente para reproduzir esses “comportamentos estranhos” (há uma seção sobre como preparar um ambiente para poder reproduzir esses códigos) e deixarei os trechos de códigos usados para vocês poderem reproduzir os passos dados. Irei trabalhar em todos os exemplos com um mesmo objeto de data e hora (instância datetime) mudando apenas o uso de fuso horário, para torná-los conscientes (aware) ou não (naive, ingênuo) (leia um pouco sobre isso aqui). Na seção final, “resumo”, deixo os principais aprendizados deste processo.

Contextualizando o sistema

Antes de tudo, lhes resumo a parte que importa do sistema:

O mesmo estava em um servidor com fuso horário UTC, e nele eu manipulava um dado de data e hora, usando o módulo python datetime, com time zone consciente (aware), transformando-os ao time zone de Brasília (-0300). Esse dado era, então, persistido no banco de dados PostgreSQL, que estava em outro servidor, também com fuso horário UTC. Os dados eram persistidos em duas colunas diferentes: uma coluna DateTime com time zone consciente e numa coluna de texto onde, além da data e hora em formato iso, uma observação textual era adicionada (que não vem ao caso, agora). Mas é importante saber que tínhamos o mesmo dado de data e hora persistido como tal e como texto.

Um detalhe não menos importante é o fato de eu estar usando o módulo pytz para definir o fuso America/Sao_Paulo, e o SQLAlchemy, para fazer a conexão com o banco de dados, commit e etc. Pensando em facilitar a minha vida, estive usando o DBeaver, uma interface gráfica para gestão de banco de dados. Ou seja, usava o DBeaver para conectar ao banco de dados e observar o que estava sendo persistido sem precisar fazê-lo pelo psql.

Reproduzindo comportamentos estranhos

Basicamente criei uma instância datetime ingênua (naive) em relação ao time zone e outra com time zone declarado ( consciente, aware). Criei uma instância da tabela persistindo cada dado nas suas respectivas colunas (consciente na coluna consciente e ingênuo na coluna ingênua) (veja aqui sobre a criação do ambiente para reproduzir esses códigos).

import pytz
from datetime import datetime
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

engine = create_engine(
 f"postgresql+psycopg2://postgres:password@localhost:5432/postgres")

Session = sessionmaker(bind=engine)
session = Session()


BR_TIME_ZONE = pytz.timezone("America/Sao_Paulo")

naive = datetime(2022, 5, 27, 12, 30, 0, 0)
aware = naive.replace(tzinfo=BR_TIME_ZONE)

record = DateTimeTable(
 date_time_tz_aware=aware,
 isoformat_tz_aware=f"{aware.isoformat()}",
 date_time_naive=naive,
 isoformat_naive=f"{naive.isoformat()}"
)

session.add(record)
session.commit()
session.close()

Ao fazer o commit e consultar a base de dados, começa o terror e pânico:

Usando o DBeaver para acessar o registro criado (seja pela interface gráfica como pela query da GUI), observei que:

O valor persistido na coluna consciente foi alterado em seis minutos (acrescidos). Deveria ser 12:30 e passou a ser 12:36, ao passo que a informação de time zone é apresentada de forma correta: -0300;
O dado da coluna iso_format_tz_aware possui a informação sem qualquer alteração. Ao passo que a time zone informada não é a esperada (-0300), mas -03:06. Lembrem-se que o time zone da coluna date_time_aware é informado apenas -0300;
Os dados persistidos nos campos time zone ingênuos não apresentaram qualquer alteração.

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:36:00.000 -0300	2022-05-27T12:30:00-03:06	2022-05-27 12:30:00.000	2022-05-27T12:30:00

Contudo, ao acessar esses dados usando o SQLAlchemy, a confusão aumenta:

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 15:36:00+00:00	2022-05-27T12:30:00-03:06	2022-05-27 12:30:00	2022-05-27T12:30:00

Reparem que agora temos:

Na coluna date_time_tz_aware, o objeto tem três horas e seis minutos acrescidos e o time zone informado como UTC (+00:00).
Os dados das colunas iso_format, date_time_naive e isoformat_naive apresentam os dados assim como estão no banco de dados.

Comportamentos estranhos a serem resolvidos:

O time zone deveria ser de -0300. De onde veio os seis minutos a mais?
Afinal, o dado é persistido no banco de dados em UTC (como retornado pelo SQLAlchemy) ou no fuso horário informado no objeto datetime (como retornado pelo DBeaver)?

Resolvendo problema de definição de time zone

Ao apresentar esses problemas aos amigos que tenho como referência na área, um deles, o @georgersilva, me alertou que a forma como eu estava definido o time zone estava equivocado. A única direção dada por ele foi essa pergunta no Stack Overflow.

Um comentário me chamou a atenção:

@MichaelWaterfall: pytz.timezone() may correspond to several tzinfo objects (same place, different UTC offsets, time zone abbreviations). tz.localize(d) tries to find the correct tzinfo for the given d local time (some local time is ambiguous or doesn’t exist). replace() just sets whatever (random) info pytz time zone provides by default without regard for the given date (LMT in recent versions). tz.normalize() may adjust the time if d is a non-existent local time e.g., the time during DST transition in Spring (northern hemisphere) otherwise it does nothing in this case.

Em tradução livre:

pytz.timezone() pode corresponder a objetos com diferentes tzinfo (mesmo local, diferentes offset em relação ao UTC). tz.localize(d) tenta encontrar o tzinfo correto para um dada hora local (algumas horas locais são ambíguas ou inexistentes). replace() apenas define qualquer informação de time zone por padrão sem se preocupar com a data. tz.normalize() deve ajustar a informação de tempo se o objeto d não possuir informação de hora local.

Como estou usando o pytz para definir um objeto de data com fuso horário, o replace não seria a forma correta, mas sim, o método localize da própria instância pytz.timezone.

Vamos testar, então:

BR_TIME_ZONE = pytz.timezone("America/Sao_Paulo")
naive = datetime(2022, 5, 27, 12, 30, 0, 0)
naive.replace(tzinfo=BR_TIME_ZONE)
# datetime.datetime(2022, 5, 27, 12, 30, tzinfo=<DstTzInfo 'America/Sao_Paulo' LMT-1 day, 20:54:00 STD>)
BR_TIME_ZONE.localize(naive)
# datetime.datetime(2022, 5, 27, 12, 30, tzinfo=<DstTzInfo 'America/Sao_Paulo' -03-1 day, 21:00:00 STD>)

Reparem a diferença que isso fez no parâmetro tzinfo da instância: há uma diferença de seis minutos no objeto ao qual usei o método replace(). Ao usar o localize(), a informação de fuso horário “-03” aparece.

Fiz mais um teste para entender se o problema é o método replace ou a forma como o pytz define o time zone:

datetime(2022, 5, 27, 12, 30, 0, 0, tzinfo=BR_TIME_ZONE)
# datetime.datetime(2022, 5, 27, 12, 30, tzinfo=<DstTzInfo 'America/Sao_Paulo' LMT-1 day, 20:54:00 STD>)

Mesmo passando o time zone do pytz como parâmetro tzinfo, a diferença de seis minutos segue (20:54). Ou seja, também não seria a forma correta.

Na documentação do localize, há apenas a menção:

Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones.

Ao salvar no banco de dados o objeto aware criado usando o localize, os dados foram, enfim, salvos de forma correta:

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:30:00.000 -0300	2022-05-27T12:30:00-03:00	2022-05-27 12:30:00.000	2022-05-27T12:30:00

✔️ OK, um problema resolvido. Gracias, @georgersilva!
❓ Mas ainda fica o mistério das conversões entre o dado acessado pelo DBeaver daquele acessado pelo SQLAlchemy.

Enquanto estava tentando resolver esse segundo problema, o @dunossauro fez uma live de python sobre datetime. Fui assistir e vi que ele indicou usarmos a definição de time zone usando timedelta. Me pareceu sensato.

Vamos testar, então:

Resolvendo problema de definição de time zone com `timedelta`

from datetime import timezone, timedelta

# BR_TIME_ZONE = pytz.timezone("America/Sao_Paulo")
BR_TIME_ZONE = timezone(timedelta(hours=-3))
datetime(2022, 5, 27, 12, 30, 0, 0, tzinfo=BR_TIME_ZONE)
# datetime.datetime(2022, 5, 27, 12, 30, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=75600)))
datetime(2022, 5, 27, 12, 30, 0, 0).replace(tzinfo=BR_TIME_ZONE)
# datetime.datetime(2022, 5, 27, 12, 30, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=75600)))

Reparem que agora não estamos mais usando uma instância timezone do pytz e por isso não podemos usar o método localize(). Com o timedelta, obtivemos os resultados esperados tanto passando o objeto no parâmetro tzinfo, na criação da instância datetime, como ao usar o método replace.

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:30:00.000 -0300	2022-05-27T12:30:00-03:00	2022-05-27 12:30:00.000	2022-05-27T12:30:00

Dessa forma também temos os dados persistidos corretamente e ainda nos poupa de usar o pytz. Gracias, @dunossauro!

O mistério das consultas sendo retornadas em UTC e -0300

Só para refrescar a memória: Ao acessar os dados persistidos no banco de dados usando o DBeaver, os recebia com o time zone -0300, enquanto ao acessar pelo SQLAlchemy, os mesmos dados eram retornados em UTC +00:00.

Decidi acessar o banco e fazer as consultas apresentadas anteriormente pelo psql e pelo DBeaver para confirmar:

o fuso horário da instância do banco de dados, e;
o fuso horário dos dados persistidos;

Confirmando o fuso horário da instância do banco de dados

Executando o mesmo comando no psql e DBeaver para uma mesma instância de banco dados tive diferentes retornos:

psql -h localhost -U postgres -p 5432 postgres

show timezone;

Eis, então, que fica evidente: A ferramenta usada para conexão e consulta ao banco de dados é que foram as responsáveis pelas diferenas observadas no time zone.

Isso me fez lembrar da documentação do PostgreSQL que já havia lido, mas não tinha dado a devida atenção:

For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system’s time zone parameter, and is converted to UTC using the offset for the time zone zone. fonte

Em tradução livre:

Para dados com informação de time zone, o valor armazenado estará sempre em UTC (também conhecido como GMT). Um valor de entrada que não tenha time zone declarado explicitamente será convertido a UTC usando o time zone indicado pelo sistema.

A partir disso, várias constatações:

Os dados que possuem a informação de time zone, são convertidos a UTC. Os dados sem essa definição é entendido como já estando em UTC, logo não é convertido.
O DBeaver identificou o time zone da minha máquina e ao retornar uma consulta já convertia todos os dados considerando o time zone da minha maquina.
Não é o SQLAlchemy que define como os dados serão resgatados, mas o PostgreSQL. Na verdade, essa definição é feita pela seção de conexão com o banco de dados.

Vejam:

psql -h localhost -U postgres -p 5432 postgres

PostgreSQL= show time zone;
# time zone
# ----------
# Etc/UTC
# (1 row)

select * from datetime;

Com uma seção (conexão) recém iniciada, o time zone é configurado para UTC (padrão), com os dados sendo retornados em UTC.

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 15:36:00+00	2022-05-27T12:30:00-03:06	2022-05-27 15:36:00	2022-05-27T12:30:00-03:06
2	2022-05-27 12:30:00+00	2022-05-27T12:30:00	2022-05-27 12:30:00	2022-05-27T12:30:00

Se, na mesma conexão, eu configuro o time zone para America/Sao_Paulo, e executo a mesma query, os dados na coluna com time zone consciente serão apresentados convertidos ao time zone definido na conexão (-0300).

postgres=set timezone = 'America/Sao_Paulo';
#SET
postgres=show timezone;
# timezone
# -------------------
# America/Sao_Paulo
# (1 row)


select * from datetime;

Eis que todos os dados são retornados em -0300:

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:36:00-03	2022-05-27T12:30:00-03:06	2022-05-27 12:30:00	2022-05-27T12:30:00
2	2022-05-27 09:30:00-03	2022-05-27T12:30:00	2022-05-27 12:30:00	2022-05-27T12:30:00

Tudo parece bem óbvio, não? Mas uma coisa que foi fundamental para a minha confusão mental sobre esse comportamento: o fato de estar usando o DBeaver os dados eram apresentados já convertidos para a time zone do meu sistema e, com isso, eu acreditava que os mesmos estavam sendo persistidos como tal no banco de dados. Ao acessar os dados pelo SQLAlchemy (que usa uma seção padrão, sem configuração de time zone, logo em UTC) recebia os dados em UTC. Ficando sem entender o que, de fato, estava sendo persistido.

:heavy_checkmark: Fica o aprendizado: O PostgreSQL irá retornar os dados de data e hora no time zone da seção de conexão, que por padrão é UTC. Caso vc queira receber-los em outro time zone, basta definir usando o SET timezone, ou, se for usando o SQLAlchemy, você poderá fazê-lo usando o parâmetro connect_args:

engine = create_engine(..., connect_args={"options": "-c timezone=-3"})`

coluna naive e aware

Ainda que tenha tomado um tempo considerável resolução de todas essas dúvidas, não chegou a esgotar a minha paciência. Por isso, fiz mais alguns testes, para tentar entender, de vez, a diferença entre usar ou não coluna com time zone consciente e ingênua no PostgreSQL.

Ainda que já esteja superada a dúvida sobre as diferenças entre DBeaver e SQLAlchemy, seguirei apresentando as consultas usando ambas ferramentas, pois isso nos ajudará a entender as consequências ao usar campo consciente ou ingênuo.

Primeiro teste:

Inseri em ambos campos de datetime (consciente e ingênuo), um objeto com time zone consciente:

record = DateTimeTable(
 date_time_tz_aware=aware,
 isoformat_tz_aware=f"{aware.isoformat()}",
 date_time_naive=aware,
 isoformat_naive=f"{aware.isoformat()}"
)
session.add(record)
session.commit()

Ao fazê-lo, o PosgreSQL entenderá o time zone do dado e, como dito anteriormente, os persitirá em UTC (logo, acrescentando três horas). Isso tanto para o campo consciente como para o campo ingênuo. A diferença, contudo estará no resgate da informação por uma seção em UTC ou em outro time zone:

Acessando esse dado pelo DBeaver (seção com time zone configurado em -0300), tenho o valor do campo aware convertido ao time zone da seção (-0300) e indicando o mesmo, ao passo que o valor persistido no campo naive se mantêm em formato UTC e sem a indicação do time zone:

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:30:00.000 -0300	2022-05-27T12:30:00-03:00	2022-05-27 15:30:00.000	2022-05-27T12:30:00-03:00

á pelo SQLAlchemy a informação persistida no campo time zone consciente é retornada respeitando o time zone da seção (logo, time zone UTC) e no campo ingênuo, não há alteração.

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 15:30:00+00:00	2022-05-27T12:30:00-03:00	2022-05-27 15:30:00	2022-05-27T12:30:00-03:00

Segundo teste:

Ao inserir em ambos campos, um objeto ingênuo, o PostgreSQL entende que os mesmos já estão em UTC. Logo, ao acessá-los pelo DBeaver (seção com time zone -0300), o valor no campo consciente apresenta o desconto de três horas e apresenta a informação de time zone -0300, e na coluna naive, os valores não são alterados.

# terceiro registro inserindo datetime naive sempre
record = DateTimeTable(
 date_time_tz_aware=naive,
 isoformat_tz_aware=f"{naive.isoformat()}",
 date_time_naive=naive,
 isoformat_naive=f"{naive.isoformat()}"
)
session.add(record)
session.commit()

session.close()

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 09:30:00.000 -0300	2022-05-27T12:30:00	2022-05-27 12:30:00.000	2022-05-27T12:30:00

Acessando so dados pelo SQLAlchemy, tanto a coluna consciente como a ingênua apresentam o mesmo valor. Contudo, no campo consciente, a informação do time zone é existente (+00:00:00).

id	date_time_tz_aware	iso_format_tz_aware	date_time_naive	isofomat_naive
1	2022-05-27 12:30:00+00:00	2022-05-27T12:30:00	2022-05-27 12:30:00	2022-05-27T12:30:00

Preparando ambiente de desenvolvimento

Para isolar e reproduzir os comportamentos apresentados segui os seguintes passos:

Criação de um ambiente virtual;
Activação do ambiente virtual;
Atualização do pip;
Instalação dos pacotes listados em requirements.txt;
Criei uma instância do banco de dados PostgreSQL usando docker;
Criei os modelos as tabelas usando SQLAlchemy;

mkdir datetime
cd datetime
python -m venv .venv
source .venv/bin/activate
pip intall --upgrade pip
pip install -r requirements.txt

Docker com PostgreSQL

Para facilitar, criei uma instância Docker com a imagem original do PostgreSQLQL. Caso já o tenha instalado em sua máquina, desconsidere.

docker pull PostgreSQL

docker run --name teste_datetime -e PostgreSQL_PASSWORD=password -d PostgreSQL

# confirmando existencia
docker container ps
#CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
#c77150c506a8 PostgreSQL "docker-entrypoint.s…" 6 seconds ago Up 5 seconds

Modelo de dados e conexão com SQLAlchemy

Crio, em um arquivo models.py, a classe que representará a tabela datetime do banco de dados. Nela teremos os campos date_time_tz_aware, date_time_naive que são, ambos, DateTime(), com o parâmetro timezone=True (verdadeiro e falso, respectivamente). Os campos isoformat_tz_aware e isoformat_naive serão os campos textuais que persistirão os dados de data e hora em formato isoformat().

# models.py
import json

from sqlalchemy import Integer, DateTime, Text
from sqlalchemy import create_engine, Column
from sqlalchemy.ext.declarative import declarative_base


Base = declarative_base()


BD_USERNAME = "PostgreSQL"
BD_PASSWORD = "password"
BD_HOST = "localhost"
BD_PORT = "5433"
BD_NAME = "PostgreSQL"


def db_connect():
 return create_engine(
 f"PostgreSQLql+psycopg2://{BD_USERNAME}:{BD_PASSWORD}@{BD_HOST}:{BD_PORT}/{BD_NAME}"
 )


def create_table(engine):
 Base.metadata.create_all(engine)


class DateTimeTable(Base):
 __tablename__ = "datetime"

 id = Column(Integer, primary_key=True)
 date_time_tz_aware = Column(DateTime(timezone=True))
 isoformat_tz_aware = Column(Text)
 date_time_naive = Column("datetime_naive", DateTime(timezone=False))
 isoformat_naive = Column(Text)


engine = db_connect()
create_table(engine)

Identificando time zone das instâncias de trabalho

Para confirmar que estamos reproduzindo as mesmas situações, vamos confirmar o time zone da base de dados.

Docker PostgreSQL

psql -h localhost -U PostgreSQL -p 5433
show timezone;
# timezone
#----------
# Etc/UTC
#(1 row)

Ao executar a consulta select now(), ele me dá a data e hora com a info de time zone utc (+00):

select now();
# now
#-------------------------------
# 2022-05-27 15:36:59.903336+00
#(1 row)

E o mesmo com python:

python

from datetime import datetime
datetime.now().astimezone().tzinfo
#datetime.timezone(datetime.timedelta(days=-1, seconds=75600), '-03')

Ou seja, o sistema no qual está rodando o python, está com o time zone -03 em relação ao UTC.

⚠️ Atenção, dependendo de como estiver configurado seu sistema, esse resultado poderá ser diferente do meu.

Resumindo

É possível usar tanto o timedelta como TimeZone, do pytz, para definir o tzinfo de uma instância datetime. Contudo, é preciso cuidado com relação ao método usado na atribuição do tzinfo:
- Caso se esteja usando uma instância TimeZone do pytz, é indicado usar o método localize;
- Já usando o timedelta, pode-se fazê-lo tanto na criação da instância datetime, quanto usando o método replace do objeto datetime já instanciado;

BR_TIME_ZONE = pytz.timezone("America/Sao_Paulo")
date_time_ibject = datetime(2022, 5, 27, 12, 30, 0, 0)
BR_TIME_ZONE.localize(date_time_ibject)
# usando timedelta
BR_TIME_ZONE = timezone(timedelta(hours=-3))
date_time_object = datetime(2022, 5, 27, 12, 30, 0, 0, tzinfo=BR_TIME_ZONE)
# OU
date_time_object = datetime(2022, 5, 27, 12, 30, 0, 0)
date_time_object.replace(tzinfo=BR_TIME_ZONE)

Os dados de data e hora são sempre armazenados em UTC no PostgreSQL, independente de estarmos ou não usando campos com time zone conscientes. Logo, ao persistir um dado consciente, o mesmo será convertido e persistido em UTC, mesmo em campos ingênuos. Objetos sem informação de time zone, serão persistido como tais por se entender já estarem em UTC. A diferença em relação a esses tipos de campos se dá pelo fato do primeiro armazenar a informação do time zone e o último, não.
Outra diferença entre campo consciente e ingênuo se dá nas consultas: Os campos conscientes, ao serem consultados por uma seção com time zone diferente do padrão (UTC), retornará os dados convertidos ao time zone da seção;
- Para definir o time zone de uma seção, pode-se usar:

# psql
set timezone = 'America/Sao_Paulo';

# ou
# SQLAlchemy
engine = create_engine(..., connect_args={"options": "-c timezone=-3"})

Não poderia deixar de agradecer ao @cuducos pelo incentivo em resolver os problemas encontrados e ajuda na revisão do texto. Eu acabei encontrando essas soluções antes de ter tempo de seguir a sugestão dele: “tentar identificar o como o SQLAlchemy estava fazendo o insert dos dados e o resgate dos mesmos”. Vejo que, de alguma forma, foi o direcionamento que acabei tomando para entender a diferença nos fuso horários retornados pelas consultas.

Criando um sistema para gestão de dados geográficos de forma simples e robusta III.

Sat, 04 Jun 2022 00:00:00 +0000

Caso não tenha visto as publicações anteriores, deixo aqui o link e os temas abordados:

Na primeira publicação falo sobre o django-geojson para simular um campo geográfico no models; o geojson para criar um objeto da classe geojson e realizar as validações necessárias para garantir robustez do sistema, e a criação do formulário de registro de dados usando o ModelForm;
Na segunda publicação apresento os validadores de campo do Django como uma ferramenta fundamental na qualidade dos dados espaciais, sem depender de infraestrutura SIG (GIS).

Agora a ideia é implementar um webmap usando o módulo django-leaflet para apresentar os fenômenos mapeados com algumas informações no popup do mapa. Para isso iremos:

usar o GeoJSONLayerView, do django-geojson para retornar os dados salvos no formato apropriado para exibição no webmap;
usar o django-leaflet para, além de implementar o webmap, podermos usar várias outras ferramentas (widget);

Vamos lá!

View GeoJSONLayerView

A serialização ou, em inglês serialization, é o processo/mecanismo de tradução dos objetos armazenados na base de dados em outros formatos (em geral, baseado em texto como, por exemplo, XML ou JSON), para serem enviados e/ou consumidos no processo de request/response.

No nosso caso isso será importante, pois para apresentar os dados salvos em um webmap, precisaremos servi-los no formato geojson. E é aí que o django-geojson entra. Nós o utilizaremos para fazer a mágica acontecer ao usar a classe GeoJSONLayerView.

A classe GeoJSONLayerView é um mixin que, em base ao modelo informado do nosso projeto, serializa os dados transformando-os em geojson e os servindo em uma view. Acredite, é bastante coisa para apenas algumas linhas de código.

Para entender a serialização, segue um exemplo…

Ao acessar os dados do banco de dados do nosso projeto, temos uma QuerySet.

>>> Fenomeno.objects.all()
<QuerySet [<Fenomeno: fenomeno_teste>]>

Ao acessar a geometria de um objeto do banco de dados do nosso projeto, temos um geojson.

>>> Fenomeno.objects.get(pk=3).geom
{'type': 'Point', 'coordinates': [-42.0, -22.0]}

Ao serializá-lo com o GeoJSONSerializer, temos como retorno uma FeatureCollection seguindo o formato geojson, tendo como propriedades os campos do model:

>>> from djgeojson.serializers import Serializer as GeoJSONSerializer
>>> GeoJSONSerializer().serialize(Fenomeno.objects.all(), use_natural_keys=True, with_modelname=False)
'{'crs': {'properties': {'href': 'http://spatialreference.org/ref/epsg/4326/',
 'type': 'proj4'},
 'type': 'link'},
 'features': [{'geometry': {'coordinates': [-42.0, -22.0], 'type': 'Point'},
 'id': 3,
 'properties': {'data': '2021-06-22',
 'hora': '02:07:57',
 'nome': 'teste'},
 'type': 'Feature'}],
 'type': 'FeatureCollection'}'

Mais sobre serialização pode ser encontrado aqui ou aqui, com outro exemplo relacionado a dado geográfico usando o GeoDjango.

Então, ciente de toda a mágica por trás do GeoJSONLayerView e o seu resultado, vamos criar os testes para essa view.

Criando os testes da `view`

Como estou testando justamente uma view que serializa o objeto do meu modelo em formato geojson, precisarei desses dados salvos no banco de dados. Para tanto, vou adicionar ao setUp do meu TestCase valores válidos ao banco de dados do teste. Sem isso, não poderemos confirmar se a serialização está ocorrendo de forma correta. E, uma vez salvo, realizo um conjunto básico de testes:

Confirmo se o status code do request (método “get”) ao path que pretendo usar para essa views (no caso, “/geojson/"), retorna 200, código que indica sucesso no processo de request/response. Veja mais sobre os códigos aqui.
Em seguida, confirmo se a resposta recebida é uma FeatureCollection com os dados da instância criada anteriormente.

# testes.py
class FenomenoGeoJsonTest(TestCase):
 def setUp(self):
 Fenomeno.objects.create(
 nome="Teste",
 data="2020-01-01",
 hora="09:12:12",
 geom={"type": "Point", "coordinates": [-42, -22]},
 )

 def teste_geojson_status_code(self):
 self.resp = self.client.get(r("geojson"))
 self.assertEqual(200, self.resp.status_code)

 def teste_path_geojson_returns_valid_feature_collection(self):
 self.resp = self.client.get(r("geojson"))
 self.assertEqual(
 self.resp.json(),
 {
 "type": "FeatureCollection",
 "features": [
 {
 "type": "Feature",
 "properties": {
 "popup_content": "<p><strong><span>Nome: </span>Teste</strong></p>",
 "model": "core.fenomeno",
 },
 "id": 1,
 "geometry": {"type": "Point", "coordinates": [-42.0, -22.0]},
 }
 ],
 "crs": {"type": "name", "properties": {"name": "EPSG:4326"}},
 },
 )

Obviamente, ambos testes falharão, pois, ainda não criamos a view e nem a designamos a um path do nosso sistema.

Para fazê-los passar, vamos primeiro criar a view: Em views.py criaremos uma classe nova, herdando da classe GeoJSONLayerView. Ela será a view responsável por resgatar os dados e servir-nos como uma FeatureCollection seguindo a estrutura de um geojson.

Um último detalhe é que, como estamos usando um Class Based-View, ao final a convertemos em view, com o método as_view().

# views.py
from djgeojson.views import GeoJSONLayerView

from map_proj.core.models import Fenomeno


class FenomenoGeoJson(GeoJSONLayerView):
 model = Fenomeno
 properties = ("popup_content",)


fenomeno_geojson = FenomenoGeoJson.as_view()

Percebam que no teste_geojson_FeatureCollection eu já estou considerando que o geojson virá com properties com o nome de popup-content. Essa property ainda deverá ser criada no model em questão e poderá ter quantas informações acharmos pertinentes. Se tratam das informações do model a serem apresentadas no popup do mapa.

Por agora estou apenas informando o nome do fenômeno mapeado mas, mais à frente, podemos incrementar, adicionando um get_absolute_url por exemplo, para poder acessar aos detalhes do fenômeno diretamente a partir do popup do mapa.

#models.py
...
 @property
 def popup_content(self):
 return self.nome

Adicionando um path a view

Para poder acessar essa view, precisamos incorporá-la na nossa urls.py:

# urls.py
from django.contrib import admin
from django.urls import path

from map_proj.core.views import fenomeno_geojson # novo!

urlpatterns = [
 path("admin/", admin.site.urls),
 path("geojson/", fenomeno_geojson, name="geojson"), # novo!
]

Com isso teremos os nossos últimos testes passando. Se ainda assim você tiver curiosidade, pode executar o runserver e acessar os dados pela url http://127.0.0.1:8000/geojson/. O resultado esperado são os dados servidos em geojson:

{
 "type": "FeatureCollection",
 "features": [
 {
 "type": "Feature",
 "properties": {
 "popup_content": "<p><strong><span>Nome: </span>Teste</strong></p>",
 "model": "core.fenomeno",
 },
 "id": 1,
 "geometry": {"type": "Point", "coordinates": [-42.0, -22.0]},
 }
 ],
 "crs": {"type": "name", "properties": {"name": "EPSG:4326"}},
 }

⚠️ Garanta que você já tenha inserido algum dado ao seu projeto ;)

Pronto, já temos uma view nos servindo os dados em formato geojson. Vamos ao Django-leaflet, para entender como montar um webmap.

Django-leaflet

Para saber mais sobre o django-leaflet, recomendo dar uma olhada na página pypi e na documentação.

Você deve estar se perguntando: “por quê usar o django-leaflet se eu posso usar o leaflet “puro”, já que se trata de uma biblioteca JavaScript para produção do mapa no frontend?”.

Os autores do projeto django-leaflet deixam alguns pontos que justificam sua adoção na página da documentação. Das quais eu destaco:

Possibilidade de uso das ferramentas de edição de geometría usando os widget;
Fácil integração dos widgets na página admin do Django;
Controle da aparência dos mapas a partir do Django settings.py;

⚠️ E por último, mas não menos importante:

django-leaflet é compatível com os campos django-geojson, o que permite o uso de dados geográficos sem a necessidade de uma base de dados espaciais. O motivo de toda essa série que tenho produzido :)

Bem legal! Eles criaram um pacote já compatível com o pacote django-geojson, que nos permite simular campos geográficos sem a necessidade de toda a infraestrutura de uma base de dados de SIG (PostGIS, por exemplo).

⚠️ Porém, atenção ao seguinte detalhe:+

O django-leaflet depende da biblioteca GDAL, não se esqueça de instalá-la antes.

Instalando `django-leaflet`

pip install django-leaflet

Após a sua instalação é necessário incluí-lo no settings.py como INSTALLED_APPS.

⚠️ Não esqueça de adicioná-lo ao requirements.txt do projeto, também.

# settings.py
INSTALLED_APPS = [
 ...
 'djgeojson',
 'leaflet', # novo
 ...
]

Usando o leaflet

Com leaflet instalado, devemos então:

Na pasta da nossa app, vamos criar uma pasta chamada “templates”;
E nessa pasta, criar um arquivo HTML (neste caso vou chamar de “map.html”;
Nessa página vamos carregar as template_tags do leaflet para poder usar leaflet_js, leaflet_css e o leaflet_map:

Nosso map.html:

% load leaflet_tags %}

<head>
 ...
 {% leaflet_js %}
 {% leaflet_css %}
</head>
...
<body>
 ...
 {% leaflet_map "yourmap" %}
 ...
</body>

Essas template_tags irão tentar acessar as configurações do leaflet presentes no settings.py da app, caso existam. Do contrário, serão usados valores padrão de configuração. O interessante dessas template_tags é que com elas podemos customizar tais configurações a cada template;

Como a ideia é apenas renderizar essa página, vou adicionar ao urls.py um path a ela, usando o TemplateView. Com isso, ao receber um request neste path, a responsta será direcionada à renderização dessa página:

#urls.py
from django.contrib import admin
from django.urls import path
from django.views.generic import TemplateView

from map_proj.core.views import fenomeno_geojson

urlpatterns = [
 path("admin/", admin.site.urls),
 path("geojson/", fenomeno_geojson, name="geojson"),
 path("map/", TemplateView.as_view(template_name="map.html"), name="map"),
]

Isso já o suficiente para termos nosso webmap apresentado:

Imagino que não seja o que esperava, né? Fique calmo. O leaflet buscou as configurações do mapa e, como não encontrou, retornou o mesmo com as configurações padrão. Veremos em breve como alterar as configurações do mapa.

Antes disso, vamos “linkar” a view que nos serve o geojson com os dados salvos no banco com o webmap em questão, para que os dados sejam apresentados.

Renderizando o `geojson` no mapa

Lembra que temos uma view que serializa os dados armazenados no banco e nos serve como uma FeatureCollection e que podemos acessar tais dados pelo path geojson/?

Então, iremos adicionar um script à nossa página no qual uma variável dataurl receberá os dados dessa url adicionando tais dados ao mapa, assim que o mesmo for inicializado, desencadeando o processo de construção da popup de cada feição apresentada com sua posterior inserção ao mapa:

{% load leaflet_tags %}

 <script>
 var dataurl = '{% url "geojson" %}';

 window.addEventListener("map:init", function (event) {
 var map = event.detail.map;
 // Download GeoJSON data with Ajax
 fetch(dataurl)
 .then(function(resp) {
 return resp.json();
 })
 .then(function(data) {
 L.geoJson(data, {
 onEachFeature: function onEachFeature(feature, layer) {
 var props = "<p><strong><span>Nome: </span> " + feature.properties.popup_content + "</strong></p>";
 layer.bindPopup(props);
 }}).addTo(map);
 });
 });

 </script>



<head>
 {% leaflet_js %}
 {% leaflet_css %}
</head>
<body>

{% leaflet_map "yourmap" %}

</body>

Veja que, para a criação da variável dataurl, estamos usando a template_tag do django: var dataurl = '{% url "geojson" %}';

Veja mais sobre ela aqui.

Repare também que, neste processo, a cada Feature, será carregada as suas propriedades a serem apresentadas no popup:

L.geoJson(data, {
 onEachFeature: function onEachFeature(feature, layer) {
 var props = "<p><strong><span>Nome: </span> " + feature.properties.popup_content + "</strong></p>";
 layer.bindPopup(props);
 }}).addTo(map);

Com o runserver em execução, já poderemos ver o nosso mapa com o dado carregado e as propriedades que definimos no popup:

)

⚠️ Garanta que você já tenha inserido algum dado ao seu projeto ;)

Mudando o tamanho do webmap:

Antes de passarmos às configurações do leaflet, podemos alterar as dimensões do mapa definindo um style. Por exemplo, para que o mapa ocupe toda a área possível do navegador, basta adicionarmos:

<style>
 #yourmap {
 width: 100%;
 height: 100%;
 }
</style>

)

Configurações do leaflet

Bom, além das template_tags do leaflet, o uso do django-leaflet nos permite definirmos as suas configurações no settings.py da app, a partir da seção LEAFLET_CONFIG.

Dentre as configurações possíveis, vou usar apenas o par de coordenadas ao qual o mapa deverá estar centralizado por padrão (DEFAULT_CENTER) e o zoom padrão (DEFAULT_ZOOM):

#settings.py
LEAFLET_CONFIG = {
 'DEFAULT_CENTER': (-22, -42),
 'DEFAULT_ZOOM': 7,
}

Com isso nosso mapa sempre será apresentado centralizado nas coordenadas (-22, -42) e com o zoom 7:

Pronto: com esses três artigos, já temos um sistema com formulário de inserção de dados, com as devidas validações dos dados preenchidos no mesmo, assim como um webmap apresentando-os ao mundo :-).

~~Na próxima publicação vamos ver como fazer o deploy desse sistema no heroku 🚀.~~ Infelizmente não darei sequencia a essa publicação já que o Heroku não tem mais instâncias gratuitas :/

Bug buster

Fri, 15 Apr 2022 00:00:00 +0000

Como tudo começou:

Estou trabalhando num projeto onde uma das funções do python é executada e recebe um um parâmtero pelo terminal. Um detalhe é que esse parâmetro é o nome de uma pessoa. Um ponto que não previ no processo de desenvolvimento é que nomes, como qualquer outro elemento textual da lingua portuguesa, podem ter acentos (ou “caracteres especiais”).

Pois é, foi praticamente sem querer que vi, olhando os logs produzidos, que os nomes com acento estavam com problema de encoding.

E assim começou a minha caça ao bug. Uma caça que me tomou um dia e meio. Mas foi de grande aprendizado.

Um pouco do contexto:

Antes de descrever essa aventura, comento um pouco o fluxo do programa que apresentou erro:

Uma função é executada pelo terminal e recebe um parâmtero, que é o nome de uma pessoa;
Esse nome é usado para instanciar um objeto. Logo no __init__ tenho o ponto de acesso ao que foi informado pelo terminal com a incorporação do mesmo como atributo da instância.
Alguns processamnetos, que não vem ao caso, são realizados;
O log do processamento realizado é persistirdo numa base de dados usando o SQLAlchemy, onde a tabela que o recebe possui um campo id e outro json, com os logs organizados em tal formato.

E agora? Por onde começar?

###Buscando o bug no terminal

Como o parâmetro estava sendo passado por terminal, achei que o problema estava nesse ponto: no terminal. Primeiro passo: checar o encoding usado pelo sistema. Mas logo vi que estava tudo em utf-8, o que por sí, não deveria apresentar problema.

Como o nome estava sendo passado como um parâmetro do sistema a partir de uma variável, aproveitei para checar se o erro não estava aí. Nada que um print e alguns testes no terminal não resolva. E nada, os nomes armazenados na variáve e passados como parâmetro não sofriam qualquer alteração neste processo inicial.

Interseção terminal/python

Achei, então que o erro estava em alguma incompatibilidade entre o que era passado no terminal e o como o python estava recebendo.

Segundo passo, então, foi checar o ponto de contato entre terminal e o python. Ler o seguinte trecho, de uma resposta do stackOverFlow me deu a certeza de que era aí o erro:

When Python does not detect that it is printing to a terminal, sys.stdout.encoding is set to None.

Ou seja, quando o python não pode detectar o que está sendo apresentado ao terminal o sys.stdout.encoding é definido como None; Ora, estou passando um parametro a partir de uma variável do terminal, logo um string. O Python não consegue identificar o encoding dessa string e está definindo, então o encoding a None, o que deve estar gerando o erro.

Tentando resolver isso, busquei alguma forma de declarar o encoding… Cheguei a adicionar ao __init__, quando a classe é instanciada e recebe o nome da pessoa os métodos, .encode().decode('utf-8') ao objeto que recebe o valor. Parecia que ia funcionar, vejam:

nome = 'Felipe Sodré'
b'Felipe Sodr\xc3\xa9'
# e ao adicionar o decode o texto volta ao normal...
nome.encode().decode('utf-8')
'Felipe Sodré'

“Meio” gambiarra, não? Mas o importante é se funcionar.

Contudo, o que parecia a solução, foi logo por agua abaixo na primeira rodada de teste. O nome continua com erro de encoding.

Decidí, então, usar o módulo logging para apresentar o nome recebido pelo terminal e nome após a classe estar instanciada durante o processamento. Aliás, o @dunosauro apresentou uma live muito boa sobre o uso do logging…

Bom, ao usar o logging tive certeza de que estava tentando resolver o erro no ponto errado, todas as mensagens de log estavam sem o tal erro de encoding, mas no log persistido no banco de dados seguia com o maldito erro…

Será que o banco de dados está configurado com uma encoding diferente?

No banco de dados…

✔️ Banco configurado como ‘utf-8’;

Até que me veio uma luz: nas mensagens de log o nome está sem erro. Mas o log que está sendo persistido no banco de dados ( que são algumas dessas mensagens filtradas para monitorar alguns pontos importantes do sistema) é uma compilação salva em um campo JSON.

“Bom deve ser nesse ponto, então.”, pensei.

Reproduzindo o erro em `JSON`

Parti então para tentar reproduzir esse erro:

>>>import json
>>>info = {'nome':'Felipe Sodré', 'idade':38}
>>>info
{'nome': 'Felipe Sodré', 'idade': 28}
>>>json.dumps(info)
'{"nome": "Felipe Sodr\xc3\xa9", "idade": 38}'

Pronto! Aí está o problema. No processo de conversão do dicionário ao JSON, há algum tipo de conversão que gera o erro de encoding.

Não levei “muito tempo” (tempo é relativo, né?) para encontrar que o método dumps() possui o parâmetro ensure_ascii, com valor padrão True, que garante que as strings do JSON que possuam caracteres não-ASCII estejam com scape.:

If ensure_ascii is true (the default), the output is guaranteed to have all incoming non-ASCII characters escaped. If ensure_ascii is false, these characters will be output as-is.

Testei usando o dumps() com ensur_ascii=False:

>>>json.dumps(info, ensure_ascii=False)
'{"nome": "Flávia Duarte Nascimento", "idade": 12}'

Pronto, ponto de erro encontrado. Basta adicionar o parâmetro apra False e tudo se resolveria.

Mas não foi bem assim, ainda faltava um ponto. Eu não estava gerando o dump e salvando no banco. O que estou fazendo é passar o dado, ainda em dicionário, para o banco usando o SQLAlchemy e ele cuida disso para mim.

Como, ou melhor, onde, então, eu devo informar esse ensure_ascii?

Enfim, a solução:

Foi lendo essa responta no SOF que entendí que como o ORM SQLAlchemy está cuidadno disso para mim, ele possui um serializador e que o mesmo é, nada mais, nada menos que os métodos json.dumps() e json.loads(), passados na função create_engine como um kwargs:

engine = create_engine(..., json_serializer=dumps)

O golpe final foi ao ler a docuementação do SQLAlchemy sobre o tipo de dado JSON e aprender que podemos customizar o serializador. Olha só o exemplo da documentação, me dando de “bandeja” a solução para o bug em questão:

engine = create_engine(
 "sqlite://",
 json_serializer=lambda obj: json.dumps(obj, ensure_ascii=False))

Agora sim, vida que segue, graças à persistẽncia e perseverança na caça aos bugs.

Ah, claro. Essa investigação contou com a ajuda de outros colegas que dedicaram alguns minutos para conversar e propor soluções, tabém. Muito obrigado!

Atualização

Quando achei que estava tudo funcionando e coloquei em produção a correção, eis que me deparo com um novo erro. Dessa vez um TypeError:

raise TypeError(f'Object of type {o.__class__.__name__} '
sqlalchemy.exc.StatementError: (builtins.TypeError) Object of type datetime is not JSON serializable

Com algumas pesquisas, pude identificar que, como estou indicando um serializador, Todo objeto a ser inluido no JSON passará por ele. Mas, como o próprio erro informa, um objeto datetime não pode ser seriaizado. E por isso que o método json.dumps(), além de ter o parâmetro ensure_ascii, possui um argumento para a serialização padrão.

Portanto o último bug foi resolvido usando o parâmetro default=str. Ou seja, o serializador padrãoa pe transformar o objeto a uma classe string.

O codigo ficou, então da seguinte forma:

engine = create_engine(
 "sqlite://",
 json_serializer=lambda obj: json.dumps(obj, ensure_ascii=False, default=str))

E vocês, que estratégias adotam na caça aos bugs?

Note: image from @ThePracticalDev

Criando um sistema para gestão de dados geográficos de forma simples e robusta II.

Sun, 11 Jul 2021 00:00:00 +0000

Artigo publicado também no linkedin.

Na primeira publicação onde exploro a possibilidade de implementar um sistema de gestão de dados geoespaciais com Django, sem a necessidade de usar um servidor com PostGIS, vimos sobre:

o django-geojson para simular um campo geográfico no models;
o geojson para criar um objeto da classe geojson e realizar as validações necessárias para garantir robustez do sistema;
a criação do formulário de registro de dados usando o ModelForm;

Agora é hora de evoluir e expandir um pouco o sistema criado. Nessa publicação vamos criar validadores de longitude e latitude para poder restringir a inserção de dados a uma determinada região. Com isso, o próximo passo (e artigo) será criar o webmap no nosso sistema. Mas isso fica para breve.

Vamos ao que interessa:

Criando validadores de longitude e latitude

Sobre os validadores:

Os validadores (validators, em inglês) fazem parte do sistema de validação de formulários e de campos do Django. Ao criarmos campos de uma determinada classe no nosso modelo, como por exemplo integer, o Django cuidará automaticamente da validação do valor passado a este campo pelo formulário, retornando um erro quando o usuário ingressar um valor de texto no campo em questão, por exemplo. O interessante é que além dos validadores já implementados para cada classe, podemos criar outros, conforme a nossa necessidade.

Por que necessitamos um validador para os campos de latitude e longitude?

Como estou explorando o desenvolvimento de um sistema de gestão de dados geográficos com recursos limitados, ou seja, sem uma infraestrutura de operações e consultas espaciais, não poderei consultar se o par de coordenadas inserido pelo usuário está contido nos limites de um determinado estado (uma operação clássica com dados geográficos). Não ter essa possibilidade de validação poderá colocar em risco a qualidade do dado inserido.

E como não se abre mão quando a questão é qualidade, uma saída será a criação de validadores personalizados para os campos de latitude e longitude, garantindo que esses possuem valores condizentes à nossa área de interesse.

O que precisamos saber: os validators são funções que recebem um valor, apenas (neste caso, o valor inserido pelo usuário no campo a ser validado), que passará por uma lógica de validação retornando um ValidationError quando o valor inserido não passar na validação. Com o ValidationError podemos customizar uma mensagem de erro, indicando ao usuário o motivo do valor não ter sido considerado válido, para que o mesmo corrija.

Então, criarei validadores dos campos de latitude e longitude para sempre que entrarem com valores que não contemplem a área do estado do Rio de Janeiro, um ValidationError será retornado.

⚠️ Essa não é uma solução ótima já que, dessa forma, estamos considerando o bounding box do estado em questão, e com isso haverá áreas onde as coordenadas serão válidas, ainda que não estejam internas ao território estadual. Ainda assim, acredito que seja uma solução boa suficiente para alguns casos, principalmente por não depender de toda infraestrutura de GIS.

O que é um bounding box?

Bounding box poderia ser traduzido por “retângulo envolvente” do estado, ou de uma feição espacial. Na imagem abaixo, vemos o território do estado do Rio de Janeiro e o retângulo envolvente que limita as suas coordenadas máximas e mínimas de longitude e latitude.

Percebam que, como mencionado antes, o que conseguimos garantir é que os pares de coordenadas estejam em alguma área interna ao retângulo em questão o que não garante que as mesmas estejam no território do estado do Rio de Janeiro.

Por uma questão de organização, criei no settings.py do meu projeto as variáveis com os valores máximos e mínimos de latitude e longitude. Essa proposta surgiu do cuducos, e achei que valia a pena implementar. Entendo que é mais organizado e evita possíveis falhas humanas, caso os mesmos valores tenham que ser usados em outras partes do sistema.

Ao fim do meu settings.py, adicionei:

# settings.py
BOUNDING_BOX_LAT_MAX = -20.764962
BOUNDING_BOX_LAT_MIN = -23.366868
BOUNDING_BOX_LON_MAX = -40.95975
BOUNDING_BOX_LON_MIN = -44.887212

Agora, sim. Vamos criar os testes:

se você não entendeu o motivo pelo qual eu começo criando testes, dá uma olhada na primeira publicação. Nela comento um pouco sobre a abordagem Test Driven Development (TDD).

Criando os testes:

No tests.py, criei uma nova classe de teste TestCase, com o objetivo de testar os validadores simulando o uso do FenomenoForm. Por isso criei staticmethod chamado create_form que cria um dicionário com chaves e valores válidos do formulário em questão, que ao receber um conjunto de argumentos nomeados **kwargs terá tais argumentos atualizados e usados para instanciar e retornar o FenomenoForm.

Fiz isso para, a cada teste, ter uma instância do FenoenoForm alterando apenas os campos que quero simular valores a serem validados, sem ter que passar sempre todos os valores do ModelForm. Assim, eu posso criar diferentes métodos de Test Case, usando o método criado anteriormente alterando o valor inicial a um inválido, testando se de fato um ValidationError é retornado.

# tests.py
class FenomenoFormValidatorsTest(TestCase):
 @staticmethod
 def create_form(**kwargs):
 valid_form = {
 'nome': 'Teste',
 'data': '2020-01-01',
 'hora': '09:12:12',
 'longitude': -42,
 'latitude': -21}

 valid_form.update(**kwargs)
 form = FenomenoForm(valid_form)
 return form

Nos métodos de teste uso primeiro o assertFalse do método de validação do formulário (form.is_valid()) para confirmar que o mesmo não é valido para, em seguida, testar com o assertEqual se o texto da mensagem de erro é o que esperamos.

# tests.py
 def test_max_longitude_raises_error(self):
 form = self.create_form(longitude='-45')
 self.assertFalse(form.is_valid())
 self.assertEqual(form.errors["longitude"][0], 'Coordenada longitude fora do contexto do estado do Rio de Janeiro')

 def test_min_longitude_raises_error(self):
 form = self.create_form(longitude='-40')
 self.assertFalse(form.is_valid())
 self.assertEqual(form.errors["longitude"][0], 'Coordenada longitude fora do contexto do estado do Rio de Janeiro')

 def test_max_latitude_raises_error(self):
 form = self.create_form(latitude='-24')
 self.assertFalse(form.is_valid())
 self.assertEqual(form.errors["latitude"][0], 'Coordenada latitude fora do contexto do estado do Rio de Janeiro')

 def test_min_latitude_raises_error(self):
 form = self.create_form(latitude='-19')
 self.assertFalse(form.is_valid())
 self.assertEqual(form.errors["latitude"][0], 'Coordenada latitude fora do contexto do estado do Rio de Janeiro')

Fazemos rodar os testes e teremos erros como esses:

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
...E.E..
======================================================================
ERROR: test_max_latitude (map_proj.core.tests.FenomenoFormValidatorsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/media/felipe/DATA/Repos/Django_Leaflet_Test/map_proj/core/tests.py", line 78, in test_max_latitude
 self.assertEqual(form.errors["latitude"][0], 'Coordenada latitude fora do contexto do estado do Rio de Janeiro')
KeyError: 'latitude'

======================================================================
ERROR: test_min_latitude (map_proj.core.tests.FenomenoFormValidatorsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/media/felipe/DATA/Repos/Django_Leaflet_Test/map_proj/core/tests.py", line 83, in test_min_latitude
 self.assertEqual(form.errors["latitude"][0], 'Coordenada latitude fora do contexto do estado do Rio de Janeiro')
KeyError: 'latitude'

----------------------------------------------------------------------
Ran 8 tests in 0.012s

FAILED (errors=2)
Destroying test database for alias 'default'...

Ou seja, o forms após ser validado deveria conter um atributo errors tendo como chave o nome do campo que apresentou dados inválidos. Como não temos os validadores criados, nenhum erro de validação foi acusado no campo de latitude.

Criando e usando validadores:

Para superá-los criamos, enfim, os validadores em um arquivo validators.py. Percebam que é nesse ponto que usarei os valores máximos e mínimos de latitude e longitude adicionados no settings.py:

# validators.py
from django.core.exceptions import ValidationError
from django.conf import settings


def validate_longitude(lon):
 if lon < settings.BOUNDING_BOX_LON_MIN or lon > settings.BOUNDING_BOX_LON_MAX:
 raise ValidationError("Coordenada longitude fora do contexto do estado do Rio de Janeiro", "erro longitude")

def validate_latitude(lat):
 if lat < settings.BOUNDING_BOX_LAT_MIN or lat > settings.BOUNDING_BOX_LAT_MAX:
 raise ValidationError("Coordenada latitude fora do contexto do estado do Rio de Janeiro", "erro latitude")

Com esses validadores estou garantindo que ambos latitude e longitude estejam na área de interesse e, caso contrário, retorno um erro informando ao usuário.

E é preciso adicioná-los ao forms.py para que sejam usados:

# forms.py
from map_proj.core.validators import validate_longitude, validate_latitude

class FenomenoForm(ModelForm):
 longitude = FloatField(validators=[validate_longitude])
 latitude = FloatField(validators=[validate_latitude])

No desenvolvimento dessa solução percebi pelos testes criados que, ao informar uma latitude ou longitude que não passe pela validação, a criação do campo geom se tornava inválido por não receber um desses valores, gerando dois erros: o de validação do campo e o de validação do campo geom. Lembre-se que é no método clean do formulário que o campo geom recebe os valores de longitude e latitude formando uma classe geojson para, logo em seguida ser validado.

Para evitar isso, alterei o método clean de forma garantir que o campo geom só seja criado e validado, quando ambos valores (longitude e latitude) existirem. Ou seja, tenham passado pelos validadores sem erro.

#forms.py
 def clean(self):
 cleaned_data = super().clean()
 lon = cleaned_data.get('longitude')
 lat = cleaned_data.get('latitude')
 if not all((lon, lat)):
 raise ValidationError('Erro em latitude ou longitude')

 cleaned_data['geom'] = Point((lon, lat))
 if not cleaned_data['geom'].is_valid:
 raise ValidationError('Geometria inválida')

 return cleaned_data

Outro ponto (na verdade, erro) importante que só percebi a partir dos testes é que no forms.py eu não estava considerando o campo geom na lista de fields a serem usados. Com isso o mesmo não é passado ao banco de dados, mesmo passando pelo método clean que o cria.

Por esse motivo, tive que alterar algumas coisas no forms.py:

Inseri o campo geom à tupla de fields do forms.py.
Inseri o campo geom com um widget de HiddenInput. Esse último, o fiz por se tratar de um campo que não quero expor ao usuário, já que será criado automaticamente no método clean.

Finalmente, a classe Meta do forms.py ficou da seguinte forma:

 class Meta:
 model = Fenomeno
 fields = ('nome', 'data', 'hora', 'latitude', 'longitude', 'geom')
 widgets = {'geom': HiddenInput()}

Pronto, com tudo isso que fizemos, já temos um sistema que, apesar de não poder fazer consultas espaciais, é capaz de validar os campos de latitude e longitude.

No próximo artigo, vou abordar sobre o que está por trás de toda mágica de um webmap, usando o módulo django-leaflet. Enquanto isso, dê uma olhada no que tenho desenvolvido.

Criando um sistema para gestão de dados geográficos de forma simples e robusta II.

Fri, 11 Jun 2021 00:00:00 +0000

Artigo publicado também no linkedin.

Há algum tempo comecei a estudar sobre desenvolvimento de sistema com Python, usando a framework Django. Decidi expor alguns aprendizados em uma serie de artigos. A ideia é que esses textos me ajudem na consolidação do conhecimento e, ao tê-los publicado, ajudar a outros que tenham interesse na área.

Aproveito para deixar meu agradecimento ao Cuducos que, tanto neste artigo, como em todos meus estudos tem sido um grande mentor. Vamos ao que interessa:

Por simples, entende-se:

Um sistema sem a necessidade da instalação e configuração de base de dados PostgreSQL/GIS, Geoserver, etc; Um sistema clássico tipo Create, Retrieve, Update, Delete (CRUD) para dados geográficos; Um sistema que não demande operações e consultas espaciais; Mas um sistema que garanta a qualidade na gestão dos dados geográficos;

Visão geral da proposta:

Vamos criar um ambiente virtual Python e instalar a framework Django, para criar o sistema, assim como alguns módulos como jsonfield, que nos vai habilitar a criação de campos JSON em nossa base de dados; django-geojson, que depende do jsonfield e será responsável por habilitar instâncias de dados geográficos, baseando-se em JSON; geojson, que possui todas as regras básicas de validação de dados geográficos, usando a estrutura homônima, geojson.

O uso desses três módulos nos permitirá o desenvolvimento de um sistema de gestão de dados geográficos sem a necessidade de termos instalado um sistema de gerenciamento de dados geográficos, como o PostGIS. Sim, nosso sistema será bem limitado a algumas tarefas. Mas em contrapartida, poderemos desenvolvê-lo e implementar soluções “corriqueiras” de forma facilitada.

No presente exemplo estarei usando SQLite, como base de dados.

Nosso projeto se chamará de map_proj. E nele vou criar uma app, dentro da pasta do meu projeto Django, chamada core. Essa organização e nomenclatura usada, vem das sugestões do Henrique Bastos. Afinal, o sistema está nascendo. Ainda que eu tenha uma ideia do que ele será, é interessante iniciar com uma aplicação “genérica” e a partir do momento que o sistema se torne complexo, poderemos desacoplá-la em diferentes aplicações.

Criando ambiente de desenvolvimento, projeto e nossa app:

python -m venv .djleaflet # cria ambiente virtual python
# ativando o ambiente virtual:
source ./venv/bin/activate

# atualizando o pip
pip install --upgrade pip

# intalando os módulos a serem usados
pip install django jsonfield django-geojson geojson

# criando projeto
django-admin startproject map_proj .

# criando app dentro do projeto
cd map_proj
python manage.py startapp core

# criando a base de dados inicial
python manage.py migrate

# criando superusuário
python manage.py createsuperuser

Adicionando os módulos e a app ao projeto

Agora é adicionar ao map_proj/settings.py, a app criada e os módulos que usaremos.

# setting.py
INSTALLED_APPS = [
 ...
 'djgeojson',
 'map_proj.core',
]

Perceba que para poder acessar as classes de alto nível criadas pelo pacote djgeojson, teremos que adicioná-lo ao INSTALLED_APPS do settings.py.

Criando a base de dados

Ainda que eu concorde com o Henrique Bastos, que a visão de começar os projetos Django pelo models.py é um tanto “perigosa”, por colocar ênfase em uma parte da app e, em muitos casos, negligenciar vários outros atributos e ferramentas que o Django nos oferece, irei desconsiderar sua abordagem. Afinal, o objetivo deste artigo não é explorar todo o potencial do Django, mas sim apresentar uma solução simples no desenvolvimento e implementação de um sistema de gestão de dados geográficos para servir como ferramenta de estudo e projeto prático.

Em models.py usaremos instâncias de alto nível que o Django nos brinda para criar e configurar os campos e as tabelas que teremos em nosso sistema, bem como alguns comportamentos do sistema.

Como estou desenvolvendo um sistema multi propósito, vou tentar mantê-lo bem genérico. A ideia é que vocês possam imaginar o que adequar para um sistema especialista na sua área de interesse. Vou criar, então, uma tabela para mapear “fenômenos” (quaisquer). Esse modelo terá os campos nome, data, hora e geometria, a qual será uma instância de PointField.

O PointField é uma classe criada pelo djgeojson que nos permite usar um campo para dados geográficos sem ter toda a infraestrutura do PostGIS, instalada, por exemplo. Nesse caso, estou simulando um campo de ponto, mas, de acordo com a documentação do pacote, todas as geometrias usadas em dados espaciais são suportadas:

All geometry types are supported and respectively validated : GeometryField, PointField, MultiPointField, LineStringField, MultiLineStringField, PolygonField, MultiPolygonField, GeometryCollectionField. ( djgeojson )

# models.py
from django.db import models
from djgeojson.fields import PointField


class Fenomeno(models.Model):
 nome = models.CharField(max_length=100,
 verbose_name='Fenomeno mapeado')
 data = models.DateField(verbose_name='Data da observação')
 hora = models.TimeField()
 geom = PointField(blank=True)

 def __str__(self):
 return self.nome

Percebam que eu importo de djgeojson a classe PointField. O que o django-geojson fez foi criar uma classe [com estrutura de dados geográfico] de alto nível, mas que no banco de dados será armazenado em um campo JSON. Vale a pena deixar claro: não espero que o usuário do meu sistema saiba preencher o campo geom em formato JSON. Por isso, criarei no forms.py, os campos latitude e longitude e a partir deles, o campo geom será preenchido. Detalharei esse processo mais adiante.

Pronto, já temos o modelo da ‘tabela de dados “geográficos”’, mas esse modelo ainda não foi registrado em nossa base. Para isso:

python manage.py makemigrations
python manage.py migrate

O makemigrations analisa o models.py e o compara com a versão anterior identificando as alterações e criando um arquivo que será executado pelo migrate, aplicando tais alterações ao banco de dados. Aprendi com o Henrique Bastos e Cuducos que o migrate é um sistema de versionamento da estrutura do banco de dados, permitindo retroceder, quando necessário, a outras versões.

Criando o formulário

Vou aproveitar algumas “pilhas já incluídas” do Django, ao usar o ModelForm para criar o formulário para o carregamento de dados. O ModelForm facilita esse processo.

Aliás, é importante pensar que os formulários do Django vão muito além da “carga de dados”, já que são os responsáveis por cuidar da interação com o usuário e o(s) processo(s) de validação e limpeza dos dados preenchidos.

Digo isso, pois ao meu FenomenosForm, eu sobreescrevo o método clean(), que cuida da validação e limpeza do formulário e incluo nele:

a construção dos dados do campo geom a partir dos valores dos campos de latitude e longitude (criados exclusivamente para a gerção do campo geom);
a validação do campo geom;

# forms.py
from django.core.exceptions import ValidationError
from django.forms import ModelForm, FloatField
from map_proj.core.models import Fenomeno
from geojson import Point


class FenomenoForm(ModelForm):
 longitude = FloatField()
 latitude = FloatField()
 class Meta:
 model = Fenomeno
 fields = ('nome', 'data', 'hora', 'latitude', 'longitude')

 def clean(self):
 cleaned_data = super().clean()
 lon = cleaned_data.get('longitude')
 lat = cleaned_data.get('latitude')
 cleaned_data['geom'] = Point((lon, lat))

 if not cleaned_data['geom'].is_valid:
 raise ValidationError('Geometria inválida')
 return cleaned_data

Ainda que pareça simples, não foi fácil chegar a essa estratégia de estruturação dos models e forms. Contei com a ajuda e paciencia do Cuducos. Inicialmente eu mantinha latitude e longitude no meu models. Mas fazendo assim, além de ter uma redundância de dados e uma abertura a erros potenciais, estaria armazenando dados que não devo usar depois de contruir o campo geom. Uma alternativa, discutida com o Cuducos foi de ter tanto latitude como longitude no models, mas o atributo geom como propriedade. Ainda que seja uma estratégia consistente, a redundância se mantém.

O processo de validação do campo geom também foi fruto de muita discussão. De forma resumida, percebi que o djgeojson apenas valida o tipo de geometria do campo e não a sua consistência. Ao conversar com os desenvolvedores, me disseram que toda a lógica de validação de objetos geojson estavam sendo centralizados no módulo homônimo.

Por isso eu carrego a classe Point do módulo geojson e designo o campo geom como instância dessa classe. Assim, passo a poder contar com um processo de validação mais consistente, como o método is_valid, usado anteriormente.

Mas e o teste?

Pois é, eu adoraria apresentar isso usando a abordagem Test Driven Development (TDD). Mas, talvez pela falta de prática, conhecimento e etc, vou apenas apontar onde e como eu testaria esse sistema. Faço isso como uma forma de estudo, mesmo. Também me pareceu complicado apresentar a abordagem TDD em um artigo, já que a mesma se faz de forma incremental.

Sobre TDD

Com o Henrique Bastos e toda a comunidade do Welcome to The Django vi que essa abordagem é tanto filosófica quanto técnica. É praticamente “Chora agora, ri depois”, mas sem a parte de chorar. Pois com o tempo as coisas ficam mais claras… Alguns pontos:

O erro não é para ser evitado no processo de desenvolvimento, mas sim quando estive em produção. Logo,
Entenda o que você quer do sistema, crie um teste antes de implementar e deixe o erro te guiar até ter o que deseja;
Teste o comportamento esperado e não cada elemento do sistema;

Sem mais delongas:

O que testar?

Vamos usar o arquivo tests.py e criar nossos testes lá. Ao abrir vocês vão ver que já está o comando importando o TestCase.

Mas o que vamos testar?

Como pretendo testar tanto a estrutura da minha base de dados, quanto o formulário e, de quebra, a validação do meu campo geom, faço o import do modelo Fenomenos e do form FenomenosForm.

⚠️ Essa não é uma boa prática. O ideal é criar uma pasta para os testes e separá-los em arquivos distintos. Um para cada elemento do sistema (model, form, view, etc).

O primeiro teste será a carga de dados. Então, vou instanciar um objeto com o resultado da criação de um elemento do meu model Fenomeno. Faço isso no setUp, para não ter que criá-lo sempre que for fazer um teste relacionado à carga de dados.

O teste seguinte será relacionado ao formulário e por isso instancio um formulário com os dados carregados e testo a sua validez. Ao fazer isso o formulário passa pelo processo de limpeza, onde está a construção e validação do campo geom. Se qualquer campo for preenchido com dados errados ou inadequados, o django retornará False ao método is_valid. Ou seja, se eu tiver construido o campo geom de forma equivocada, passando mais ou menos parâmetros que o esperado o nosso teste irá avisar, evitando surpresas.

# tests.py
from django.test import TestCase
from geojson import Point

from map_proj.core.models import Fenomeno
from map_proj.core.forms import FenomenoForm


class ModelGeomTest(TestCase):
 def setUp(self):
 self.fenomeno = Fenomeno.objects.create(
 nome='Arvore',
 data='2020-11-06',
 hora='09:30:00'
 )

 def test_create(self):
 self.assertTrue(Fenomeno.objects.exists())


class FenomenoFormTest(TestCase):
 def setUp(self):
 self.form = FenomenoForm({
 'nome': 'Teste',
 'data': '2020-01-01',
 'hora': '09:12:12',
 'longitude': -45,
 'latitude': -22})
 self.validation = self.form.is_valid()

 def test_form_is_valid(self):
 """"form must be valid"""
 self.assertTrue(self.validation)

 def test_geom_coordinates(self):
 """after validating, geom have same values of longitude and latitude"""
 self.assertEqual(self.form.cleaned_data['geom'], Point(
 (self.form.cleaned_data['longitude'],
 self.form.cleaned_data['latitude'])))

 def test_geom_is_valid(self):
 """geom must be valid"""
 self.assertTrue(self.form.cleaned_data['geom'].is_valid)

⚠️ Reparem que:

No test_create() eu testo se existem objetos inseridos no model Fenomeno. Logo, testo se o dado criado no setUp foi corretamente incorporado no banco de dados.
Na classe FenomenosFormTest eu crio uma instância do meu modelForm e realizo três testes:
- test_form_is_valid() estou testando se os dados carregados são condizentes com o informado no model e, pelo fato desse método usar o método clean(), posso dizer que estou testando indiretamente a validez do campo geom. Caso ele não fosse válido, o form também não seria válido.
- Em test_geom_coordinates() testo se após a validação o campo geom foi criado como esperado (como uma instância de Point com os dalores de longitude e latitude).
- O teste test_geom_is_valid() serve para garantir que a contrução do campo geom é valido. Ainda que ao testar se o formulário é valido eu estaria implicitamente testando a validez do campo geom, esse teste serve para garantir a criação válida do campo. Afinal, por algum motivo (como por exemplo, refatoração), pode ser que façamos alguma alteração no método clean() que mantenha o formulário como válido mas deixe de garantir a validez do campo geom.

A diferença entre as classes de teste criadas está no fato de ao inserir os dados usando o método create() - e aconteceria o mesmo se estivesse usando o save() -, apenas será validado se o elemento a ser inserido é condizente com o tipo de coluna no banco de dados. Vale deixar claro: Dessa forma, eu não estou validando a consistência do campo geom, já que o mesmo, caso seja informado, será salvo com sucesso sempre que represente um JSON.

Esse fato é importante para reforçar o entendimento de que o djgeojson implementa classes de alto nível a serem trabalhados em views e models. No banco, mesmo, temos um campo de JSON. Enquanto que, para poder validar a consistência do campo geom, preciso passar os dados pelo formulário onde, no processo de limpeza do mesmo, o campo será criado e validado usando o módulo geojson. Por isso a classe com os testes relacionados ao comportamento do formulário.

Registrando modelo no admin

Para facilitar, vou usar o django-admin. Trata-se de uma aplicação já criada onde basta registrar os modelos e views que estamos trabalhando para termos uma interface “frontend” genérica.

#admin.py
from django.contrib import admin
from map_proj.core.models import Fenomeno
from map_proj.core.forms import FenomenoForm

class FenomenoAdmin(admin.ModelAdmin):
 model = Fenomeno
 form = FenomenoForm

admin.site.register(Fenomeno, FenomenoAdmin)

To be continued…

Até o momento já temos algo bastante interessante: um sistema de CRUD que nos permite adicionar, editar e remover dados geográficos. Talvez você esteja pensando consigo mesmo:

“OK. Mas o que foi feito até agora, poderia ter sido feito basicamente com uma base de dados que possuam as colunas latitude e longitude”.

Eu diria que sim, até certo ponto. Uma grande diferença, eu diria, da forma como foi implementada é o uso das ferramentas de validação dos dados com o módulo geojson.

A ideia é, a seguir (e seja lá quando isso for), extender a funcionalidade do sistema ao implementar um webmap para visualizar os dados mapeados.

Hacktoberfest: Colaborações e aprendizados.

Fri, 21 May 2021 00:00:00 +0000

Artigo publicado também no linkedin.

O HacktoberFest é um evento promovido pela Digital Ocean durante o mês de outubro e já está na sua oitava edição. O objetivo é incentivar a colaboração em projetos de código aberto e, claro, como uma forma de democratizar o conhecimento em sistemas de versionamento, como o git, além de outras tecnologias.

…Ah, e o incentivo vem com a possibilidade de ganhar uma camisa do evento ao ter aprovado quatro pull requests em repositórios participantes (para participar, basta adicionar a tag “Hactoberfest” ao repositório ou adicionar a tag “Hacktoberfest-accepted” no Pull request em questão).

Não foi minha primeira participação, mas foi a primeira vez que pude colaborar em projetos diferentes daqueles relacionados ao meu trabalho cotidiano. E já fazia algum tempo que tinha interesse em colaborar, mas não sabia como quebrar a inércia. Compartilho neste artigo, alguns projetos desenvolvidos este ano e o que pude aprender nos mesmos.

Fogo Cruzado

O projeto Fogo Cruzado foi desenvolvido pela Volt Data Lab e Instituto Fogo Cruzado, como um sistema Crowdsourcing para monitoramento dos tiroteios no Rio de Janeiro e/ou em Recife. O mesmo disponibiliza uma API para acessar aos dados, bastando criar um usuário, sem custo. E o projeto já tem um pacote para acessar os dados pelo R.

Como faltava um módulo python para acessar os dados do projeto, decidi fazê-lo durante o #Hacktoberfest. Esse foi o primeiro projeto: um módulo python para acessar os dados da API, direto do python.

Foi um desafio legal e, até certa forma, simples, pois eu já tinha um modelo de como funcionava o pacote em R. Então o trabalho foi, principalmente “traduzir” ao python. Com isso aproveitei para refatorar algumas partes do código.

No geral, posso dizer que ao desenvolver esse projeto, aprendi sobre:

Python-poetry (do zero);
Validação de login usando variáveis do sistema;
Publicação de módulos no PyPi;

E fica como desafios para melhor/implementar em breve:

Melhorar o código com type annotation;
Criação de documentação com Sphynx (se alguém quiser sugerir outra alternativa será bem-vinda);

PyInaturalist-convert

O segundo projeto que atuei nesse mês foi no PyInaturalist-convert. A história deste módulo é bem interessante e surge de uma demanda pessoal: O IMiBio, Instituição onde trabalho, está desenvolvendo um projeto com o INaturalist, uma aplicação de crowdsourcing para observação de biodiversidade, e eu tive que criar um sistema que acesse os dados do projeto usando a API deles. Com isso, conheci o módulo PyINaturalist. Conversando com os desenvolvedores, comentei que seria interessante ter os dados no padrão darwincore. Um deles achou pertinente e começamos a desenvolver juntos. Contudo, fiquei uns bons meses afastado do projeto e ao voltar, já era um pacote bem estruturado. Por isso, para entender a estrutura do mesmo e saber por onde começar, além de ler as issues abertas, adotei a estratégia de ler os testes…

… E foi lendo os testes que percebi que estavam implementando um objeto geojson, “na unha”. Como estive estudando sobre o geojson (e, inclusive foi um dos temas explorados por mim em outros artigos, propus usá-lo. Com isso, poderíamos usar os métodos de validação já implementados no módulo, garantindo consistência aos dados;

Ao colaborar no módulo PyInaturalist-converter, aprendi sobre:

Como colaborar a um projeto já estruturado. Tenho certeza que essa não é uma regra. Mas foi uma boa estratégia começar lendo os testes;
Mais aprendizados sobre python-poetry :);
Soube da existência do formatador de código Black;
Soube da existencia do ISORT, para padronizar os imports;

Além desses aprendizados, o autor principal do módulo já tinha configurado no repositório um fluxo de ações e validações bem interessantes. Dessa forma, havia um sistema de validação do que se estava propondo como pull request. Ainda não tive tempo de me aprofundar, mas já está na lista de estudos futuros…

Análise espacial no frontend

Uma última atividade que queria compartilhar, não está relacionada a uma contribuição minha, mas sim, um projeto ao qual eu recebi ajuda.

Publiquei recentemente um artigo apresentando alguns módulos de JavaScript que nos permitem fazer algumas análises espaciais sem depender de uma infraestrutura de servidores de dados e de mapas.

Eu fui apresentado a essas tecnologias no FOSS4G 2021 e por pura curiosidade, já que frontend não é a “minha praia”, comecei a fazer alguns testes como estratégia de estudos, mesmo.

Pude evoluir bastante com os estudos, mas num momento vi que poderia ser feito muito mais, mas que eu não tinha conhecimento técnico em JS para isso. Não tive dúvidas em contactar um amigo que trabalha com JS e apresentei a ele o que estava tentando fazer. Ele curtiu e acabou colaborando com o projeto, transformando essa prova de conceito numa solução, em algo realmente interessante.

Percebam que essa colaboração não surgiu pelo Hacktoberfest. Mas por uma mudança de postura minha em me conectar com outras pessoas e apresentar o que eu estava estudando, as “minhas dores” e o que pretendia fazer.

Neste projeto estudei e aprendi sobre:

O georaster, uma biblioteca JavaScript que nos permite carrregar, e até mesmo criar, dados raster a partir de objetos JavaScript;
georaster-layer-for-leaflet que é uma biblioteca que nos permite apresentar dados raster (a princípio geotif) nos mapas feitos em leaflet;
geoblaze que é um pacote desenvolvido em JavaScript para permitir analisar dados carregados como georaster.

Como resultado, criamos dois visualizadores de dados raster apenas com tecnologia frontend. No primeiro o usuário interage com o pixel (clicando num píxel específico) e o gráfico apresenta o comportamento temporal daquele pixel; No segundo visualizador o usuário clica em um dos estados e o gráfico apresenta o valor médio dos pixels daquele estado ao longo do tempo.

Notas finais sobre Hacktoberfest

Entendo que muitos “torcem o nariz” para o Hacktoberfest, pois poucos o utilizam como uma estratégia de estudos, crescimento ou colaboração a projeto de código aberto, que são os objetivos principais. A ideia de escrever sobre as colaborações feitas é justamente destacar que o evento é uma grande estratégia/ferramenta para aprender mais, conectar-se com outros desenvolvedores e se engajar em projetos de código aberto.

Espero que os meus aprendizados serviam de motivação aos demais. Qualquer coisa, fico à disposição para conversar mais a respeito.

Python |

Struggling to Download Sentinel-2 Level 1C `.SAFE` Files with Python and AWS CLI

TL;DR

Attempt 1: Using the sentinelhub Python library

Attempt 2: Using STAC from Copernicus Dataspace

Lessons Learned during the developtmen of `corssfire` Python package

Debuging in test

TDD is about exploring issues rather than a solution

Flat path to success

Instalando versão pacote Python a partir do GitHub

CROSSFIRE PYTHON CLIENT

SAILING ANALYSIS

DOMESTIC ECONOMY CHATBOT

Combinando Duas Paixões: Análise de Dados e Velejar.

Aprendendo sobre datetime, SQLAlchemy e PostgreSQL a partir de bugs

Contextualizando o sistema

Reproduzindo comportamentos estranhos

Resolvendo problema de definição de time zone

Resolvendo problema de definição de time zone com timedelta

O mistério das consultas sendo retornadas em UTC e -0300

Confirmando o fuso horário da instância do banco de dados

coluna naive e aware

Primeiro teste:

Segundo teste:

Preparando ambiente de desenvolvimento

Docker com PostgreSQL

Modelo de dados e conexão com SQLAlchemy

Identificando time zone das instâncias de trabalho

Docker PostgreSQL

python

Resumindo

Criando um sistema para gestão de dados geográficos de forma simples e robusta III.

View GeoJSONLayerView

Criando os testes da view

Adicionando propriedade para popup

Adicionando um path a view

Django-leaflet

Instalando django-leaflet

Usando o leaflet

Renderizando o geojson no mapa

Mudando o tamanho do webmap:

Configurações do leaflet

Bug buster

Como tudo começou:

Um pouco do contexto:

E agora? Por onde começar?

Interseção terminal/python

No banco de dados…

Reproduzindo o erro em JSON

Enfim, a solução:

Atualização

Criando um sistema para gestão de dados geográficos de forma simples e robusta II.

Criando validadores de longitude e latitude

Sobre os validadores:

Criando os testes:

Criando e usando validadores:

Criando um sistema para gestão de dados geográficos de forma simples e robusta II.

Visão geral da proposta:

Criando ambiente de desenvolvimento, projeto e nossa app:

Adicionando os módulos e a app ao projeto

Criando a base de dados

Criando o formulário

Mas e o teste?

Sobre TDD

O que testar?

Registrando modelo no admin

To be continued…

Hacktoberfest: Colaborações e aprendizados.

Fogo Cruzado

E fica como desafios para melhor/implementar em breve:

PyInaturalist-convert

Análise espacial no frontend

Notas finais sobre Hacktoberfest

Resolvendo problema de definição de time zone com `timedelta`

Criando os testes da `view`

Instalando `django-leaflet`

Renderizando o `geojson` no mapa

Reproduzindo o erro em `JSON`