HOW TO: Unir mucho shapefiles en un solo shapefile con GDAL en Windows

Si trabajas con cartografía es normal que te den un montón de shapefiles como respuesta a “necesito el vectorial de una zona”, y en algunos casos (en el mío) no es manejable cuando su número es mayor de 1000 ficheros.

Para unir todos los ficheros, y de paso borrando las geometrías repetidas, podemos usar la fabulosa herramienta ogr2ogr del paquete GDAL, que puedes obtener desde el instalador de la OSGeo4W que nos permite instalar de manera sencilla GDAL compilado para Windows. Creo que esta parte es suficientemente sencilla como para explicarla, pero si hay dudas, deja un comentario.

Una vez instalado, entramos en “Inicio > OSGeo4W > OSGeo4W Shell”, y vamos a la ruta donde tenemos la montonera de shapefiles. Y creamos el siguiente fichero “.bat” dentro del mismo directorio:

@echo off
mkdir merged
set counter=0

setlocal ENABLEDELAYEDEXPANSION

for %%f in (*.shp) do (
	if not exist merged\mergedFilter.shp (
		echo Uniendo %%f
		ogr2ogr -f "ESRI Shapefile" merged\mergedFilter.shp %%f
	) else (
		echo Uniendo %%f - Iteracion !counter!
		ogr2ogr -f "ESRI Shapefile" -update -append merged\mergedFilter.shp %%f  
		if !counter! GTR 500 (
			echo Simplificando %%f
			ogr2ogr -f "ESRI Shapefile" merged\mergedFilterAux.shp merged\mergedFilter.shp -sql "SELECT * FROM mergedFilter GROUP BY id_parcela" -dialect sqlite
			del merged\mergedFilter.*
			ren merged\mergedFilterAux.* mergedFilter.*
			set counter=0
		)
	)
	set /A counter=counter+1
)

Este código tendrás que adaptarlo a tus necesidades, por ejemplo lo nombres de los fichero y demas, pero te cuento lo que hace:

  • Va leyendo todos los fichero del directorio donde se ejecuta
  • Une el fichero con un fichero que se va creando dentro de “merge/mergedFilter.shp”
  • Cada 500 uniones, borra todas las features que tengan el mismo “id” (en tu caso puede que sea diferente y tengas que usarlo comprobando la geometria).

Le das unas horas, y al final tendrás un fichero Shapefile gigante… pero al menos uno.

Please follow and like us:

Como usar “shapelib.dll” para entornos x64 de Windows

Vaya follón… y vaya trabajo. Encontrar una “shapelib.dll” en x64 para un proyecto en Windows.

Si queréis usar esta magnifica librería (si no sabes que hace, casi seguro que no la necesitas) en vuestros proyectos en sistemas operativos de Windows os tocará recompilar el código ya que no hay un binario directamente publicado en ningún sitio (en linux si está… en Windows son mas vagos 😛 ).

Os voy a solucionar el problema, y os pasaré el binario compilado, para equipos con entornos x64 de Windows.

[Shapelib 1.2.10 para Win x64]

Un saludo.

Please follow and like us:

Openlayers, aplicando estilos propios a ArcGIS Server WMS

Una de funcionalidad muy interesante que nos ofrecen los servidores de mapas, con el protocolo “WMS” y mediante la petición “GetMap“, es poder aplicar nuestro propio “estilo” a las capas que nos ofrecen, solo suministrándole un archivo donde se detalla como cambiar el estilo visual de las capas que nos muestra mediante el estándar “Style Language Descriptor” o “SLD” para los amigos. Este estándar no deja de ser un “XML” con una estructura y etiquetas propias. No es muy complejo de entender. Además hay hasta editores para hacerte la vida mucho más sencilla escribiendo SLD, como este, que es totalmente visual.

Para que entendáis, que significa esto, si pedimos un capa a un servidor, de una cierta zona, podría devolvernos esto:

Capa antes de aplicar un estilo

Pero no nos gusta nada su presentación, y tras hacer un poco de magia, obtendríamos algo así:

Capa despues del estilo

Capa después de aplicar un estilo

Normalmente estos estilos están definidos en el servidor de mapas, y el usuario que consume dicho servicio le indica que estilo utilizar. Pero para completar un poco esta funcionalidad, se permitió que el usuario indique que estilo usar, dando en la petición una URL a un fichero de estilos, como por ejemplo:

