On 8/22/20 4:13 PM, Rodolfo Quesada Zumbado wrote: > Hola, > > Lo que me está preocupando como menciona Wolter y por eso proponía el 'kill > switch', es que eventualmente alguien se va a aburrir y queden los datos > desactualizados en la metadata de los relations, para muestra un botón, > revisen los artículos de Wikipedia sobre la pandemia de COVID19 en Costa > Rica, están abandonados, excepto un par de updates al día de un editor desde > Asia para el conteo diario, pero las estadísticas y mapas llevan semanas de > atraso:
Es que en teoría, esa info no debería estar en OSM, me parece. La etiqueta alert:cne parece no existir en la wiki y tampoco una propuesta de etiquetado al respecto. No estoy seguro, en ese sentido, si esa información debería ir en el mapa libre, o cómo sería la mejor forma de gestionar dicha info. Pienso que tal vez el approach ideal sería montar un mapa propio que use de base OSM y se le agregue una capa adicional con la información de las alertas. Con Mapbox se podría hacer algo así y hasta jugar a agregarle otras cosillas... > > https://en.wikipedia.org/wiki/2020_coronavirus_pandemic_in_Costa_Rica > > https://es.wikipedia.org/wiki/Pandemia_de_enfermedad_por_coronavirus_de_2020_en_Costa_Rica > > Para las alertas tipo CNE directamente en OSM, también estuve buscando y no > he encontrado nada, lo que si he visto mucho es usar OSM como base layer y > luego repintar encima con algún framework JavaScript. Hay montones de > ejemplos con Leaflet y MapBox, que posiblemente hacen ya lo que estamos > discutiendo acá, tomar un CSV/JSON, jalar los relations desde OSM, poner un > layer encima, y pintarlos... Para obtener algo como lo que tiene la CNE con > ESRI o ArcGIS, pero comunitario. Ayyn a esto me refería arriba. Creo que ese sería el método adecuado para hacerlo. > Me parece que hay que investigar un poco más como montar estas alertas, ver > si hay otros países que lo están usando directamente sobre los relations > (parece que no), o usándolos de base para otro layer, o si ya recae en > proyectos como HOT (https://www.hotosm.org/), pero veo que lo que ellos > tienen es para mejorar los mapas de zonas afectadas que lo requieran > (https://wiki.openstreetmap.org/wiki/COVID-19), ya hubo una mapatón hace poco > me parece, a nivel de Centroamérica. Estuve exporando en Hot y todo su proyecto relacionado al COVID se refiere al mapeo de lugares, y es por ahí que me entra la duda, si OSM debería ser usado para agregar características dinámicas. Creo que lo más cerca que he visto a un proyecto así es la etiqueta que indica si un edificio está en construcción o no, o el etiquetado de calles para inundaciones. > Con respecto a los CSV de unidades administrativas con sus relation, nombre y > código, pues, es la fuente de la información que montamos desde Overpass para > la tabla del Wiki, ya tenemos eso listo! Que pena que no les comenté eso > antes, no he revisado si se pueden subir archivos así al Wiki que sería lo > ideal, o bien, irnos haciendo un github tipo osm-cr como comunidad. Otra > cosa que puedo hacer es subirlos en wikitablas a esa misma página, que quede > de referencia y adicionalmente segregado por tabla de cantones y de > distritos. > > ... Ya agregué la de cantones que la tenía lista de prueba, en los próximos > días agrego la de distritos, voy a agregar una columna de 'Notes' para > pendientes por cada unidad. (Notar acá que la División Territorial > Administrativa y el INEC usan códigos de 3 caracteres para los cantones, > entonces códigos como 10100 deberían ser 101. La tabla de códigos postales de > Wikipedia en inglés de hecho la he estado actualizando yo. :-D) > > Por cierto, acá tengo algo parecido para la Red Vial Nacional, tengo > pendiente escribirles sobre este proyecto que he estado montando, para dotar > de relations a cada ruta nacional, ya hay unas poquitas listas, y es otra > tabla que hay una incompleta en el wiki principal que hay que quitar, el link > ya está ahí hacia esta otra: > > https://wiki.openstreetmap.org/wiki/Costa_Rica/Red_Vial_Nacional > > Eso sería por hoy. :) > > > > On Sat, Aug 22, 2020, at 13:50, Wolter H. V. wrote: >> [2020-08-21 00:49 -0600] Rodrigo: >>> On 8/20/20 7:57 PM, Jaime Gutiérrez Alfaro wrote: >>>> On Thu, Aug 20, 2020 at 3:04 PM Rodolfo Quesada Zumbado <r...@roqz.net> >>>> wrote: >>>>> Hola Jaime, Wolter, Rodrigo y amigos de OSM, >>>>> >>>>> Jaime y yo estuvimos trabajando un poco ahora temprano y creamos esta >>>>> tabla fija y plana con todas las unidades administrativas de Costa Rica y >>>>> sus relations de OSM: >>>>> >>>>> https://wiki.openstreetmap.org/wiki/Costa_Rica/Divisi%C3%B3n_Territorial_Administrativa >>>>> >>>>> Se puede/debe mejorar (ej, agregar códigos postales por distrito y >>>>> códigos de cantón), pero sirve de referencia rápida para muchos >>>>> proyectos. Yo juraba que la tabla que tenemos en el Wiki estaba >>>>> completa, pero nunca me animé a expandirla, la agregó un colaborador que >>>>> está normalizando eso en varios países. >>>>> >>> Esto me parece genial. A esa misma tabla creada se le puede agregar una >>> columna especificando los elementos pendientes, para pensar en un esquema >>> de trabajo comunitario y seguimiento de qué cantones y distritos tienen la >>> info completa. >> ¡Qué buen trabajo la verdad! Los felicito. Para que quede de referencia >> para el futuro, la tabla de códigos postales de Costa Rica de Wikipedia >> en inglés [1] es una buena fuente de información para este caso >> >>>> Súper. En realidad toda la chamba la hizo Rodolfo. Ahora que tenemos esta >>>> tabla con una página wiki propia quizás podemos valorar eliminar la tabla >>>> que está en >>>> https://wiki.openstreetmap.org/wiki/Costa_Rica#Provinces.2C_Cantons_and_Districts >>>> y mover esa info a la nueva página que hizo Rodolfo. Así todo el tema de >>>> división administrativa estaría junto. No se qué les parece, aunque >>>> podríamos hacer otro hilo de correo para conversar sobre ese tema. >>> De acuerdo con eliminar la tabla y agregar solamente un párrafo >>> direccionando a esta nueva página. >> Yo también, de acuerdo. Creo que sí valdría la pena conversar esa >> página por aparte para unificar esa info. >> >>>>> La iniciativa de las alertas me parece bien, y sugiero unas cosas >>>>> adicionales al respecto: >>>>> * Kill Switch: En teoría #estopasará como dicen en las redes sociales, >>>>> entonces hay que tener listo un mecanismo (y encargado) para quitar los >>>>> tags cuando ya no sea necesario. >>>> Si, el tema del covid y las restricciones pasará. Sin embargo, el tema de >>>> las alertas de la CNE no es algo que pase. Las usan para cuando hay >>>> condiciones climáticas adversas o situaciones que lo ameriten. Hoy no tuve >>>> chance de revisar si esto es así por alguna ley en específico. En el sitio >>>> web de la CNE está este enlace: >>>> https://cne.go.cr/preparativos_respuestas/alertas.aspx. Con esto quiero >>>> decir que quizás hay que valorar esta etiqueta con esa perspectiva. >> Sí me parece buena idea quitar las etiquetas cuando ya no sean >> necesarias / cuando deje de haber alguien que las actualice. Si alguien >> se comprometiera a actualizar las etiquetas indefinidamente, no lo >> vería necesario. Respecto a ese tema, sería interesante conversar con >> alguien del CNE para ver si se interesan en este tema. Pienso que al >> sitio de la CNE le vendría bien un visualizador de este mapa de alertas. >> >>>>> * Timeline Log: Crear un CSV o tabla en algún lado (GitHub?), para llevar >>>>> control del histórico... A la fecha no se ha publicado por parte del >>>>> gobierno la especificación de como se asignan los colores, dependemos de >>>>> noticias para eso, y no se está guardando el histórico en ningún lado, >>>>> solo se conoce el estado actual (creo?). Puede servir de input para la >>>>> herramienta que propone Wolter. Por ejemplo, Montes de Oca ya es >>>>> amarillo, pero lo veo naranja en el mapa, y creo que el cambio fue ayer?. >>>>> :-P >>>> El estado de alerta lo declara la CNE. Tienen un hermoso listado de PDF >>>> con el histórico de alertas: >>>> https://cne.go.cr/preparativos_respuestas/alertas/historicoalertas.aspx. >>>> Cero datos abiertos. A mi me suena bien la idea de llevar un histórico en >>>> un CSV en github. Creo que es un aporte bonito. >>> Me parece bien, sería un bonito proyecto. Traducir el histórico de alertas >>> requerirá un trabajo interesante que puede servir en el futuro para >>> estudiar la gestión del sistema de alertas frente a la pandemia, y otras >>> emergencias. >> Sería interesante incluso hacer que la herramienta tome el CSV como >> entrada, de modo que al actualizar la tabla CSV y correr la >> herramienta, la herramienta haga las actualizaciones necesarias en OSM. >> >> El CSV podría tener un formato como >> >>> Fecha y hora de actualización | admin_level | Sujeto | Alerta | >>> 2020-08-22T00:17-0600 | 4 | Merced | naranja | >> Si se va a aplicar el etiquetado de regiones a diferentes niveles >> administrativos. En este caso, recomiendo que haya otro nivel de alerta >> que signifique "nivel de alerta heredado de región administrativa >> madre" (tal vez algo un poco más conciso), para el caso de que un >> distrito pase de tener un nivel de alerta excepcional (distinto al de >> su cantón), a tener el mismo nivel de alerta que su cantón. Una opción >> sería eliminar la etiqueta del todo, pero eso puede ser difícil de >> diferenciar de un error. >> >>> Este sistema del histórico de alertas podría incluir añadir y gestionar >>> etiquetas como, alert=yes/no y alert_type=health/natural_disaster etc... >>> aunque no estoy si ya existe algún modelo de etiqueta de alertas para OSM. >>> Indagué algo en la wiki y no encontré nada. >> Está interesante, aunque me preocupa el "feature creep" y el hecho de >> replicar (y mantener) información que le corresponde al CNE. >> >>>> Esta propuesta la implementé en el mapa con el que hemos estado probando >>>> esto: http://u.osmfr.org/m/490621/ >> ¡Que bueno! ¿Tiene el código fuente de eso en la nube? >> >> Por mi parte, me puse a armar unos CSV para jalar info de las >> relaciones según región administrativa. Los intenté adjuntar pero el >> mensaje pasó el tamaño permitido, entonces solo copio unas previstas. >> Si son útiles eventualmente los puedo cargar a algún sitio. >> >> * **zonas.csv** tiene 3 columnas: código, nombre y relación. El código >> indica si la región es provincia (X0000), cantón (XXX00) o distrito >> (XXXXX). Esto es poco legible para humanos pero es una forma mínima de >> la información. >> >> Código,Nombre,Relación >> 10000,San José,{{Relation|3223004|tools=no}} >> 10100,San José,{{Relation|4069041|tools=no}} >> 10101,Carmen,{{Relation|4068775|tools=no}} >> 10102,Merced,{{Relation|4068748|tools=no}} >> >> * **zonas3.csv** tiene 5 columnas: código, provincia, cantón, distrito >> y relación. Esta versión es más legible para humanos, pero tiene >> información superflua. Las filas sin valores para cantón ni distrito >> corresponden a provincias (intuitivo), aquellas sin valor de distrito >> corresponden a cantones, y aquellas con provincia, cantón y distrito >> corresponden a distritos. >> >> Código,Provincia,Cantón,Distrito,Relación OSM >> 10000,San José,-,-,{{Relation|3223004|tools=no}} >> 10100,San José,San José,-,{{Relation|4069041|tools=no}} >> 10101,San José,San José,Carmen,{{Relation|4068775|tools=no}} >> 10102,San José,San José,Merced,{{Relation|4068748|tools=no}} >> >> Saludos, >> >> Wolter HV >> >> [1]: https://en.wikipedia.org/wiki/List_of_districts_of_Costa_Rica >> >> >> >> >> >> >> _______________________________________________ >> Talk-cr mailing list >> Talk-cr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cr >> _______________________________________________ Talk-cr mailing list Talk-cr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cr
