Este projeto, desenvolvido pelo grupo IEEE-CIS, tem como objetivo a predição de valores de venda e de aluguel de imóveis. Através da coleta de dados de diversos sites de imóveis, criamos um pipeline automatizado que organiza, processa e armazena esses dados para análise e modelagem preditiva.
A ideia central é utilizar técnicas de machine learning em dados de imóveis para oferecer estimativas mais precisas de preços de mercado.
├── database
│ ├── config.py # Configurações de conexão com o MongoDB
│ ├── connection.py # Classe para gerenciar a conexão com o MongoDB
│ ├── repository.py # Funções para manipulação de dados de imóveis (CRUD)
├── docs
│ ├── Project_documentation.docx # Documentação do projeto em formato Word
│ └── Project_documentation.pdf # Documentação do projeto em formato PDF
├── pipeline
│ ├── data_cleaning.py # Responsável por realizar o tratamento dos dados coletados
│ ├── data_scraping.py # Orquestra a execução dos scrapers
│ ├── data_transform.py # Responsável pela transformação e normalização dos dados
│ └── main.py # Gerencia a interação com o banco de dados
├── scripts
│ ├── df-imoveis # Scripts de scraping para o site 'df-imoveis'
│ ├── net-imoveis # Scripts de scraping para o site 'net-imoveis'
│ ├── quinta-andar # Scripts de scraping para o site 'quinta-andar'
│ ├── viva-real # Scripts de scraping para o site 'viva-real'
│ ├── w-imoveis # Scripts de scraping para o site 'w-imoveis'
│ ├── zap-imoveis # Scripts de scraping para o site 'zap-imoveis'
├── utils
│ └── data_handler.py # Classe para manipulação e salvamento de dados- Suporte para múltiplos sites de imóveis: DF-Imóveis, Net-Imóveis, Quinto Andar, Viva Real, W-Imóveis e Zap-Imóveis
- Coleta automatizada de dados de imóveis com suporte para diferentes tipos de contratos (venda/aluguel)
- Suporte para diferentes tipos de propriedades: apartamentos, casas, flats, etc.
- Limpeza e normalização de dados de imóveis
- Geocodificação de endereços para obtenção de coordenadas geográficas
- Suporte para múltiplos serviços de geocodificação:
- Nominatim (serviço gratuito, padrão)
- Google Maps API (requer chave de API)
- Salvamento incremental de dados (modo append)
- Suporte para formatos Excel e CSV
- Processamento em lotes com salvamento automático para evitar perda de dados
- Tratamento robusto para arquivos corrompidos com funcionalidade de backup
git clone <URL-do-repositório>
cd <nome-do-repositório>Crie um arquivo .env a partir do .env.example.
cp .env.example .envEntão, preencha o arquivo .env com as devidas variáveis de ambiente do projeto:
MONGODB_URI: URI de conexão com o MongoDBGOOGLE_MAPS_API_KEY: Chave de API do Google Maps (opcional, para geocodificação)
docker-compose up -dTodas as dependências de pacotes Python necessários para o projeto estão listadas no arquivo requirements.txt para usuários que optem por não usar o docker. Para instalar os pacotes, siga os seguintes passos:
Certifique-se de estar no diretório raiz do projeto.
Execute o comando abaixo para instalar as dependências:
pip install -r requirements.txtVerifique o python PATH local e execute o arquivo desejado.
Branch principal do repositório e representa o ambiente de produção do projeto.
Ao criar a nova branch, procure trazer significado a ela desde a sua nomeação, e aqui seguem algumas boas práticas:
Coloque um prefixo na branch, a fim de esclarecer sua intenção. Alguns exemplos abaixo:
feat/: implementação de uma nova funcionalidade do software;fix/: implementação de uma correção no software;docs/: documentação de parte ou trecho do software;refactor/: refatoração de parte ou trecho do software.
Após o prefixo, coloque um nome declarativo ou explicativo do objetivo da branch, ou seja, um nome que diga o que será implementado na branch. Procure escrever na convenção "kebab-case".
Após o nome, adicione um sufixo numérico, explicitando qual a issue do projeto a que se refere a nova branch.
feat/data-scraping-21fix/data_transformation-bug-13refactor/api-fetch-refactor-4
É necessário tomar algumas atenções quanto às issues do GitHub.
Focando-se na boa prática de integração contínua, faz-se necessário particionar pendências e novas funcionalidades o máximo possível, enquanto houver sentido, afim de se criar issues com menores responsabilidades, promovendo branchs menores, PRs menores, merges mais frequentes e um código-fonte com atualizações constantes.