[un/loquer] Agentes de calidad del aire

Jue Abr 6 23:13:49 UTC 2017

2017-04-06 13:39 GMT-05:00 Eliette Restrepo <elietterestrepo at gmail.com>:

>
> Tenemos dificultades para representar la realidad, pues si la bicicleta se
> queda mucho rato en un solo punto, el mapa de calor muestra mayor densidad
> en esa área y aparenta un mayor valor en las mediciones (o sea que se pone
> más hacia el rojo), se intentó sacar un promedio de los puntos que estén en
> la misma geolocalización, pero es una solución temporal pues esto
> eliminaría medidas tomadas en ese mismo punto en días diferentes.
>
> Tal vez esto ya se habló antes, pero: la idea es dar un valor absoluto de
> la concentración de PM25, o un valor relativo?
>

Ambas maneras servirían, incluso sería bueno poder tener ambas opciones, el
absoluto se podría calibrar con los valores que usa el SIATA y que nuestro
rojo sea el rojo de ellos, y la opción de una escala relativa calibrando el
rojo con el valor máximo de las mediciones nos podría permitiría ver
relaciones con el sensor sin calibrar (pero entorpecería la medida de
diferentes sensores con calibraciones diferentes)

>
> Lo que interpreto del mapa es que la medición depende del tiempo de
> muestreo. ¿Es correcto?
>

Es correcto.

> En éste caso, no se podría utilizar la medición para calcular un valor
> absoluto, sino que primero se tendría que normalizar la medición sobre el
> tiempo de muestreo. Por ejemplo, habría que medir el tiempo que se gasta en
> cada coordenada y dividir la concentración de PM25 sobre ese tiempo.
>

¿Esa aproximación no nos afectaría las revelaciones del mapa? supongamos
que el ciclista hace un recorrido haciendo zigzag entre la calle colombia
(muy contaminada) y la calle paralela (menos contaminada) normalizar no nos
haría ver ambas calles con un nivel similar?  porque justamente la
bicicleta lo que nos permite, ventaja sobre las estaciones fijas, es poder
marcar esas diferencias entre calles.

>
> Otro opción sería medir la velocidad de la bicicleta y definir una
> velocidad "estándar". Las mediciones de PM25 que se tomen mientras la bici
> va por fuera de la velocidad estándar se eliminarían. Por ejemplo, las
> mediciones que se tomen cuando la velocidad es 0 no se toman en cuenta para
> el promedio.
>

¿Esta aproximación nos nos pondría vulnerables en los semáforos y tacos? en
la reunión del SIATA salió justamente que los puntos más críticos de
emisión de parte de los carros son los tacos o semáforos y quisieramos
poder revelar eso.

Por supuesto que estas opciones que presentas mejorarían de alguna manera
la forma actual de medir, pero dejo esas preguntas para seguir
identificando los retos.

Otra opción es poner unas reglas e irlas ajustando hasta que logremos una
visualización que revele algo útil.

Leyendolos y pensando algunas reglas pueden ser:

- Evalúe la diferencia entre la Latitud y Logitud de la fila imediatamente
anterior en el arreglo de datos con relación a la fila presente, si la
diferencia es menor a X promedie.
- Elimine las filas que tengan diferencia en Lat Long menor a Y en cada
recorrido (esto apuntaría a lo que dice dani y eliette de disminuir la
resolución cuando se baja la velocidad)

Estas reglas se podrían aplicar a cada  "recorrido", no al dataset completo
 porque si el ciclista pasa dos veces en el día por el mismo sitio, nos
interesa poder ver los acumulados o los recorridos independientes, y que un
recorrido no elimine mediciones de otro anterior en la misma ruta.

Brolin, ¿Que se ocurre para marcar de forma automática los recorridos? se
puede hacer manual pero no escala, y  la fecha no sería suficiente porque
pueden suceder recorridos simultaneos de dos ciclistas, paso esto a issues.

>
>
>
> On Apr 6, 2017 10:52, "daniel gomez" <danielgomezmarin at gmail.com> wrote:
>
>> Hola
>>
>> Tenemos dificultades para representar la realidad, pues si la bicicleta
>>> se queda mucho rato en un solo punto, el mapa de calor muestra mayor
>>> densidad en esa área y aparenta un mayor valor en las mediciones (o sea que
>>> se pone más hacia el rojo), se intentó sacar un promedio de los puntos que
>>> estén en la misma geolocalización, pero es una solución temporal pues esto
>>> eliminaría medidas tomadas en ese mismo punto en días diferentes.
>>>
>>
>> tengo poco conocimiento de programar en R entonces en vez de hacer
>> pruebas en mi compu les digo una idea, aunque no se si estoy en lo correcto.
>>
>> ## detecta coordenadas repetidas y calcula el valor promedio para cada
>> coordenada única meansAddressPoints <- addressPoints %>% group_by(lat,lng)
>> %>% summarise(value=mean(value))
>>
>> esta línea acumula todas las mediciones para la coordenada x,y? o hace
>> una iteración sacando el promedio cada que encuentra un valor con las
>> mismas coordenadas?
>>
>> por otro lado, no sería práctico quitarle resolución a las coordenadas
>> (por ejemplo quitarles el último o los dos últimos digitos y volverlos
>> cero) para que en vez de ser puntos se hagan pixeles y así se hace menos
>> denso el mapa. no se cual es la resolución del gps, pero creo que pasar de
>> centímetros a decímetros o incluso a metros no afecta mucho el cálculo y
>> disminuye geométricamente (osea muchísimo) la cantidad de puntos
>> independientes que se deben calcular. También aumenta la cantidad de
>> mediciones por pixel. (esto tambíen puede ser lo que afecte el mapa porque
>> el tamaño del dibujo es mucho más grande que el punto donde se mide
>> entonces se traslapan varias mediciones que están en puntos cercanos).
>>
>> sobre la visualización
>> sería muy bueno poder consultar los datos por:
>> - 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
>>
>> aquí en este punto sería interesante poder hacer un mashup de datos de
>> diferentes fuentes que estén disponibles en la red.
>>
>> si hay algo de python que se pueda correr en el servidor puedo ayudar con
>> el mash de los datos y con la manera como se pueden organizar por días,
>> fecha, hora, etc.
>>
>>
>> _______________________________________________
>> 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/20170406/14087805/attachment.html>