http://servidor/GetMap?TRANSPARENT=true&LAYERS=RiverBasinDistrict&FORMAT=image%2Fpng&TILED=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-1.69189453125,41.21172151054787,1.12060546875,43.29320031385282&WIDTH=256&HEIGHT=256&SLD=http://servidorPublico/misestilos.sld&STYLES=estilo

La parte en negrita, indica donde cambiamos el estilo, indicante el fichero de estilos, y el estilo a usar (que podría estar definido en dicho fichero o no). Si indicamos un estilo que no esta definido ni en el servidor ni en el fichero, obtendremos un bonito error, o obtendremos la capa con el estilo por defecto.

Existen grandes ejemplos para entender este capacidad, como por ejemplo esta web, donde se colorean los polígonos que representan los países según el nombre de dicho país. Bonito, y descriptivo.

Pero hay un problema, como casi con todos estos estándar. Cada uno lo implementa a su modo. Por ejemplo si vemos un fichero de estilo de un servidor de mapas “Geoserver”, este tiene una extensión “sld”, y una sintaxis muy relajada. ¿Pero y si trabajamos con ArcGIS Server WMS?, pues no es igual…

Ahora bien, tras esta larga introducción, no centramos en nuestro caso actual.

  • Openlayers, en mi caso, se uso la versión 2.7, con algunos retoques que no modificaban esta funcionalidad.
  • Servidor ArcGIS Server WMS sirviendo unas capas con un estilo horrible. Para estas pruebas, sólo se sabía que era ArcGIS, y aún no sabemos exactamente que versión exacta es.
  • Hojas de estilo sacadas de un servidor Geoserver en formato SLD. La hoja de estilos tiene que estar almacenada en un servidor web donde el servidor de mapas tenga acceso, es decir que si no está en tu red, tiene que estar en un servidor web conectado a internet.

Si tratas de incluir en OpenLayers el estilo, nos encontramos esto:

wms_1 = new OpenLayers.Layer.WMS( "Capa"
		,url_wms_GIS
		,{
		    transparent:'true',
		    layers: 'capa',
		    styles: 'estilopoligono',
		    sld: 'http://servidorPublico/poligono.sld',
		    format:'image/png',
		    tiled: 'true'
		},
		{
		    'reproject': true,
		    buffer: 0
		}
	);

Y nuestro fichero de estilo, el cual esta alojado en la URL “http://servidorPublico/poligono.sld”:

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0"
	xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd"
	xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NamedLayer>
		<Name>capa</Name>
		<UserStyle>
			<Name>estilopoligono</Name>
			<Title>Estilo de un poligono</Title>
			<FeatureTypeStyle>
			<Rule>
				<PolygonSymbolizer>
					<Fill>
						<CssParameter name="fill">#995599</CssParameter>
						<CssParameter name="fill-opacity">0.3</CssParameter>
					</Fill>
					<Stroke>
						<CssParameter name="stroke">#000000</CssParameter>
						<CssParameter name="stroke-opacity">1</CssParameter>
					</Stroke>
				</PolygonSymbolizer>
			</Rule>
			</FeatureTypeStyle>
		</UserStyle>
	</NamedLayer>
</StyledLayerDescriptor>

Como puedes leer, en el fichero “sld” he incluido el nombre de la capa, y el nombre del estilo, y tienen que concordar con los escritos en Openlayers.

Todo parece correcto, pero al usarlo contra el servidor ArcGIS Server… esto no funciona, sencillamente te dice que el tipo de estilo no esta definido. ¡Mi gozo en un pozo!.

Pero no todo esta perdido, tras mucho mirar, y releer, me doy cuenta de lo de siempre, ArcGIS tiene “peculiaridades”, y es muy estricto, aunque gracias a dios, todo se encuentra muy bien documentado en su página de ayuda. Hay que remarcar, que la extensión pasa a ser “.xml”, y que ahora todas las etiquetas tiene el prefijo “sld”, aunque respeta el resto del estándar.

Hacemos unos cambios y ya tenemos la nueva versión:

<?xml version="1.0" encoding="UTF-8"?>
<sld:StyledLayerDescriptor version="1.0.0" xmlns="http://www.opengis.net/ogc" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">
	<sld:NamedLayer>
		<sld:Name>capa</sld:Name>
		<sld:UserStyle>
			<sld:Name>estilopoligono</sld:Name>
			<sld:Title>Estilo de un poligono</sld:Title>
			<sld:FeatureTypeStyle>
				<sld:Rule>
					<sld:PolygonSymbolizer>
						<sld:Fill>
							<sld:CssParameter name="fill">#995599</sld:CssParameter>
							<sld:CssParameter name="fill-opacity">0.2</sld:CssParameter>
						</sld:Fill>
						<sld:Stroke>
							<sld:CssParameter name="stroke">#0000FF</sld:CssParameter>
							<sld:CssParameter name="stroke-opacity">1</sld:CssParameter>
							<sld:CssParameter name="stroke-width">1</sld:CssParameter>
						</sld:Stroke>
					</sld:PolygonSymbolizer>
				</sld:Rule>
			</sld:FeatureTypeStyle>
		</sld:UserStyle>
	</sld:NamedLayer>
