Diferencia importante en el núm de observaciones entre proyectos
Por alguna extraña razón, el proyecto sombrilla (https://www.inaturalist.org/projects/cordillera-volcanica-central-en-limon-umbrella-project) me da muchas más observaciones que el proyecto collection (https://www.inaturalist.org/projects/cord-volcanica-central-en-limon/), a pesar de que cubren el mismo territorio. La diferencia en cómo delimité fue que el proyecto sombrilla utiliza Sector Quebrada González en vez de lo configurado en el proyecto collection que usa todo el PN Braulio Carrillo eliminando las provincias que no son Limón. Las demás áreas quedaron igual en ambos proyectos. Solamente esta diferencia causa que el sombrilla tenga 9258 observaciones vs 8393 en el collection.
Comparando los mapas, solo logré ver diferencias precisamente en las observaciones en el Sector Quebrada González. El proyecto sombrilla tiene más que el collection en esta zona, pero al mismo tipo, el collection tiene algunas observaciones que el sombrilla no tiene. Creo que esto se debe a que algunas observaciones tienen radios de precisión muy grandes, lo cual los excluye de un mapa pero no de otro (e incluso seguramente hay algunas observaciones que no aparecen en ninguno de los dos).
Una posible solución es incluir en el proyecto sombrilla al proyecto collection para no perder esas observaciones. Pero siempre con la cautela de que algunas observaciones quizás no se contabilizan en ninguno de los dos, en especial si son ofuscadas.
Luego de incluir el collection dentro del umbrella, ahora el umbrella contabiliza 9432 en vez de la anterior cifra (9258), son 174 observaciones adicionales. Lo bueno es que puedo asumir que el umbrella no está contabilizando dos veces una misma observación (si fuera así, el total ahora sería aprox. 17.651 observaciones).
NOTA 1: me estaba "incomodando" ver tantas observaciones ofuscadas de dantas en estos proyectos (en ambos aparecen de forma similar), pues no sé si el sistema está delimitando bien estas observaciones a mi área de interés o está incluyendo áreas muy lejanas y ajenas al proyecto al otro lado de la Cordillera. Pero creo que ya entendí lo que sucede: en realidad sí hay muchas observaciones de dantas en la zona de interés, se pueden ver precisamente en el lugar conocido como Tapirus Lodge (por algo lo nombraron así) en Rainforest Adventures (el teleférico). Esto explica la mayor parte de esas numerosas observaciones, aunque algunas siempre podrían ser de fuera del área del proyecto.
NOTA 2: Respecto a los filtros para excluir lugares (en este caso, provincias Heredia, Cartago, San José), creo que es una especie de función "clip" (intersección de conjuntos), pero no estoy seguro que sucede por ejemplo con observaciones que están en los límites a veces mal definidos en los mapas default de las provincias que tiene iNaturalist (en los mapas default de cantones también los he visto muy mal definidos los límites), la pregunta es: ¡estos lugares incluidos en un mapa incluido en el proyecto, se conservan o se eliminan al pasar por el filtro de excluir provincias? No lo puedo saber fácilmente. La solución sería posiblemente incluir nuevos places con delimitación más precisa, que podrían ser places que no están ahora disponibles, por ejemplo, distritos justo en la zona límite (por fuera) del área de interés, ya que en lo posible es mejor no crear "duplicados" (versiones alternativas que no son iguales en este caso) de cantones o provincias (default de iNat vs Atlas CR 2014), pero sí se pueden agregar los distritos del Atlas CR 2014, pues los distritos no están incluidos por default en iNat, y tienen límites más precisos. El problema aquí es que para que funcionen estos distritos como filtro (para exluirlos), tendría que agregar todos los distritos que albergan una parte del territorio del PNBC o de la RFCVC. Solamente así podría elaborar un buen filtro de exclusión, para quedarme solo con lo que está dentro de Limón. Y además, estos distritos serían útiles para todos los usuarios de iNat.
La alternativa más fácil para mí sería crear solamente un clip de la RFCVC con los cantones de Limón que contienen parte de la RFCVC, y hacer un place denominado RFCVC, sector Limón (o algo así), el problema es que esto no es una designación oficial, aunque sí cumple con límites oficiales. Quería evitar hacer este place por eso mismo, y para eso usé los filtros de exclusión (provincias default de iNat), pero por falta de precisión, estoy buscando alternativas. Si quiero hacer ese place a conveniencia, ya pude comprobar que la capa de Provincias en el Atlas CR 2014 tampoco tiene delimitación precisa, mientras que cantones y distritos comparten el mismo nivel de precisión (mucho más que el mapa de provincias). Al menos comparando el límite del distrito Guápiles con el cantón Pococí (Atlas CR 2014), son iguales en la zona que lo inspeccioné (mientras que el límite de provincia Limón se nota que es mucho menos exacto). Lo más práctico pues sería hacer una unión de los cantones de Limón (Atlas CR 2014) que contienen parte de la RFCVC, y con esto hacerle un clip al área total de la RFCVC, y así quedo con un mapa/place de "RFCVC, Sector Limón" con límites más precisos, y ya no tendría que usar los filtros de exclusión con base en provincias default de iNat.
Revisando este límite, me percaté que el mapa/place del distrito Guápiles que subí hace aprox. 4 años alguien lo cambió y yo ni me percaté (ni me llegó un mensaje ni nada, a pesar de que el place está a ni nombre). Parece que alguien le hizo una especie de "crop" para ajustarlo a los límites (no exactos) por default de la provincia de Limón. De manera que perdió un área que le corresponde más allá de este límite inexacto. Me percaté de esto al analizar unas pocas observaciones sobre Ruta 32 cerca del puente sobre Río Sucio, un sitio donde hay un límite entre 3 Provincias. Aquí lo que me parece curioso es si fue un proceso automático, o si hay alguien "encargado" de hacerle clips a los "community curated" maps/places para ajustarlos a los límites burdos/inexactos de las provincias/cantones default de iNaturalist. En fin, volví a subir el mapa del distrito Guápiles al place y parece que sí aceptó el cambio, y tomé dos precauciones: al kml lo nombré: "GuapilesDistritoAtlasCR2014" y al place le puse en el nombre "normal" solamente "Guápiles", pero en display name, le puse: "Guápiles, LI, CR (Atlas CR 2014)", para enfatizar que es un mapa oficial de ese Atlas, y que no estoy inventándome yo los límites más precisos.
Dado lo anterior, me entró la ligera duda de si los mapas Atlas CR 2014 (en el sistema CRTM05) (fuente https://repositoriotec.tec.ac.cr/handle/2238/6749?show=full) son equivalentes al sistema usado en Google Maps (el mismo de iNaturalist) que es WGS84 supongo. Encontré esta mención: "Parameter values are from CR05 to CR-SIRGAS (1) (code 9751) assuming that CR-SIRGAS (ITRF08 (IGb08)@2014.59) is equivalent to WGS 84 within the accuracy of the transformation." https://epsg.io/5367 .Según esa fuente, es posible que el CRTM es equivalente a WGS 84 Dentro del área de precisión de la transformación* (y por tanto, no habría necesidad de convertir los mapas entre CRTM y WGS84). Además, al cargar el mapa Atlas CR 2014 en Google Earth tengo la impresión de que ya lo está ajustando al datum de Google Earth (el WGS 84), y así, después de importarlo en Google Earth, es como los estoy guardando en kml y subiendo a places de iNaturalist.
Comments
Add a Comment