Compilar Openlayers 3 en Windows, sin morir en el intento

Si eres programador, trabajas sobre SIG, y por desgracia, tienes que hacer clientes SIG Web, creo que conocerás la solución “Openlayers” que nos hace la vida mas sencilla a todos los que nos peleamos a diario con esto…

Openlayers 3 Logo

Openlayers 3

El salto de la rama 2.x a la 3.x ha sido muy dura. Incluso compilar, desde el código fuente, la rama 3.x es bastante complicado (si vemos como se trabajaba en la version 2.x). Y recompilar el código es una necesidad cuando no paran de encontrarse errores y pequeños fallos (recordemos que estamos en una beta). Errores como por ejemplo el que se comenta en este hilo respecto del manejo de las capas “ImageStatic” como fuente de las imágenes.

Bueno pues manos a la obra.

Requisitos:

Os dejo una lista, instala todos por defecto y que estén en el disponibles en el PATH:

  • Git
  • Node.js
  • Python 2.6/2.7
  • Java 7 (yo usé el JRE)

Una cosa muy curiosa es que Python se tiene que instalar en “C:\Python27” o “C:\Python26” o no funcionará este sistema.

Git haz tu trabajo

Nos traemos el repositorio entero de OL3 desde Github (te recomiendo una ruta corta, tipo “C:\ol3” que es la que voy a usar a lo largo del manual):

git clone https://github.com/openlayers/ol3.git

Esto tardará un rato… es la hora del café!

Dependencias… y algo de magia

Bien, ahora comprobamos si tenemos todo lo que necesitamos:

C:\ol3>build.py checkdeps
Program "./node_modules/.bin/cleancss" seems to be MISSING.
Program "git.exe" seems to be present.
Program "C:Python27\Scripts\gjslint.exe" seems to be MISSING.
Program "C:\Program Files\jsdoc3\jsdoc.cmd" seems to be MISSING.
Program "./node_modules/.bin/jshint" seems to be MISSING.
Program "C:Python27\python.exe" seems to be MISSING.
Program "C:phantomjs-1.9.7-windows\phantomjs.exe" seems to be MISSING.
For certain targets all above programs need to be present.

Fue bonito mientras duró (no iba a funcionar a la primera 🙂

Pero vamos a realiza un par de comandos que nos van a arreglar el asunto:

npm install

Instalará bastantes cosas… otro café?. Por último:

C:\ol3>c:\Python27\Scripts\easy_install.exe http://closure-linter.googlecode.com/files/closure_linter-latest.tar.gz
C:\ol3>c:\Python27\Scripts\easy_install.exe pystache 

Y… redoble de tambores:

C:\ol3>build.py checkdeps
Program ".\node_modules\.bin\cleancss.cmd" seems to be present.
Program "git.exe" seems to be present.
Program "gjslint.exe" seems to be present.
Program ".\node_modules\.bin\jsdoc.cmd" seems to be present.
Program ".\node_modules\.bin\jshint.cmd" seems to be present.
Program "python.exe" seems to be present.
Program ".\node_modules\.bin\phantomjs.cmd" seems to be present.
For certain targets all above programs need to be present.

Y ahora la parte más difícil…

… Compilar. Hay mucho fallos en la versión para Windows de los scripts, por lo que hay que bucear un montón por los foros de GitHub para encontrar la solución a problemas en los scripts (rutas largas, directorios que no existen, rutas linux, etc…) yo lo he conseguido, con los scripts siguientes:

Scripts ol3-fix

Descomprime en el raíz del repositorio de Openlayers, y ya puedes lanzar el build.

C:\ol3>build
2014-10-23 11:57:44,256 build/ol.css: .\node_modules\.bin\cleancss.cmd css/ol.css
2014-10-23 11:57:44,424 build/ol.js: node tasks/build.js config/ol.json build/ol.js
info ol Parsing dependencies
info ol Compiling 333 sources
2014-10-23 11:58:06,733 build/ol.js: uncompressed:   406514 bytes
2014-10-23 11:58:06,733 build/ol.js:   compressed:   121282 bytes, (saved 70.17%)
2014-10-23 11:58:06,734 build/ol-debug.js: node tasks/build.js config/ol-debug.json build/ol-debug.js
info ol Parsing dependencies
info ol No compile options found.  Concatenating 333 sources
2014-10-23 11:58:10,434 build/ol-debug.js: uncompressed:  3276814 bytes
2014-10-23 11:58:10,436 build/ol-debug.js:   compressed:   603658 bytes, (saved 81.58%)

Sólo busca en el directorio “build” por las versiones de “debug” y “compressed”.

Referencias:

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: