Source: http://arkeox.blogspot.com/2008/
Timestamp: 2018-03-19 21:50:08+00:00

Document:
Arke_Geomática: 2008
Los arqueólogos estamos de enhorabuena al poder disponer desde principios de año de los ficheros *.xyz para obtener de una forma rápida y más que económica los modelos de elevaciones gracias a el proyecto PNOA, con una resolución
más que suficiente para la mayoría de los proyectos arqueológicos. Así que la tediosa digitalización de las curvas de nivel para crear los mismos queda em el baúl de los recuerdos.
PNOA o Plan Nacional de Ortofotografía Aérea se instituye para obtener una cobertura ortofotográfica continua a nivel nacional a partir de especificaciones técnicas comunes dentro de un proyecto de colaboración entre las distintas administraciones Autonómicas y la Administración General del Estado. En gran medida el espiritu del mismo trata de seguir las directrices de Inspire y los estándares para la distribución de la información a través de Servidores de Mapas remotos lo que supone una reducción de costes a través de una producción descentralizada y cooperativa . En última instancia los grandes beneficiados son los distintos agentes sociales que puedan sacar alguna utilidad de esta información más alla de los organismos implicados servicios territoriales y organismos cartográficos.
Las distintas fases del proyecto son lás típicas de la obtención de una Ortofotografía
Cálculo mediante procesos de aerotriangulación con apoyo topográfico.
Elaboración de la ortofotografía mediante técnicas de ortorectificación.
Muchas son las aplicaciones de los modelos de elevaciones en arqueología, calculos de costes, visibilidad, etc, todos ellos relacionados con la Arqueología Territorial más conocida "últimamente" como Arqueología del Paisaje. En este post nos limitaremos
a mostrar los distintos procesos que nos permiten crear un Modelo de Elevaciones o Modelo Digital del Terreno a partir de los ficheros *.csv de PNOA y varios programas SIG de código abierto para la obtenión de un fichero en formato grid de Esri.
Si bien el fin último es la obtención de una Ortofotografía fase prevía e ineludible para la obtención de la misma pasa por la creación de un MDE mediante la extracción del mismo a través de correlación de imágenes.
No conocemos una dirección que centralizen estos ficheros a nivel nacional estando disponibles en los distintos Servicios Territoriales u organismos similares de las distintas Comunidades Autónomas. En nuestro caso queremos obtener un MDT de Astorga y su entorno. La Junta de Castila y Léon en el siguiente Servidor FTP mantiene distintos datos de Acceso Público, a parte de los ficheros XYZ de los MDE se pueden obtener las observaciones GPS en formato Rhinex de las distintas estaciones de Referencia distribuidas por el territorio de la comunidad: http://gnss.itacyl.es/.
En el siguiente enlace ftp://ftp.itacyl.es/cartografia/MDE/Malla_10x10m/ se accede la distribución de hojas, de los modelos de elevaciones con un paso de malla de 10m.
que es una resolución más que suficiente para la mayoría de las aplicaciones en la arqueología territorial, aunque también estan disponibles con una resolución de 5m. Hemos optado por una resolución más "grosera" para disminuir el tiempo de ejecución de los procesos implicados en la transformación y generación del MDT al utilizar un número menor de ficheros. Es conveniente proveerse antes de nada con un croquis pdf de la distribución de las hojas. Una vez que conocemos el número de hoja que queremos descargar, en nuestro caso 0193 (relativo al número de la distribución de hojas a escala 1:50000) 1-1.
Identificado el fichero que necesitamos procedemos a descargarlo.
Una vez descargado el archivo en formato de fichero comprimido *.zip. proedemos a abrirlo obteniendo un fichero de texto con la extensión *.xyz. En esencia un fichero MDT es una simplificación númerica del terreno (relieve) mediante una matriz de alturas en el que se consignan sus cordenadas X e Y a un intervalo regular.
737670 4709360 978.87
737680 4709360 980.31
737690 4709360 981.34
737700 4709360 983.14
737710 4709360 985.02
737720 4709360 986.66
Estas son las primeras filas de un total de 319656 del fichero descargado en las que se observa que es un fichero delimitado por comas o *.csv con el delimitador tab o espacio con una proyección cartográfica UTM 29N con el datum ETRS89 codigo EPSG 25829 y una resolución o paso de rejilla de 10 metros. Es el momento de hacerse con un buen programita para poder editar y manipular los ficheros de tipo *.csv si estamos en el entorno de las ventanas, en entornos Linux simplemente tendríamos que abrir un terminal y escribir lo siguiente: cat ficheroPNOA.xyz | awk '{print $1";", $2";", $3}' > ficheroPNOA.csv. En este caso hemos transformado el fichero del PNOA *.xyz a un fichero *.csv con el delimitador punto y coma que es el utilizado en España y por ende por el mágnifico SIG GvSIG. En el caso de que la transformación sea realizada con Saga el fichero resultante tendría que utilizar un delimitardor tab y salvarlo con una extensión de fichero *.txt.
Una vez transformado el fichero xyz a formato *.csv con el delimitador tab y salvado con la extensión *.txt abrimos el módulo importar/exportar shapes y elegimos la opción importar shapes XYZ.
Cargamos el fichero previo dejando las opciones por defecto tal como están siendo X el campo 1 e Y el campo 2 como es el caso de nuestro fichero,si bien estas opciones pueden ser alteradas para adecuarse los campos X e Y a otras posiciones si fuera el caso . Una vez leido el fichero correctamente podemos presionar sobre los tabs Data y Map para visualizar el fichero generado del tipo Shape Point.
Una vez hecho esto ejecutamos el proceso de triángulación para generar una rejilla mediante este método de interpolación de puntos, para ello utilizamos el módulo Grid_Griding con la opción de triangulación, los parámetros que tenemos que consignar son los siguientes, en el apartado shape elegimos el fichero recien generado Point_SHAPE, en opciones de puntos habilitamos el campo que contiene la altura o Z , en las opciones de la generación de la Rejilla utilizamos la definida por el usuario y presionamos ejecutar.
Una vez hecho esto se nos abre una nueva ventana donde definimos la resolución de la rejilla, como hemos visto anteriormente los datos estan tomados cada 10 metros por lo que le damos este valor dejando las demas opciones por defecto y presionamos Okay Makey, y ya solo falta esperar a que se lleve a cabo el proceso de transformación que se puede demorar más o menos tiempo según las características de nuestro equipo, en mi caso unos 45 minutos lo que nos da lugar a terminar tranquilamente este Post.
Una vez realizado el proceso volvemos a presionar sobre el tab Data y presionamos sobre el nombre de nuesro fichero con la etiqueta triangulation y ya podemos visualizar nuestro DEM presionado sobre el tab Map.
Con estos sencillos pasos ya tenemos convertido el fichero de PNOA en un modelo de elevaciones apto para realizar con el propio Saga todas las operaciones comúmes que se realizan sobre estos ficheros en Arqueología así como algunas otras de las que daremos cumplida cuenta en un próximo y venidero post.
Por ultimo sólo nos queda exportar este fichero a un formato que se ha convertido en un estándar de facto *.ASC para lo cual utilizaremos el módulo Import/Export Grids con la opción export Esri Arc/Info Grid la rejilla a utilizar será la que acabamos de realizar, dejando las demás opcionespor defecto. Este formato de fichero es reconocido por la mayoría de los SIG Raster, el propio ARC/INFO, GRASS, Sextante, Ilwis, etc.
El fichero resultante en formato *.ASC puede ser descargado aqui. El proceso es el mismo si obtenemos a nivel de yacimiento un taquimétrico con estación total o gps para la creación de Módelos de Elevaciones de alta resolución. En este sentido es recomedable echarle un vistazo a esta publicación que recoge todos estos tópicos. y su aplicación a la Arqueología.
Etiquetas: MDE, Saga, Sig Open_Source, Tutoriales
Publicado por varix en 5:13 Enlaces a esta entrada 0 comentarios
Publicado por varix en 4:26 Enlaces a esta entrada 0 comentarios
Publicado por varix en 15:52 Enlaces a esta entrada 0 comentarios
Integración de OpenLayers en Blogger.
Si bien la forma más sencilla pasa por colocar una etiqueta iframe para llamar a una página externa, donde tengamos alojada la aplicación desarrollada en OL, la incorporación de un artilugio o widget facilita en gran medida la tarea, aunque este debe ser modificado para poder incorporar las capas que deseemos asi como los controles que creamos necesarios y que nos facilita la librería OpenLayers. El proceso de integración de los mapas es sencillo, teniendo que añádir nada más una etiqueta div en nuestros post donde se configuran los parameros de anchura, altura, coordenadas del centro del Mapa y el nivel de zoon deseado apelando a la clase slippymap sobre la que se basa este widget la extesión para incrustrar en MediaWiki Openlayers y desarrollada por el grupo de OpenStreetMap.
El widget original puede ser descargado aqui.
Una personalización del mismo incorporando otras capas
.slippymap img { padding: 0px !important; border: none !important;}
<!-- bring in the OpenStreetMap OpenLayers layers. Using this hosted file will make sure we are kept up to date with any necessary changes. -->
// Blogger Slippy Map 0.1.1
var lat = 54;
var style = "width:300px; height:200px;";
var element1, element2, element3, text;
for ( var j=0; j < tags.length; j++ ) {
if ( tags[j].className == "slippymap" ) {
if ( tags[j].getAttribute("lat") ) {
lat = tags[j].getAttribute("lat");}
if ( tags[j].getAttribute("lon") ) {
lon = tags[j].getAttribute("lon");}
if ( tags[j].getAttribute("z") ) {
z = tags[j].getAttribute("z");}
if ( tags[j].getAttribute("style") ) {
style = tags[j].getAttribute("style");}
element1 = document.createElement("div");
element1.setAttribute("class","tempmap");
element1.setAttribute("style","margin-bottom:-35px;");
<!-- define a DIV into which the map will appear -->
element2 = document.createElement("div");
element2.setAttribute("id", "map" + i);
element2.setAttribute("style", style
+ " border-style:solid; border-width:1px; border-color:#000;");
element2 = document.createElement("br");
element2 = document.createElement("span");
element2.setAttribute("class","tempmap")
element2.setAttribute("style",
"font-size:70%; background-color:white; position:relative;top:-65px;left:5px;z-index:1003;");
text = document.createTextNode("Data by ");
element3 = document.createElement("a");
element3.setAttribute("href","http://www.openstreetmap.org/?lat=" + lat
+ "&lon=" + lon + "&zoom=" + z );
element3.setAttribute("title","See this map on OpenStreetMap.org");
text = document.createTextNode("OpenStreetMap");
element3.appendChild(text);
element3 = document.createElement("br");
element3.setAttribute("href","http://creativecommons.org/licenses/by-sa/2.0/");
element3.setAttribute("title","Creative Commons Attribution-Share Alike 2.0");
text = document.createTextNode("CC-BY-SA-2.0");
tags[j].appendChild(element1);
eval("var lat"+ i + "=" + lat + "; var lon"
+ i + "=" + lon + "; var zoom"+ i + "=" + z + "; var map" + i
+ "; function lonLatToMercator(ll) { var lon = ll.lon * 20037508.34 / 180; "
+ "var lat = Math.log (Math.tan ((90 + ll.lat) * Math.PI / 360)) / "
+ "(Math.PI / 180); lat = lat * 20037508.34 / 180; return new "
+ "OpenLayers.LonLat(lon, lat); } ;"
+ "if (typeof window.addEventListener == 'function') { "
+ "window.addEventListener('load', init, false);} else if (typeof "
+ "window.attachEvent == 'object') { window.attachEvent('onload', "
+ "init);} else { var oldonload = window.onload ; if (typeof "
+ "window.onload != 'function') { window.onload = init;} else { "
+ "window.onload = function() { oldonload(); init(); } } };"
+ "function init() { map" + i + " = new OpenLayers.Map('map" + i
+ "', { controls:[ new OpenLayers.Control.Navigation()"
+ ", new OpenLayers.Control.PanZoom(), new OpenLayers.Control"
+ ".LayerSwitcher()], maxExtent: new OpenLayers.Bounds(-20037508.34, "
+ "-20037508.34, 20037508.34, 20037508.34), maxResolution:156543.0399, "
+ "units:'meters', projection: 'EPSG:900913' } ); var mapnik = new "
+ "OpenLayers.Layer.OSM.Mapnik('Mapnik'); map" + i + ".addLayer(mapnik);"
+ " var osmarender = new OpenLayers.Layer.OSM.Osmarender('Osmarender'); "
+ "map" + i + ".addLayer(osmarender); var cyclemap = new OpenLayers"
+ ".Layer.OSM.CycleMap('Cycle Map'); map" + i + ".addLayer(cyclemap); "
+ "var maplint = new OpenLayers.Layer.OSM.Maplint('Maplint'); map" + i
+ ".addLayer(maplint); var lonLat" + i + " = lonLatToMercator(new "
+ "OpenLayers.LonLat(lon" + i + ", lat" + i + ")); map" + i
+ ".setCenter (lonLat" + i + ", zoom" + i + "); } ");
Un ejemplo del widget original
Estos ejemplos acceden a capas del tipo OSM, asi como nos amos de vacaciones habrá que tirar de GPS para poder utilizarlos. La personalización realizada se fundamenta en las capas alojadas en la IDE española asi como en alguna de nuestro servidor de Mapas.
Publicado por varix en 13:48 Enlaces a esta entrada 0 comentarios
Etiquetas: Herramientas, Open Layers, Webmapping
Publicado por varix en 11:00 Enlaces a esta entrada 0 comentarios
Una de las características principales de los programas open source y en particular los portados desde Linux al sistema de las ventanas es su capacidad de ejecutarse sin problemas de dependencias a las librerias dinámicas del sistema al estar todas las necesarias en un directorio del propio programa, por lo que podemos tener multiples instancias del programa, instalaciones, fucionando perfectamente aunque sean ersiones distintas sin tener problemas de dependencias a las mismas. Esto abre la posibilidad a que gran parte de las aplicaciones open source puedan ser ejeutadas desde un CD, un dispositivo USB una memoría SD, etc. Esta práctica, la de llevar los programas en el bolsillo, en la camara fotográfica, .... nos permite transportar toda nuestra arafernalia de software sin tener que acarrear con el portatil al hombro, pudiendonos enchufar a cualquier ordenador, para trabajar, presentar nuestro trabajos, etc. con una configuración similar a la de nuestro equipo.
Esta idea se plasmo en un primer momento en los Lives CD que convertían una estación Windows en una caja Linux plenamente operativa, sin embargo muchos usuarios no están acostumbrados al entorno del pingüino por lo que la solución pasa por ofrecerles directamente los programas en el "confortable" entorno de las ventanas.
Una solución de este tipo, una suite de paquetes autocontenidos puede ser descargada en la siguiente dirección
si bien la conociamos hace tiempo no ha sido hasta hace unos días que nos hayamos decidio a probarla. Dado que todos estos programas los tenemos instalados, en lo casos de los servidores hemos tenido que parar todos aquellos servicios que pudieran interferir en su buen funcionamiento.
Pasamos a continuación a describir las características de este USBGIS
El paquete de programas esta compuesto por las siguientes aplicaciones:
SIG de escritorio.
Sig en entorno Java de muy rápido crecimiento y desarrollado con un fuerte apoyo institucional. Hacer notar que sobre entornos Windos Vista las funcionalidades Raster no funcionarán, acceso a WMS, etc. A resaltar el fichero Bat del arranque de la aplicación que nos provee una forma elegante y eficiente para evitar el problema del cambio de unidades y que puede ser reutilizado para todos aquellos programas, autocontenidos claro, que queramos utilizar.
Aunque funciona perfectamente obtenemos algunos errores con las extensiones Phyton, hacer notar que el ambiente python utilizado es el que provee Fwtools,siendo su versión la 2.3 y creemos que Qgis funciona perfectamente sobre la ultima versión de python, 2.5 o al menos sobre la 2.4
En nuestro caso no arranca una vez ejecutado el archivo bat, el problema viene dado por que tengo una instalación de Grass en Cygwin y para que corriera la nativa en Windws tendría que borrar cualquier huella de este emulador poxis sobre windows, cosa a la que no estoy dispuesto por que esta petao con muchisimas aplicaciones, otra cosa sería la posibilidad de crear un cygwin portable, de toda las maneras muchas de las funcionalidades de Grass puede ser utilizadas desde Qgis. En relación a Cygwin este enlace más que recomendable explica paso a paso en castellano como hacerlo portable.
No rula de ninguna de las maneras, aunque tenemos más que comprobado que FWtools es de una portabilidad al 100 por cien
Añádiendo aplicaciones autocontenidas.
El menu de la aplicación puede ser modificado en el fichero de configuración AppList en la forma
[Arrancar Saga]
Name=SAGA // Nombre que aparecera en la ventana de créditos
Executable=\USBGIS\APPS\saga_vc\saga_gui.exe // Ubicación del ejecutable
Menu=Progs
Website=http://gvsig.org/ // Créditos
Este mágnifico programa con innumerables módulos de los que destacan los de Sig Raster y Geoestadística así como algunos modelos de simulación de procesos como esperabamos no supone ningún problema el integrarlo al ser un viejo conocido portable haya donde vayas.
Añadir funcionalidades Geoestadísticas.
Echamos de menos uno de los mejores entornos de análisis estadístico R, sobre todo por lo diferentes módulos geoestadísticos que provee su integración tampoco supone ningún problema, en más de alguna casión lo habiamos echo rular desde nuestra cámara de fotos.
Extensiones de GvSIG
Sin lugar a dudas GvSIG sin desmerecer a los demás proyectos de Sig Libre es la aplicación SIG que mejor cumple los estándares de la OGC objetivo que se marco desde un principio, constituyéndose como el mejor cliente pesado para acceder a los servicios Web Geográficos.
En la misma hechamos en falta la extensión que provee a GvSIG de capacidades de análisis Raster, el magnífico desarrollo Sextante que actualmente se compone de 210 módulos. Este proyecto incubado inicialmente en el proyecto Saga ha sido portado de C a Java y de ahi a GvSig para seguir creciendo, de forma muy rapida. En poco tiempo, al paso que va, será capaz de implementar gran número de los algoritmos en los que se basan los procesos del análisis raster.
Este programa desde hace más de un año ha sido liberado como Open Source y nos puede servir para complementar de alguna manera los demás tiene varios modulos geoestadisticos y un potente lenguaje de script para automatizar los procesos.
Creemos que esta aplicación es autocontenida en el disco duro funciona pero no lo hemos probado sobre un USB.
Servidores de Mapas, Bases de Datos espaciales, webmapping en general
Suite Apache, PHP, MySQL extrañamente no se ejecutan ni accediendo al arranque de los servicios directamente desde sus carpetas asi que procedemos a instalada otra suite "WAMP" que no "LAMP" y todo funciona co los cambios oportunos en los archivos de configuración, Tilecache, featureserver, etc.
Geoserver arranca perfectamente sobre un contenedor de serlets Jetty, cabría la posibilidad de instalar Toncat para instalar otros servidores de mapas, aunque seguramente se podrá hacer sobre Jetty, pero pasaria siempre por arrancar Geoserver. Como hemos mencionado anteriormente Mapserver no puede ser rulado al venir instalado en FWtools.
Tilecache y Featureserver aunque vienen a pelo funcionan perfectamente. Hemos instalado mapserver y funciona correctamente.
Otra opción podría ser instalar MS4W de suite con un batch adecuado para soportar los cambios de unidades ya que se trata de otra aplicación autocontenida. "WAMP" con un gran número de aplicaciones de cliente ligeros.
PostgreSQL+Postgis funciona perfectamente, aunque phpPgAdmin esta muy bien para gestionar la base de datos pero se echa de menos Pgadmin que es mucho más completita y tambien como no y como debe ser, autocontenida.
Por último lo que más se echa en falta para todo lo relacionado con el webmapping es un buen navegador, firefox, no vaya a ser que nos enchufemos al ordenata de un amigo o vaya a saber usted quien y tengamos que tirar con un explorer en el que seguramente algunas aplicaciones no rularán y que pude ser muy util para arrancar los distintos servidores y aplicaciones web, mediante marcadores en la barra de herramientas. En este sentido creo que la suite adolece de una buena documentación y que las aplicaciones vienen bastante a pelo con falta de ejemplos etc, por lo que un usuario novel no va a obtener mucha productividad de la misma.
Mientras he ido urgando en la misma me he puesto a ir complementándola con más aplicaciones que a mi al menos me son muy útiles, aparte como tengo bastante documentación dispersa por el disco duro y ejemplos de todas estas aplicaciones se me ha ocurrido hacer una suite arkegeomática y arkeosemántica así tendre de que berrerar en próximos post del blog.
De momento ya tengo una primera versión con aplicaciones webmapping customizadas que creo que están la "mar de chulas", así que será para ir colocándola por ahi en plan torrent, para los muleros,y en algún formato comprimido para los más ortodoxos.
Bueno con un poquito de trabajo a lo mejor a mediados de mes tenemos preparada una primera versión medianamente bien documentada. Le he dedicado un par de días y ya tengo montado una suite que descomprimida ocupa 2,4 Gbytes, pero bueno actualmente las memorias no cuestan tanto y tampoco es para ponerse en plan minimalista.
Publicado por varix en 2:19 Enlaces a esta entrada 0 comentarios
Etiquetas: Servidores de Mapas, Sig Open_Source
Publicado por varix en 5:00 Enlaces a esta entrada 0 comentarios
Etiquetas: GeoRSS
Una parte importante del volumen de información generada en una intervención arqueológica es de formato gráfico. Las fotos de los hallazgos "in situ" en su contexto arqueológico, de las distintas UE´s, Unidades de Excavación, etc. consumen una parte bastante significativa de la documentación del registro arqueológico. En tiempos de la fotografía analógica se solía realizar una tabla de datos exclusiva para esta parte de la documentación, que se relacionaba con los objetos/artefactos/productos o con las unidades de excavación y que eran almacenadas en un modelo RDBMS en el mejor de los casos.
Con la aparición de la fotografía digital la creación de una tabla de datos exclusiva para este tipo de documentación gráfico/fotográfica resulta cuanto menos redundante y/o recurrente al registrar las mismas una serie de datos respecto a la tomas fotográficas, que en gran medida cubren estas necesidades y que son registrados en la cabecera de los ficheros en formato EXIF.
Si bien existen cámaras fotográficas de relativamente bajo precio que incluyen un chipset que permite la realización de lecturas GPS a través de la cámara fotográfica y por tanto de la georeferenciación de las mismas, en aras de optimizar recursos, y de prolongar la vida de uso efectivo de nuestros dispositivos, el recurrir a una solución software nos permite obtener el mismo resultado.
Así que buscando por la red hemos encontrado la siguiente aplicación, GPicSync, que mediante Python auna dos herramientas Open Source, Exiftool, una herramienta que nos permite escribir y leer la cabezera de ficheros de imágen, audio y video y GPSBabel programa que nos permite el acceso a dispositivos GPS de distintas marcas, asi como la lectura/escritura de distintos formatos de fichero GPS.
GPicSync es el acrónimo para G:GPS Pic:Pictures Sync:Synchronization. Creo que queda claro el cometido de este software Open Source
Los pasos previos, a la utilización de este software pasa por la configuración horaria de la cámara en UTC, Universal Time Co-ordinated, que permitirá sincronizar las fotografías con los datos GPS, para el caso de la Península Ibérica esta suele ser una o dos horas menos dependiendo de que estemos en un horario de invierno o de verano, ese constructo artificial dirigido al ahorro de energía y que nos han colado desde la crisis del petróleo de 1973. También podemos usar el tiempo local para lo cual tendremos que cambiar este parámetro en el dispositivo GPS.
Una segunda parte del proceso implica la descarga de los waypoint y de los tracks desde nuestro GPS y guardarlos en formato GPX, estándar XML para el intercambio de ficheros GPS, para lo cual podremos utilizar GPSBabel a través de la interfaz gráfica que nos proveee Qgis. Una vez realizados estos pasos podremos cargar tanto los ficheros de imágenes como los de GPS en Gpicsync y que nos permitirá a parte de georeferenciar las fotografías, su exportación a formato KML/KMZ para su visualización en Gearth, en Gmaps, en Flirck y otros mediante la geocodificación vía Servicios WEB de http://geonames.org.
Se incluyen así mismo una serie de herramientas muy útiles, que nos permiten leer los ficheros EXIF así como editarlos con lo que se pueden georeferenciar manualmente las fotografías si disponemos de las coordenadas de las mismas. El ejemplo que se muestra no es precisamente arqueológico o aunque sus usos en la documentación arqueológica son más que diversos y que nos permiten automatizar una serie de procesos evitando en gran medida errores humanos.
Es innegable la gran utilidad que se le puede dar a la hora de realizar prospecciones arqueológicas, posibilitando la georeferenciación de las imágenes de los hallazgos y evitando posibles errores, si tenemos dos registros, uno automático el del GPS y otro idefectiblemente manual al que hay que asociar la imagen con el número de punto tomado con el GPS. La realización automática de esta operación soslaya en gran medida el cometer errores, a la vez que nos permite contar con una base de datos de imágenes georeferenciadas que pueden ser cruzadas con otros datos del mismo tipo a parte de su visualización en un entorno de Mapping vía KML o GeoRSS. La buena costumbre de la toma fotográficas en el contexto de una excavación con el GPS al lado y en ON posibilitaría una organización inequivoca de este material fotográfico a nivel de UE´s, contextos mínimos, unidades estratigráficas, en este caso si se dispone de un GPS de precisión centimétrica, etc. que nos permitirían incluso de prescindir de la tablilla de turno para la descripción de las mismas.
Ejemplo de fichero de imagen georeferenciado en su cabezera.
File Name : S6300897.JPG
Directory : D:\web_colaborativa\fotos_GPS
File Size : 282254
File Modification Date/Time : 2008:02:07 14:50:50
Focal Length In 35mm Format : 81
Scene Capture Type : 0
Saturation : 65535
GPS Longitude Ref : W
GPS Altitude : 638
Thumbnail Offset : 31216
Thumbnail Length : 4012
Encoding Process : 0
Y Cb Cr Sub Sampling : 2 1
GPS Latitude : 40.35715
GPS Longitude : -4.3858
GPS Position : 40.35715 -4.3858
Scale Factor To 35mm Equivalent : 5.91240875912409
Shutter Speed : 0.002857142857
Thumbnail Image : (Binary data 4012 bytes, use -b option to extract)
Circle Of Confusion : 0.00508189840266015
Field Of View : 25.0576365835832
Focal Length : 81
Hyperfocal Distance : 8.79358296787338
Light Value : 12.9139178625746
Publicado por varix en 12:53 Enlaces a esta entrada 0 comentarios
Existe el tópico o el dicho generalizado y repetido a lo largo del siglo pasado que una imagen vale más que mil palabras, si bien es cierto que el número de "palabras" o conceptos que nos puede transmitir una imagen están en función del observador y de los conocimientos que este "posea" sobre el objeto o composición de objetos observados, en una visión objetiva de los mismos.
Así mismo, diferirán las visiones subjetivas que la visualización del objeto puedan evocar a los distintos observadores fruto de distintas experiencias o experienciaciones que conforman al sujeto como un "yo" débil.
Esto viene a cuento por el video que tenemos en el panel de la izquierda intitulado Servicios WMS y Arqueología donde se hace un repaso a las operaciones implicadas en el estándar WMS de OGC. Si no se le añade un texto explicativo al mismo, a pesar de contener casi 15.000 imágenes en secuencia animada, acompañadas de una música cañera, un observador cualquiera puede ver e interpretar que lo que esta viendo son una serie de mapas accedidos a través de la WEB, así como de una serie de ficheros XML y esto cuando conozca la gramática de este tipo de ficheros. Bueno, pues este es uno de los casos en los que a lo mejor casi mil palabras valen más que 15.000 imágenes, o mejor, cuando estas palabras dan un contenido cierto, objetivo y dirigido a las mismas. Por tanto hemos considerado oportuno hacer una entrada en el blog en que se expliquen los procesos que se van sucediendo en el video en el que se trata de hacer entender la visualización de datos geográficos a partir de WMS tomando como partida el sitio http://arkegeomatica.es, hermano mayor de este Blog.
Para ello y partiendo de una distribución regional de asentamientos, los sempiternos castros zamoranos y tomando como marco de entrada una respuesta Getmap se intenta explicar que esta es consecuencia de una petición anterior a un Servidor de Mapas y que puede ser realizada directamente desde la barra del browser o navegador web. Creo que se entiende que la imagen generada es una respuesta al vuelo de dicha petición y por lo tanto no es una imágen en un formato gráfico determinado, es decir, estática, dependiendo las mismas de las peticiones realizadas y los parámetros utilizados, formato de imagen, capas a visualizar, limites geográficos o proyección en la que queramos que se genere la misma.
En un segundo paso se obtiene el documento de la información residente o hacía la que apunta el servidor mediante una petición GetCapabilities, visualizándose el documento. Se centra la visualización sobre las capas arqueológicas para relacionarlo con la petición GetMap anterior que es precisamente la capa que se esta visualizando. Se aprovecha para realizar una petición GetCapabilities sobre las capas habilitadas como WFS aprovechando que es el mismo tipo de operación para ver las capacidades que tiene el servidor implementadas para WFS, recuperando la capa como un archivo GML en sus especificaciones 2 y 3 que serán utilizadas en un vídeo posterior.
Trás mezclar churras con merinas nos centramos en los servcios WMS propiamente dichos para introducirnos en la noción de cliente ligero genérico y por tanto de acceso ubicuo a la información arqueológica utilizando para ello el propio servidor como cliente con un desarrollo en html que nos permite la creación de un cliente básico. Utilizando el propio html centramos las vistas a distintas escalas para poder facilitar la visualización de la información. En esta parte se desarrolla la tercera operación inplicada en el estándar WMS, GetFeatureInfo para ello se hace una consulta a una de las entidades puntuales visualizadas, asi como peticiones Getmap a distintos servidores.
Como último paso y ya que los anteriores se han realizado sobre el mismo Host hemos procedido a integrar la información de nuestro servidor en el marco de un "Clearinghouse" de estas características, el portal IDEE, lo que nos sirve para explicitar las distintas escalas de integración de este tipo de servicios. Para ello y mediante GetCapabilities integramos distintas fuentes de información disponibles, ortofotos de la zona de estudio, si bien el diálogo entre ambos servidores se resuelve de forma correcta, al realizar el GetMap el cliente sobre el nuevo servidor integrado la respuesta no se produce. Bueno prescindiendo del mismo integramos nuestra información arqueológica que dentro de una estructura de una IDE es considerada como información
temática, trás un "diálogo" que se demora en exceso, no nos ocurre con otros servidores, la operación GetCapabilities se realiza con éxito. Procediendo al Getmap desde el cliente para visualizar la información, y a GetFeatureInfo para consultar la información asociada de la entidad puntual sobre la que nos hemos centrado. La petición Getmap a varias capas que creemos de interés nos permiten apreciar a simple vistas las estructuras asociadas ha dicha entidad puntual, un castro de la II Edad del Hierro, que queda bien caracterizada por la consulta anteriormente realizada con la operación GetFeatureInfo.
Por último se introduce a la noción de cliente pesado, para ello hemos utilizado una herramienta ampliamente difundida como es Google Earth en el que se visualizan la información de la capa de esta distribución de asentamientos mediante GetMap. En otros videos y utilizando estándares OGC para recuperar la información y utilizando la navaja suiza que es OGR transformaremos esta información para que pueda ser consultable en este cliente.
Si bien hemos obviado la operación GetLegendGraphic, creemos que queda suscintamente claro el funcionamiento de este estándar, que define la visualización de información geográfica vía internet. En este caso, sí que las imágenes valen más que mil palabras, máxime si tenemos cierta capacidad para la fotointerpretación visual de las fotografías aéreas de fondo asociadas a los elementos puntuales de los castros, que nos permiten una primera caracterización de multiples realidades en las que se inscriben. La composición de información visual a traves de este estándar de distintas capas arqueológicas, en muchas ocasiones sirven para sintetizar realidades pasadas, de mejor manera que pesados tochos de farragosa literatura gris. O eso, es al menos lo que yo pienso, aunque también dependerá en gran medida y estará en función de la conformación de los distintos yo´s que observan y se dedican al noble arte de la hermeneutica para aproximarse a las realidades pasadas.
Publicado por varix en 13:33 Enlaces a esta entrada 0 comentarios
Sin lugar a dudas una de las grandes ventajas que proporciona una IDE es la posibilidad de acceder a la información arqueológica como fuente primaria de datos sin ningún tipo de elaboraciones, permitiendo al interesado que accede a las mismas la posibilidad de probar nuevos modelos sobre los datos almacenados en los contenedores de datos alojados en ellas. En http://www.casamontero.org se tiene la intención de relacionar toda la información planimétrica de los pozos que constituyen este yacimiento único, para ilustrar las actividades extractivas de aprovisionamiento de silex en un periodo dilatado de tiempo, con la abundante información empirica que han aportado estos profundos buracos.
En la siguiente dirección se puede acceder a esta información planimétrica en un formato cerrado *.DWG. Partiendo de este fichero y mediante su exportación a una base de datos espacial, para poder transformar las polilíneas en poligonos cerrados, hemos preparado el siguiente fichero para visualizar y consultar alguna de las características de este yacimiento como WMS y WFS [1].
Mediante el conector disponible en GvSIG para acceder a este tipo de ficheros hemos podido comprobar que en el mismo disponemos de la información georeferenciada de los buracos como entidades de polilíneas 3D, que envidentemente han de ser transformadas a un fichero *.shp si queremos obtener entidades cerradas de tipo poligonal, mediante el uso de Postgis, sobre las que poder realizar posteriormente las consultas. Al ser estas polílineas en 3D, disponemos tambien de un campo en el archivo de CAD donde se han registrado la altura de todos los pozos que constituyen la mina neolítica de Casa Montero lo que nos permite la creación de un Modelo de Elevaciones relativamente preciso de todo el yacimiento así como otra serie de productos derivados.
La información relativa a los contextos culturales con los que se relaciona cada pozo, consignada como no podía ser de otra forma en la capa Layer es relativamente pobre, lo que no nos permite, posiblemente por que se trate del fichero de registro topográfico, aventurar sobre la utilización temporal de zona o zonas del yacimiento a partir de este fichero. Esta evolución en la formación del yacimiento así como las relaciones espaciales establecidas entre los distintos pozos podrá ser estudiada por cada cual una vez los datos de localización de los elementos arqueológicos que conforman cada pozo con su registro formen una entidad arqueológica individual que junto a otras permitan la formación de grupos que puedan responder a las preguntas que se tenga ha bien plantear. La posibilidad de que otros yacimientos cercanos de los cuales hay unos cuantos, puedan tener alguna relación con este yacimiento en algunas de sus etapas quedaría mejor resuelta si siguiendo el ejemplo de este sitio cabiera la posibilidad de disponer asi mismo de sus datos primarios.
Así mismo podemos acceder a través de WFS a las actuaciones arqueológicas realizadas por la empresa inglesa Oxford Archaeology que están muy en la línea de una Arqueología Abierta. De momento son sólo los datos de las actuaciones pero menos da una piedra y todo se andará. En la siguiente dirección pueden verse la distribución de estas actuaciones sobre Openlayers. La imagen de la entrada, el mismo repositorio de datos accedido desde GvSIG.
http://mapdata.thehumanjourney.net/cgi-bin/mapservwfs.cgi?
Por último, trás intenso rastreo puede ser consultados via Webmapping un yacimiento neolítico del área alicantina, el documento Getcapabilities no resulta demasiado dificil obtenerlo. La dirección la consignada más abajo, la Web del proyecto aqui.
[1] Al pesar demasiado, más de 25 MB hemos prescindido de colgarlo en el servidor, de momento, al tenerlo demasiado "petao". Cuando hagamos una pequeña limpieza del mismo subiremos una serie significativa de yacimientos madrileños bastante significados.
Publicado por varix en 12:07 Enlaces a esta entrada 0 comentarios
Etiquetas: IDEArk, OGC, WFS
Publicado por varix en 3:45 Enlaces a esta entrada 0 comentarios
Publicado por varix en 14:43 Enlaces a esta entrada 0 comentarios
Etiquetas: Cygwin, Sig Open_Source, Tutoriales
Publicado por varix en 12:05 Enlaces a esta entrada 0 comentarios
Creación de Modelos de Elevaciones del proyecto PN...
Georeferenciando documentación fotográfica en cont...
Operaciones implicitas en el estándar WMS: Una ima...

References: resolución

 resolución 
 resolución 
 resolución 
 resolución 
 resolución