</sld:StyledLayerDescriptor>

Y tras todo esto, ya podremos disfrutar de poder manejar el estilo con el que un servidor remoto nos sirva las imágenes de su cartografía.

Please follow and like us:

Geoserver en entorno de producción (III): Configurando PostgreSQL y PostGIS [Mejorado]

No, no habéis vuelto al pasado. Rectificar es de sabios, y más aún cuando mejoras lo dicho. Y este post es exactamente esto, una corrección y una mejora a mi explicación de como instalar una base de datos libre espacial.

Tras empezar a meter datos en mi máquina con PostgreSQL y PostGIS, siguiendo el primer manual que os dejé, me he dado cuenta que esto no funcionaba muy bien, ya que inicialmente no se instalaba PostGIS hasta que no lanzaras un archivo SQL, y luego, fallaba al devolver algunos objetos vectoriales. Recordemos que todo estaba montado con los paquetes estándar de Ubuntu 9.10.

Bueno, tras leer, me di cuenta que la gente recomienda la versión 8.4 de PostgreSQL y la 1.4+ para PostGIS. Pero hay un problema muy gordo, ya que no hay paquete PostGIS para esta versión de PostgreSQL en los repositorio oficiales de Ubuntu. Maldita sea, toca recompilar.

Me mentalizo, tengo que coger el código fuente, y ponerme a compilar, pero por desgracia, la versión actual, 1.5, de PostGIS, tiene unas dependencias que no puedo cumplir (Ubuntu no tiene aún las librerias libgeos-3.1.1, si no las 3.1.0, para mi versión de Ubuntu) con librerías estables liberadas, por lo que usaré la versión 1.4.2, pero en cuanto salga esta versión de las librerías ya podré usar la 1.5 siguiendo este mismo manual.

  1. Empecemos, instalando la versión 8.4 de PostgreSQL:
    sudo aptitude install postgresql-8.4
    
  2. Volvemos a configurar el servidor PostgreSQL, siguiendo el antiguo manual, para darnos acceso remoto.
  3. Ahora nos instalamos unas cuantas librerías que necesitaremos más adelante:
    sudo apt-get install proj-bin libproj-dev gdal-bin postgresql-server-dev-8.4 libgdal-dev libgeos-dev build-essential
    # Esto puede tardar un poco... tómate un café...
    

    Ahora ya tenemos todas las herramientas necesarias.

  4. Como recomendación personal, os recomiendo instalar, opcionalmente el paquete “checkinstall” ya que nos permite crear un archivo .deb, desinstalable mediante “aptitude”, a partir de un ejecutable con su código fuente. Para obtenerlo ponemos:
    sudo apt-get install checkinstall
    
  5. Pasamos a bajar el código fuente de PostGIS de su web oficial. Os recuerdo que yo uso la versión 1.4.2, ya que no tengo ciertas librerías aun disponibles en la versión 9.10 (al menos en su versión estable), pero que si tienes una versión más antigua o la LTS, están portadas en esta web en su versión estable. Recordemos que vamos a instalar un servidor en producción y que la estabilidad es fundamental.
    sudo wget http://postgis.refractions.net/download/postgis-1.4.2.tar.gz
    sudo tar xvzf postgis-1.4.2.tar.gz
    cd postgis-1.4.2
    sudo ./configure
    sudo make
    sudo checkinstall -D
    # Le ponemos un nombre al paquete
    # que es como aparecerá en el listado
    # de "aptitude search"
    # y confirmamos
    
    # Solo en el caso que no hayas instalado 
    # el programa "checkinstall"
    sudo make install
    

    Rezamos porque no haya ningún problema de dependencias ni librerías, aunque en Ubuntu 9.10 no tuve ninguna.

  6. Pero tenemos un problema, ya que si usamos PgAdmin, nos damos cuenta que no hay ningún template (plantilla) creado para postgis. Si usas Windows, esta se crea al instalar PostGIS pero en linux se complica un poco. Sin esta plantilla, cada vez que se crea una nueva base de datos, tenemos que lanzarle varios SQL para incluir toda funcionalidad espacial, y dar permisos a ciertas columnas. Pero si tenemos la plantilla, solo tenemos que elegirla en el momento de la creación para tener todo esto.
    Vamos a crear la plantilla:

    sudo su postgres # Cambiamos al usuario de mantenimiento de PostgreSQL
    createdb -E UTF8 template_postgis # Creamos la base de datos
    createlang -d template_postgis plpgsql
    #
    psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE datname='template_postgis';" # La hago visible para su uso
    # Es importante remarcar que el fichero lwpostgis.sql ha cambiado de nombre a postgis.sql
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/postgis.sql # Creo todas las funciones/tablas para habilitar todo
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/spatial_ref_sys.sql
    #
    psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;" # Acceso a todo el mundo
    psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"
    # La dejamos fija ante cambios
    VACUUM FREEZE;
    

    Si todo ha ido bien, ahora al crear una base de datos nueva, veremos esto:

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

  7. Incluimos el “adminpack” como te expliqué en el antiguo manual.
  8. Para testar que todo ha ido bien, desde PgAdmin, abrimos una consulta SQL y escribimos esto:
    select postgis_lib_version();
    

    Y veremos algo así:

    Versión de PostGIS mediante SQL

    Versión de PostGIS mediante SQL

