UDAPE PRESENTA ESTE DOCUMENTO QUE MUESTRA UNA SERIE DE NUEVOS DATOS GEOGRAFICOS QUE SINTETIZAN Y REFLEJAN, EL ESTADO DE SITUACION DE LOS TERRITORIOS INDIGENAS ORIGINARIOS CAMPESINOS(TIOC'S) EN DIVERSOS CAMPOS VINCULADOS CON SU DESARROLLO Y CONDICION ECONOMICA.
DESCARGAR EN EL SIGUIENTE LINK
jueves, 24 de noviembre de 2011
viernes, 11 de noviembre de 2011
10 elementos clave para la usabilidad en aplicaciones web GIS
En este artículo se pretenden ofrecer algunas claves básicas para poder mejorar la usabilidad de nuestras aplicaciones web GIS. Estas claves se basan en las 10 claves de usabilidad de Jakob Nielsen pero adaptadas al GIS:
1
Visibilidad del estado del sistema. Nuestra aplicación debe informar en todo momento al usuario, qué está haciendo. Si hemos lanzado un geoproceso, además del típico reloj de arena, no estaría de más ir enviando mensajes de cómo va el estado del geoproceso o un porcentaje de ejecución. Con las tecnologías ajax no es complicado (por ejemplo usando DWR).
2
Que la aplicación y el usuario hablen el mismo lenguaje. “La feature #21 incumple las reglas de topología definidas en el dataset“. ¿Quién entiende un mensaje así fuera del mundo GIS? Un mensaje como “no ha sido posible insertar el elemento” sería mucho más entendible. Eso sí, tampoco está de más, ofrecer la posibilidad de ampliar detalles técnicos (ver punto 9 más abajo).
3
Usuarios, Control y Libertad. Ups, no quería hacer esto… ¿cómo vuelvo atrás?. Siempre es importante ofrecer puertas de escape ante acciones involuntarias de los usuarios. Si hay un botón de borrar y el usuario lo pulsa accidentalmente, debería ser posible deshacer la acción.
4
Consistencia y estándares. Si todos usamos la lupa o el símbolo + para agrandar un mapa, no es buena idea inventar un nuevo icono para esta acción (estándares). Además, si ya se ha usado un tipo de icono para representar algo, es importante volver a usarlo siempre para esa misma acción (consistencia).
5
Prevención de errores. Si dejar un polígono abierto, ya se sabe que va a provocar un error de topología en la geodatabase, hay que impedir que antes que se ejecute la transacción el usuario pueda grabar ese polígono. Todo lo que se pueda validar en cliente, debe hacerse. Si múltiples opciones son potencialmente conflictivas (crear y borrar) han de activarse/desactivarse de forma automática.
6
Reconocimiento en vez de tener que recordar. ¿Cómo se cargaba una capa? Las acciones más habituales deben ser fácilmente reconocibles, sin que el usuario deba recordar en qué oscura opción del menú oculto se encontraba.
7
Flexibilidad y eficiencia de uso. Hacer las cosas sencillas a los nuevos y dar atajos a los usuarios más avanzados. Es posible que las primeras veces que nuestro usuario quiere crear un polígono pase por ese maravilloso asistente que hemos creado, pero seguramente, tras 5 veces ya se sepa todos los pasos de memoria, y le resulte tedioso. Ha pasado a ser un usuario avanzado. ¿Por qué no ofrecerle un atajo de teclado para facilitarle la tarea? En javascript no es tan complicado como pueda parecer.
8
Estética y diseño minimalista. O la revolución del iPod. Pocos botones que dan acceso a la funcionalidad necesaria. Por desgracia, en el mundo del GIS es habitual ver aplicaciones muy recargadas de iconos, menús y opciones. En vez de eso, es mejor limitar al máximo el número de opciones en función de la operativa del usuario. Aunque un usuario editor pueda crear elementos, sería aconsejable no mostrar la barra completa de edición hasta que no haya decidido crear un nuevo elemento.
9
Ayudar a los usuarios con los errores, identificándolos y ayudándolos. “Contacte con el Administrador del Sistema“. Quizá no haya peor mensaje de error, porque nos deja tal y como estábamos. Siempre que sea posible, hemos de mostrar mensajes de error que ayuden a identificar el problema o que puedan servir de referencia. Si no se ha podido insertar un elemento porque ha habido una desconexión momentánea en la geodatabase, sería mejor informar de esto al usuario, y si no queda más remedio que redireccionarle al administrador, proporcionarle pre-formateada toda la información del error para que pueda solucionar el problema lo antes posible.
10
Ayuda y documentación. Si el diseño es bueno, la documentación puede parecer secundaria. Sin embargo, por mucho que nos esforcemos con el diseño siempre habrá situaciones que no habremos controlado, o que no habremos resuelto bien con el diseño. En este caso la documentación debe estar disponible ahí mismo, para mostrar la información relevante y exclusiva al problema en cuestión. Y no olvides que un vídeo o locución puede aclarar más y ahorrar mucho tiempo.
Si quieres ver mas a detalle visita el siguiente link
De aitorcaleroesri
Visto en:BlogESRI
1
Visibilidad del estado del sistema. Nuestra aplicación debe informar en todo momento al usuario, qué está haciendo. Si hemos lanzado un geoproceso, además del típico reloj de arena, no estaría de más ir enviando mensajes de cómo va el estado del geoproceso o un porcentaje de ejecución. Con las tecnologías ajax no es complicado (por ejemplo usando DWR).
2
Que la aplicación y el usuario hablen el mismo lenguaje. “La feature #21 incumple las reglas de topología definidas en el dataset“. ¿Quién entiende un mensaje así fuera del mundo GIS? Un mensaje como “no ha sido posible insertar el elemento” sería mucho más entendible. Eso sí, tampoco está de más, ofrecer la posibilidad de ampliar detalles técnicos (ver punto 9 más abajo).
3
Usuarios, Control y Libertad. Ups, no quería hacer esto… ¿cómo vuelvo atrás?. Siempre es importante ofrecer puertas de escape ante acciones involuntarias de los usuarios. Si hay un botón de borrar y el usuario lo pulsa accidentalmente, debería ser posible deshacer la acción.
4
Consistencia y estándares. Si todos usamos la lupa o el símbolo + para agrandar un mapa, no es buena idea inventar un nuevo icono para esta acción (estándares). Además, si ya se ha usado un tipo de icono para representar algo, es importante volver a usarlo siempre para esa misma acción (consistencia).
5
Prevención de errores. Si dejar un polígono abierto, ya se sabe que va a provocar un error de topología en la geodatabase, hay que impedir que antes que se ejecute la transacción el usuario pueda grabar ese polígono. Todo lo que se pueda validar en cliente, debe hacerse. Si múltiples opciones son potencialmente conflictivas (crear y borrar) han de activarse/desactivarse de forma automática.
6
Reconocimiento en vez de tener que recordar. ¿Cómo se cargaba una capa? Las acciones más habituales deben ser fácilmente reconocibles, sin que el usuario deba recordar en qué oscura opción del menú oculto se encontraba.
7
Flexibilidad y eficiencia de uso. Hacer las cosas sencillas a los nuevos y dar atajos a los usuarios más avanzados. Es posible que las primeras veces que nuestro usuario quiere crear un polígono pase por ese maravilloso asistente que hemos creado, pero seguramente, tras 5 veces ya se sepa todos los pasos de memoria, y le resulte tedioso. Ha pasado a ser un usuario avanzado. ¿Por qué no ofrecerle un atajo de teclado para facilitarle la tarea? En javascript no es tan complicado como pueda parecer.
8
Estética y diseño minimalista. O la revolución del iPod. Pocos botones que dan acceso a la funcionalidad necesaria. Por desgracia, en el mundo del GIS es habitual ver aplicaciones muy recargadas de iconos, menús y opciones. En vez de eso, es mejor limitar al máximo el número de opciones en función de la operativa del usuario. Aunque un usuario editor pueda crear elementos, sería aconsejable no mostrar la barra completa de edición hasta que no haya decidido crear un nuevo elemento.
9
Ayudar a los usuarios con los errores, identificándolos y ayudándolos. “Contacte con el Administrador del Sistema“. Quizá no haya peor mensaje de error, porque nos deja tal y como estábamos. Siempre que sea posible, hemos de mostrar mensajes de error que ayuden a identificar el problema o que puedan servir de referencia. Si no se ha podido insertar un elemento porque ha habido una desconexión momentánea en la geodatabase, sería mejor informar de esto al usuario, y si no queda más remedio que redireccionarle al administrador, proporcionarle pre-formateada toda la información del error para que pueda solucionar el problema lo antes posible.
10
Ayuda y documentación. Si el diseño es bueno, la documentación puede parecer secundaria. Sin embargo, por mucho que nos esforcemos con el diseño siempre habrá situaciones que no habremos controlado, o que no habremos resuelto bien con el diseño. En este caso la documentación debe estar disponible ahí mismo, para mostrar la información relevante y exclusiva al problema en cuestión. Y no olvides que un vídeo o locución puede aclarar más y ahorrar mucho tiempo.
Si quieres ver mas a detalle visita el siguiente link
De aitorcaleroesri
Visto en:BlogESRI
miércoles, 9 de noviembre de 2011
Reporte Cartografía de Quemas e Incendios Forestales en Bolivia,2010
La FAN (Fundación Amigos de la Naturaleza) pone a vuestra disposición, este reporte de quemas e incendios, 2010
Hasta la fecha en Bolivia no existía una cuantificación de superficies afectadas por incendios que
permita evaluar daños, ni la localización de sitios de mayor presión, o evidenciar patrones de
conversión del bosque a través de incendios.A partir de este documento se genera una metodologia para elaborar estos reportes periodicos que permitan tomar medidas preventivas mas atinadas. Por ejemplo en el documento para evaluar las quemas históricas en Bolivia se utilizaron imágenes MODIS (MCD45A1) con una resolución de 500 m para diez años (2000 – 2010). La validación de la cuantificación de superficies quemadas se la realizó aplicando el cociente normalizado de quemas (NBR) a imágenes Landsat TM con una resolución de 30m, que permita separar las cicatrices de quema; se seleccionaron las ecoregiones de la Amazonia y la Chiquitania, para estimar la exactitud.
Puedes descargarlo en este link
Hasta la fecha en Bolivia no existía una cuantificación de superficies afectadas por incendios que
permita evaluar daños, ni la localización de sitios de mayor presión, o evidenciar patrones de
conversión del bosque a través de incendios.A partir de este documento se genera una metodologia para elaborar estos reportes periodicos que permitan tomar medidas preventivas mas atinadas. Por ejemplo en el documento para evaluar las quemas históricas en Bolivia se utilizaron imágenes MODIS (MCD45A1) con una resolución de 500 m para diez años (2000 – 2010). La validación de la cuantificación de superficies quemadas se la realizó aplicando el cociente normalizado de quemas (NBR) a imágenes Landsat TM con una resolución de 30m, que permita separar las cicatrices de quema; se seleccionaron las ecoregiones de la Amazonia y la Chiquitania, para estimar la exactitud.
Puedes descargarlo en este link
lunes, 7 de noviembre de 2011
Atlas Histórico Mundial Interactivo desde 3000 a.C.
Con un gran impacto mediático, desde hace unos meses se ha puesto en marcha la página web y la aplicación Geacron ideada por el historiador Luis Músquiz. Geacron es sistema, basado en OpenLayers en su aplicación e mapas, que permitiese representar en el tiempo los hechos históricos y los mapas geopolíticos de cualquier región o país del mundo.
El funcionamiento es sencillo, gracias eso si, a un concienzudo trabajo de un equipo multidisciplinar. El sistema permite posicionarse en cualquier zona geográfica, mediante herramientas de búsqueda y de navegación. Así mismo, incluye la posibilidad de incrustar, en webs de prensa digital o temáticas, determinadas zonas geográficas y su evolución en el tiempo.
La primera versión de GeaCron contiene una secuencia de mapas que cubren la historia política desde el año 3000 a.C. Los mapas muestran la situación histórica del mundo al principio de cada año; por tanto, los cambios que se produzcan en el año actual quedarán mostrados en los mapas de 2012.
Podemos decir que GeaCron es una herramienta 2.0 ya que está abierta a la colaboración de todos que quieran sugerir algún tipo de modificación o cualquier otra clase de contribución.
Sin duda puede convertirse en un importante recurso didáctico, para profesores y alumnos de enseñanzas medias como herramienta complementaria para el estudio de la historia, aunque no podemos obviar las posibilidades que ofrecen a cualquier usuario interesado en la Historia.
En el caso de Bolivia podemos ver los cambios 1825 - 2011 hacer click
Visto en: http://sigdeletras.blogspot.com/
El funcionamiento es sencillo, gracias eso si, a un concienzudo trabajo de un equipo multidisciplinar. El sistema permite posicionarse en cualquier zona geográfica, mediante herramientas de búsqueda y de navegación. Así mismo, incluye la posibilidad de incrustar, en webs de prensa digital o temáticas, determinadas zonas geográficas y su evolución en el tiempo.
La primera versión de GeaCron contiene una secuencia de mapas que cubren la historia política desde el año 3000 a.C. Los mapas muestran la situación histórica del mundo al principio de cada año; por tanto, los cambios que se produzcan en el año actual quedarán mostrados en los mapas de 2012.
Podemos decir que GeaCron es una herramienta 2.0 ya que está abierta a la colaboración de todos que quieran sugerir algún tipo de modificación o cualquier otra clase de contribución.
Sin duda puede convertirse en un importante recurso didáctico, para profesores y alumnos de enseñanzas medias como herramienta complementaria para el estudio de la historia, aunque no podemos obviar las posibilidades que ofrecen a cualquier usuario interesado en la Historia.
En el caso de Bolivia podemos ver los cambios 1825 - 2011 hacer click
Visto en: http://sigdeletras.blogspot.com/
Suscribirse a:
Entradas (Atom)