Este proyecto pretende automatizar la búsqueda de la mejor ubicación posible para una recién fundada empresa según las necesidades de los trabajadores.
La idea básica de este proyecto es poder encontrar una ubicación que satisfaga las demandas de todos los miembros de la empresa. La meta es devolver unas coordenadas, o un grupo de coordenadas, en cuyas inmediaciones se encuentren todas las comodidades y recursos que la ciudad ofrece a nuestros empleados.
La estructura de la empresa es la siguiente:
- 20 Designers
- 5 UI/UX Engineers
- 10 Frontend Developers
- 15 Data Engineers
- 5 Backend Developers
- 20 Account Managers
- 1 Maintenance guy
- 10 Executives
- 1 CEO/President
Las peticiones eran estas:
- Designers like to go to design talks and share knowledge. There must be some nearby companies that also do design.
- 30% of the company staff have at least 1 child.
- Developers like to be near successful tech startups that have raised at least 1 Million dollars.
- Executives like Starbucks A LOT. Ensure there's a starbucks not too far.
- Account managers need to travel a lot.
- Everyone in the company is between 25 and 40, give them some place to go party.
- The CEO is vegan.
- If you want to make the maintenance guy happy, a basketball stadium must be around 10 Km.
- The office dog—"Dobby" needs a hairdresser every month. Ensure there's one not too far away.
- Priorización de peticiones
- Elección de ciudad
- Creación de base de datos
- Filtrado de peticiones
- Creación de csv
- Visualización oficina
Lo primero era saber como valoraremos en la empresa las distintas peticiones, para jerarquizarlas y encontrar un orden de búsqueda posteriormente. La decisión que se tomó fue que se valorarían en relación al coste que genereba a la empresa las personas que hacían las peticiones, cuanto más se hubiese invertido en contratar a esas personas, más importancia tendría la petición. Para ello se realizó un diccionario con la estructura antes mencionada pero añadiendo los valores de sueldo medio (valor que recogimos de buscar en google el sueldo medio de cada puesto), coste empresa, petición y peso de la petición dado que la gran mayoría de peticiones venían de departamentos concretos.
Se valorarían las peticiones del uno al diez, entendiendo 10 como el coste empresa del departamento más caro. Se calculó el peso de cada petición por departamento y se hizo una tabla de peticiones y su valor, a la que se le añadirían las peticiones no relacionadas directamente con departamentos. Una vez tuvimos las peticiones y su fuerza, se ordenó de mayor a menor peso, ya teníamos un orden de prioridades.
Tuvimos claro desde el principio que los criterios para la selección de ciudad tenían que ser aquellos elementos de la lista de prioridades que fuesen más anómalos. Cafeterías, aeropuertos, y peluquerías caninas íbamos a encontrar en todas las ciudades medianamente grandes donde buscásemos, pero empresas tecnológicas con áreas de diseño y que tuviesen unas ganancias superiores a un millón de dólares iba a ser más complicado.
Para ello, tuvimos la suerte de contar con la colección 'companies' que nos permitió filtrar en Mongo DB. Tras algunas modificaciones con las funciones de tratamiento de datos conseguimos una lista de todas las ciudades que cumplían con la espectativa de tener una empresa tecnológica con área de diseño y más de un millón de dólares de ganancia. Lista que fue para nuestra sorpresa especialmente extensa.
Como seguiamos teniendo una lista con 745 posibles ciudades decidimos filtrar aún más, así que nos scrapeamos de esta página una tabla con el coste de vida de las principales ciudades del mundo. Sabíamos que la tabla usaba como referencia la ciudad de NY, así que buscamos aquí el coste en dolares de la vida en NY y pasamos a dólares los índices porcentuales de la tabla scrapeda. Seleccionamos de esta tabla todas las ciudades cuyo coste anual no fuese inaccesible para nuestros trabajadores teniendo en cuenta el sueldo que les pagamos. Cruzamos la tabla de ciudades obtenidas mediante la colección 'companies' y la de ciudades viables que acababamos de obtener y conseguimos una nueva lista con 122 posibles ciudades.
Decidimos seguir discriminando y lo que se nos ocurrió fue valorar la calidad de vida de esas 122 ciudades. Scrapeamos una tabla con las ciudades con mayor calidad de vida del mundo en este enlace y volvimos a cruzar resultados. Esta vez teníamos una lista con 18 resultados y 3 de ellos se encontraban en la Península Ibérica: Madrid, Barcelona o Lisboa. La decisión fue Madrid.
Una vez seleccionada la ciudad decidimos hacernos distintas colecciones de los requisitos exigidos. Para ello usamos la API de Four Square que nos devolvía la localización en coordenadas de las distintas peticiones que le hiciesemos atendiendo a que estuviesen en Madrid. Así pudimos hacernos con una base de datos de todos los sitios de interés de nuestra lista. '''
- Colegios.
- Bares y centros de ocio.
- Starbucks.
- Estaciones de tren, intercambiadores de autobuses y aeropuertos.
- Peluquerías caninas y veterinarios '''
Con la ciudad decidida, una base de datos creada con todas los sitios de interés que pudimos recabar de la API, decidimos crear una función que hiciese una geoquery a nuestra base de datos y almacenase las distintas combinaciones de coordenadas con resultados positivos y descartase el resto, además nos devolvía una lista de coordenadas medias, que triangulaban la posición y servían para realizar la siguiente query con el siguiente requisito. Una vez hechas las queries de todas las peticiones de la lista teníamos una lista con todas las coordenadas que había en Madrid que cumplían con todos los requisitos propuestos.
Para poder hacer una visualización de los alrededores de nuestra 'nueva oficina' creamos un documento json mediante la API de Four Square, pidiéndole que nos devolviese todas las coincidencias de nuestra lista de prioridades desde las coordenadas de nuestra oficina a 500 m a la redonda. Con ese documento hicimos un DataFrame y ese DataFrame lo exportamos a csv
Mediante la tecnología de código abierto Kepler.gl usamos nuestro csv para cargar los datos y configuramos nuestro mapa para que representase cada tipo de petición en un color distinto representado con barras hexagonales. El resultado fue el siguiente.
Para este proyecto se han usado estas librerías y módulos.
- sys
- itertools, zip_longest
- pandas
- numpy
- requests
- BeautifulSoup
- pymongo
- json
- dotenv
- os
- functools
- operator
- geopandas
- keplergl
Distinto programas y utilidades usados en este proyecto:
- Jupyter Notebook
- Python: Version 3.8
- Visual Studio Code
- plotly
- BeautifulSoap
- MongoDBCompass
- API Four Square
- Kepler.gl
A mi profes (porque si no fuese por ellos no sabría ni abrir un Jupyter):
A mis ángeles de la guarda, aunque en Ironhack los llamen TA (por estar siempre ahí, por hacer más de lo que su trabajo les obliga, por cuidarnos, ayudarnos y entendernos a cada uno de manera distinta, pero a todos igual de bien. Por ayudarme a superarme desde hace un mes, aunque parece un año):
Y a mis compañeros de clase por aguantar mis preguntas tontas, mis preguntas pesadas, mis caras raras en el zoom, mis pintas de 'me acabo de despertar', por todo el apoyo, consejo, ayuda y risas.
ADVERTENCIA:
Imaginaos el discurso si gano un Oscar 😱😱😱
(Pero es que en una guía muy molona ponía que fuesemos agradecidos)