Como siempre, de donde he leido toda la información que os condenso en este post:

Please follow and like us:

Geoserver en entorno de producción (IV): Habilitando GDAL y su soporte para formatos

Esto se está haciendo eterno, pero desde luego esta costando mucho lograr todo lo que me he propuesto. En este caso, me voy a centrar en ampliar los tipos de datos que va a aceptar nuestro servidor de mapas. Y esto me ha dado dos días de guerra. Os recuerdo mi configuración: Ubuntu 9.10 Server, Geoserver 2.0.1 y Tomcat 6. También os recuerdo que si queréis empezar con una instalación limpia, hay 3 manuales anteriores que encontraréis más abajo.

En este caso, vamos a instalar las librerías necesarias para que nuestro Geoserver sea capaz de leer formatos soporta la librería GDAL, entre los que están ECW, MrSID, EHdr, DTED, rasters de ERDAS,  etc…

Importante: Por desgracia, en esta ampliación tendremos un problema con las licencias para utilizar ECW en nuestro servidor, ya que para usarlo hay que usar unas librerías de ERDAS bastante restrictivas, y tendremos que tener un licencia (obviamente de pago, es decir, comprada) para usarlo sin romper la licencia de sus librerías, que no permiten su uso libre en servidores de mapas de terceros. En este tutorial se explica como activar el soporte para ECW, pero contamos con que se tienen las licencias compradas de antemano.

Manos a la obra, empecemos por el principio:

  1. En versiones antiguas de Geoserver hay que instalar un plugin dentro del directorio “WEB_INF/lib” de Geoserver, el cual puedes encontrar aún, en la página de descargas de Geoserver, en el apartado “Extensions>GDAL“. En la versión 2.0.1, ya viene de serie, por lo que no hace falta hacer nada.

Bajar las librerías nativas de GDAL del proyecto “ImageIO-ext” en esta dirección, no tengo que decirte que busques la versión más moderna y para tu sistema operativo, bájate las “native-libraries“. Estas librerías son totalmente independientes de las que tengas instaladas en tu equipo. Es decir, si hay tenias GDAL instalado vía apt/aptitude o porque tu te las instalaras a mano, no interfieren con estas.

Actualización 10-08-21: De nuevo, las cosas han cambiado, ya que como todos sabemos, Java ahora pertenece al eje del mal, es decir Oracle. Y como no, ha tenido que cambiar todo de sitio. Las nuevas direcciones para encontrar las cosas son:

Todas estas librerías son para el GDAL 1.7.3, el cual es el que esta disponible en los repositorios de Ubuntu, en caso de no tenerlo, no se si funcionará, aunque imagino que tendrás que instalarlo a mano para desgracia de nuestros nervios.
cd /usr/lib/
sudo wget https://imageio-ext.dev.java.net/files/documents/7505/144611/imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
sudo tar -zxvf ./imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
./
./libNCSCnet.so
./libNCSEcwC.so.0.0.0
./libNCSCnet.so.0
./gdalinfo
./libNCSUtil.so.0.0.0
./libNCSCnet.so.0.0.0
./libgdal.so.1
./libNCSEcw.so.0.0.0
./libNCSUtil.so.0
./libgdal.so
./libNCSEcwC.so.0
./libosrjni.so
./libNCSUtil.so
./libNCSEcw.so.0
./libNCSEcw.so
./libNCSEcwC.so
./libgdalconstjni.so
./libgdaljni.so
./libogrjni.so
./libgdal.so.1.11.4

