[un/loquer] Agentes de calidad del aire

Jue Abr 13 07:26:39 UTC 2017

mucho mejor!
yo sigo en python haciendo lo que hablamos arriba. en este momento estoy
trabajando en sanar lo datos "INVALID" como sugería brol.
Tengo dos preguntas:
- la velocidad del sensor es en metros por segundo?
- a cuanto equivale un metro en latitud y en longitud? (esta seguro está en
google)

El 12 de abril de 2017, 23:32, federico lopez <fede2001 at gmail.com> escribió:

> Aún sin implementar las buenas ideas que se han planteado en este hilo hoy
> se hizo (brolin) esta versión del mapa con puntos graduados que empieza a
> ser más útil que el mapa de calor, ahí ya se pueden consultar medidas en
> horarios (y días) diferentes.
>
> http://www.daquina.io/vizAirePuntosGraduados/
>
>
>
> 2017-04-10 17:03 GMT-05:00 daniel gomez <danielgomezmarin at gmail.com>:
>
>> Hola
>>
>> Inicialmente será de archivos planos y filtramos al cargarlos y ojalá
>> después que sea una especie de api a la que se le hagan consultas.
>>
>> Ya está leyendo desde la web.
>> desde la dirección que me dió @fede:
>> https://raw.githubusercontent.com/daquina-io/visualizacionCa
>> lidadAire/master/data/points.csv
>>
>> estoy atento a que consolidemos un wishlist para irle trabajando.
>>
>> Por el momento estoy saltándome los datos "INVALID". Pero ya @brol nos
>> mostró como podemos hacer la calibración de la velocidad con el course:
>>
>> El dato course es el ángulo (0 < course < 360) respecto al norte.
>> Y con la velocidad y el tiempo del último punto se puede hacer una
>> aproximación a la siguiente posición: x = v*t
>>
>> hoy le estuve pensando y hay algo:
>> el primer dato por ejemplo es "INVALID" entonces no se puede sanar el
>> dataset de atrás hacia adelante.
>> de hecho los primeros datos son INVALID.
>> en ese caso deberíamos buscar el primer dato que no sea INVALID.
>> Una vez lo encontremos nos vamos devolviendo "sanando" el dataset hasta
>> llegar a la primera medición.
>> y apenas tengamos esos primeros corregidos nos vamos sanando los datos
>> hacia adelante.
>>
>> también atentos a lo que diga @eliette sobre el sensor. para depurar esa
>> medida.
>>
>> pego el "mapa" que hace en este momento
>> :D
>>
>> El 10 de abril de 2017, 22:59, brolin <brolin108 at gmail.com> escribió:
>>
>>> Ey, una nota que estén animados con esto. Poco a poco lo iremos afinando
>>> :D
>>>
>>> *Respondiendo a los approach para analizar los datos:*
>>>
>>> Yo creo que inicialmente debemos trabajar en disponer los datos de modo
>>> tal como dice @dani:
>>>
>>> - día del calendario (osea día por año,mes,día)
>>> - día de la semana (agrupar todos los lunes, los martes y así) para
>>> poder comparar los fines de semana con los demás días.
>>> - horas, para poder ver los momentos del día más críticos
>>> - recorrido de un usuario
>>> - todos los datos alrededor de un punto
>>>
>>> Inicialmente será de archivos planos y filtramos al cargarlos y ojalá
>>> después que sea una especie de api a la que se le hagan consultas.
>>>
>>> E independizar el análisis de la consulta de los datos. Yo creo que cada
>>> registro cuenta así contenga valores inválidos para algunos campos.
>>>
>>> Lo que guardamos realmente son recorridos entonces están íntimamente
>>> relacionados con el tiempo. El mapa de calor que hicimos no es la mejor
>>> forma para representar esto.
>>>
>>> El análisis del proyecto en python y lo que propone elitte con la
>>> normalización en el tiempo, supone análisis por área territorial. Una
>>> especie de binning maps
>>> <https://duckduckgo.com/?q=binning+maps&t=vivaldi&iax=1&ia=images> e
>>> incluso creo que faltaría
>>> normalizar por el área territorial ¿de qué tamaño debería ser esta área?
>>>
>>> @Eliette, cuándo decís medir el volumen de aire es medir el flujo de
>>> aíre que entra cada vez? cuándo voy a menos velocidad entra menos que
>>> cuándo voy más rápido?, el razonamiento va por ahí?
>>> esta es la información que hay del sensor http://www.sharp-world.
>>> com/products/device/lineup/data/pdf/datasheet/gp2y1010au_appl_e.pdf
>>>
>>> De pronto de alguna manera mecánica sea posible que el sensor "chupe" el
>>> aíre de la muestra que va a leer y llene su cavidad con aproximadamente el
>>> mismo volumen, no se.
>>>
>>> Otra posibilidad, es analizar los datos con modelos basados en agentes.
>>> No se mucho del tema pero lo bueno es que vamos a tener datos para hacer
>>> experimentos.
>>> Hay unos frameworks en python o en netlogo y teoría que se puede
>>> revisar. Los enlaces que pego son lo primero que encontré al buscar por la
>>> palabra "agent based model"
>>>
>>> https://www.amazon.com/Agent-Based-Models-Quantitative-Appli
>>> cations-Sciences
>>> https://www.youtube.com/watch?v=bjjoHji8KUQ
>>> http://mesa.readthedocs.io/en/latest/
>>>
>>> Esta semana le voy a trabajar a tener una especie de api donde enviar y
>>> recuperar los datos.
>>>
>>> Saludos
>>> -
>>> b
>>>
>>>
>>> 2017-04-08 22:59 GMT-05:00 brolin <brolin108 at gmail.com>:
>>>
>>>> Así se ven los datos como flechas giradas según el course
>>>>
>>>> 
>>>>
>>>> 2017-04-08 22:56 GMT-05:00 brolin <brolin108 at gmail.com>:
>>>>
>>>>> *Respondiendo a cómo predecir la próxima posición*: El dato course es
>>>>> el ángulo (0 < course < 360) respecto al norte. Y con la velocidad y el
>>>>> tiempo del último punto se puede hacer una aproximación a la siguiente
>>>>> posición: x = v*t
>>>>>
>>>>> Esto yo no lo haría en el microcontroladorm si no en el servidor
>>>>> cuando se envían los datos.
>>>>>
>>>>> 2017-04-06 2:30 GMT-05:00 daniel gomez <danielgomezmarin at gmail.com>:
>>>>>
>>>>>>
>>>>>>>
>>>>>> Creo que la señal del gps es muy sensible y ante árboles o techos se
>>>>>> pierde, yo si tomo datos de las otras variables pero no se pueden ver en el
>>>>>> mapa porque los datos gps son inválidos. La rutina puede ser almacenar en
>>>>>> un buffer la última coordenada válida  y con el course y la velocidad
>>>>>> calcular la próxima coordenada si el dato es inválido.
>>>>>>
>>>>>>
>>>>>> Si. Esta me parece mucho mejor. Cómo es el course? La última del gps
>>>>>> con mezclada con los acelerómetros o las dos últimas del gps?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pues yo creo que es una combinación de todas, debería ser posible:
>>>>>>
>>>>>> - Descargarlos a un celular o un compu conectándose a una red que
>>>>>> cree el esp (si tiene wifi)
>>>>>> - Si tiene conexión a internet que envíe los datos a un servidor
>>>>>> - Que avise si la memoria se está llenando con un led parpadeando
>>>>>> - Partir los datos por días u otra manera mejor a evaluar
>>>>>> - Otras que se nos ocurran
>>>>>>
>>>>>>>
>>>>>> Todo suena muy bien.
>>>>>> Yo no se nada de conectividad con redes en cpp y poco de cpp :P. Pero
>>>>>> puedo apoyarte por televideo si vas a hacer una sentada próximamente.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> unloquer mailing list
>>>>>> unloquer at lists.aktivix.org
>>>>>> https://lists.aktivix.org/mailman/listinfo/unloquer
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> unloquer mailing list
>>> unloquer at lists.aktivix.org
>>> https://lists.aktivix.org/mailman/listinfo/unloquer
>>>
>>>
>>
>> _______________________________________________
>> unloquer mailing list
>> unloquer at lists.aktivix.org
>> https://lists.aktivix.org/mailman/listinfo/unloquer
>>
>>
>
> _______________________________________________
> unloquer mailing list
> unloquer at lists.aktivix.org
> https://lists.aktivix.org/mailman/listinfo/unloquer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aktivix.org/pipermail/unloquer/attachments/20170413/b049afa8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: map_course.png
Type: image/png
Size: 119604 bytes
Desc: not available
URL: <https://lists.aktivix.org/pipermail/unloquer/attachments/20170413/b049afa8/attachment-0001.png>