Como habrás notado, he bajado la versión con soporte ECW (solo para probar que funciona), y lo he instalado en la carpeta “/usr/lib”. Si miras los manuales de referencia, todos te dicen que estas librerías puedes instalarlas donde te de la gana y luego fijar una variable de entorno “LD_LIBRARY_PATH” a la ruta para que todo funcione. En mi caso, esto no funcionaba, y la única manera de lograr que funcionara, era instalando estas librerías aquí.

Esto es importante, ya que no tengo muy claro donde se tiene que instalar las librerías nativas del GDAL (en serio, es un follón). Ahora mismo si no las descomprimo tambien en; “/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64” (es decir, en el directorio de mi versión por defecto de Java, y con la arquitectura, en 64 bits en mi caso, pero podría ser en i386 también), no me funciona. Simplemente trata de descomprimir en el directorio JAVA primero, y luego intenta en el directorio de librerías.

  1. Bajar los datos para la GDAL. Este fichero contiene definiciones de proyección y datos que se necesitan para usar esta librería, esta puedes instalarla donde quieras para luego fijar la variable de entorno “GDAL_DATA” para que GDAL sepa encontrarlas.
    cd /usr/share/gdal-data/
    sudo wget https://imageio-ext.dev.java.net/files/documents/7505/137749/gdal_data-1.4.5.zip
    sudo unzip -o ./gdal_data-1.4.5.zip
    

    Ahora editamos el fichero “/etc/profiles” y añadimos la siguiente línea:

    export GDAL_DATA=/usr/share/gdal-data
    

    Y ya hemos instalado todo.

    Actualización 2-11-10: Según he aprendido a lo largo de mis andaduras con linux, el mejor sitio para poner las exportaciones de variables de entorno es en el fichero “/etc/environment“.

  2. Tendremos que reiniciar Tomcat, por seguridad de que refresque y ver reflejados los cambios. En alguna ocasión solo con recargar el Geoserver desde el “manager” de Tomcat me ha valido, pero no lo puedo asegurar.
  3. Ahora entramos en el interfaz Web de Geoserver, que usualmente está instalado en: http://tuservidor:8080/geoserver, y en el apartado “Almacenes de datos” pulsamos “Agregar nuevo almacén”, y tendremos que ver una lista parecida a esta:

    Formatos soportados tras instalar la extensión de GDAL

    Formatos soportados tras instalar la extensión de GDAL

  4. Importante: Parece que están surgiendo problemas con estas librerías y Tomcat, y puedes leer como “arreglarlo” en el siguiente post. Para saber si te ocurre, sólo tienes que tratar de crear un almacén con cualquiera de los nuevos tipos que han aparecido y te saldrá un error. No es muy complicado de arreglar pero asusta 🙂

Como siempre, aquí tienes todas las referencias, de donde he sacado sabiduría:

Please follow and like us:

Lista de clientes ligeros web, y libres, para SIG

Se que para muchos esto os sonará a chino, pero para los que trabajamos con estas cosas, nos vienen muy bien este tipo de listas que escribe la gente del mundillo.

Imaginaros, Google Maps, pero en chiquitito, para mostrar información geográfica encima, como por ejemplo la población, carreteras, caudal de agua de los rios, o simplemente donde estas. Hace unos años esto era ciencia ficción, pero ahora hay muchas soluciones para hacerlo, sin rompernos los cuernos contra el Ajax, javascript, etc… Y aunque existe la posibilidad de usar la API de un tercero (por ejemplo, Google Maps) aveces esto se queda muy corto.

En este caso es una lista de clientes ligeros web que esta escribiendo la gente de GeoTux sobre este tema. Es una gran lista donde no echo de menos ningun nombre (de hecho me han descubierto alguno). Si necesitas hacer un desarrollo sobre SIG, te recomiendo que le eches un ojo a esta lista, ya que seguro que te facilita la vida y no tendrás que reinventar la rueda.

Y también de regalo, si necesitas un documento donde te detallen todas las soluciones libres, para servidor de mapas, cliente web, cliente de escritorio, etc… el documento que necesitas está en OSGeo, donde te detallan todo en mayor detalle.

Please follow and like us: