geomatico @geomatico - Tumblr Blog

¿Quiénes somos Geomatico, la empresa de la web "1km"?

En 3 días, hemos pasado de ser conocidos sólo en el mundo del GIS y las aplicaciones geográficas a ser la “empresa de 1km.geomatico.es”, tras más de tres millones de visitas en un fin de semana. Para todos los que no habíais oído hablar de nosotros, somos una cooperativa galaico-catalana que llevamos 8 años desarrollando software geo de código libre para necesidades concretas de empresas y AAPP. Estamos especializados en movilidad (trabajamos por ejemplo para Transportes Metropolitanos de Barcelona, Siemens o el Puerto de Barcelona) pero también colaboramos con cualquier sector que necesite de las últimas tecnologías geo, como el medioambiental (Food Agriculture Organization de las Naciones Unidas). Podéis consultar nuestros proyectos en nuestra página web geomati.co - por ahora, pues estamos en proceso de cambiar de nombre a geomatico.es -.

La idea de 1km.geomatico.es surgió con la intención de ayudar con una pequeña aportación en estos tiempos difíciles. No queríamos sacar ningún provecho económico de ello y contamos con la inestimable ayuda (también desinteresada) de Mapbox para dar servicio al enorme tráfico (casi 20.000 usuarios simultáneos durante el sábado) que fue un auténtico reto. Os agradecemos muchísimo el interés y vamos a intentar seguir aportando nuevas funcionalidades que os ayuden durante el desconfinamiento. Mucho ánimo a todos, pronto podremos vernos aunque sea con un poco de distancia.

Contacto: [email protected]

One kilometer from home

On March the 23rd, after five weeks of COVID-19 lockdown, president Sanchez announced that Spain will begin easing restrictions. In this first attempt at loosening measures across the country, children under the age of 14 will now be allowed to go outside of their homes for one hour a day, accompanied by an adult. The measure limits travel to no further than 1 kilometer from home. But just how far is 1 kilometer? To help navigate these new rules, Geomatico, a Spanish GIS company, developed a non-profit web application using donated tools from Mapbox that allows adults and children to visualize a 1 kilometer radius around their home.

In ten days, 1km.geomatico.es has become a reference for individuals and families throughout Spain looking to safely leave their house for the first time in over a month. Thanks in part to Mapbox’s support, the team has been able to deliver this mapping service for free to over 7 million users in multiple languages and municipal districts.

Want to see what 1 kilometer compliance looks like where you live? Check out the application here.

1km.geomatico.es en TV3

https://www.ccma.cat/324/els-nens-no-podran-anar-a-mes-dun-quilometre-de-casa-com-es-pot-calcular/noticia/3007207/

#1km #COVID19 #tv3

1km.geomatico.es en la Cadena SER

https://cadenaser.com/ser/2020/04/24/sociedad/1587726752_687364.html

#1km COVID19

1km.geomatico.es en Huffington Post

https://www.huffingtonpost.es/entry/cuanto-mide-un-kilometro-casa_es_5ea2e770c5b6f963981378b3?utm_hp_ref=es-homepage

1km.geomatico.es en La Sexta

https://www.lasexta.com/noticias/nacional/mapa-interactivo-comprueba-distancia-maxima-que-puedes-recorrer-menor-domicilio_202004245ea33b3564242d00016ea253.html

#covid #1km

1km.geomatico.es en La Voz de Galicia

https://www.lavozdegalicia.es/noticia/sociedad/2020/04/24/aplicacion-permite-saber-donde-podran-pasear-ninos/00031587723256310253753.htm

#1km covid

Herramienta de consola para la descarga desde el ATOM del Catastro

En geomati.co llevamos tiempo usando los datos del Catastro para utilizarlos en visualizaciones 3D con MapboxGL. Lo que hacemos es descargarnos la información desde los servicios INSPIRE del Catastro, exactamente desde su servicios ATOM.

Para alguna demo que teníamos preparada, utilizábamos scripts que descargaban directamente los datos desde las URL. El problema es que el servicio ATOM no es precisamente un servicio fácil de usar con los nuevos navegadores.

Así que se le ocurrió a nuestro compañero Francisco Sampayo la idea de desarrollar una herramienta que facilitará esta descarga.

CatastroInspireDownloader es una herramienta desarrollada en Python que permite desde la consola, de una manera cómoda, realizar las descargas de los datos de los servicios ATOM y los empaqueta en GeoPackage.

Como la usamos.

Lo primero será instalarla en nuestro equipo:

pip install CatastroInspireDownloader

Tras la instalación tendremos acceso a la herramienta desde la consola y podremos lanzar su ejecución de la manera:

cidownloader -p 36 -m 62 --srs 25829 --filename a_illa

Esto generará un archivo a_illa.gpkg en la carpeta donde hayamos ejecutado el comando con las parcelas, edificios y direcciones descargadas del catastro.

El código de la herramienta lo tenéis en:

https://github.com/geomatico/cidownloader

Colaboraciones y sugerencias, ¡serán bienvenidas!.

Saludos.

Querying multiple layers in a single query with GeoServer?

Our problem, get multiple features filtered from multiple different layers using WFS.

Let's work with the topp data coming by default in GeoServer. A matter of taste.

To apply a single CQL_filter on a WFS layer it’s simple. We have the "unknown" ;-) topp:tasmania_water_bodies published in one Demo GeoServer (thanks GeoSolutions ;-)) and we want to get the features where the area is greater than 1066494066 square meters, so we can make the next petition to the server

https://demo.geo-solutions.it/geoserver/wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&typeNames=topp:tasmania_water_bodies&propertyName=&cql_filter=AREA<1066494066&outputFormat=application/json

Easy! We'll get 4 features that satisfy filters. The syntax is clear, we must use typeNames=topp:tasmania_water_bodies and cql_filter=AREA<1066494066 in the petition.

But, how we must do if we want get features from two or more layers at the same time?.

If we get at the same time the features type Alley from the topp:tasmania_roads layer with the topp:tasmania_water_bodies features filtered before, we must use similar request but separating the typeNames in this way:

typeNames=(topp:tasmania_water_bodies)(topp:tasmania_roads)

and setting the associated CQL filters ordered respect the typenames:

cql_filter=AREA<1066494066;TYPE='alley'

https://demo.geo-solutions.it/geoserver/wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&typeNames=(topp:tasmania_water_bodies)(topp:tasmania_roads)&propertyName=&cql_filter=AREA<1066494066;TYPE='alley'&outputFormat=application/json

And, what about the propertyName?. Using the propertyName parameter on the WFS petition we can filter the returned feature properties as we want. This parameter is important to reduce the response's size getting only the properties we are interested in.

In our example, we can get only the CNTRY_NAME of the topp:tasmania_water_bodies and the TYPE of the topp:tasmania_roads.

In this case the request will be:

https://demo.geo-solutions.it/geoserver/wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&typeNames=(topp:tasmania_water_bodies)(topp:tasmania_roads)&propertyName=(CNTRY_NAME)(TYPE)&cql_filter=AREA%3C1066494066;TYPE=%27alley%27&outputFormat=application/json

Michogar's GIST

Enjoy!!.

#GeoServer

Sensor Widgets: monitor your real-time sensor data on the web

Publish your sensor data via standard protocols and make it instantly available on your website through Open Source, 100% Javascript widgets.

You gather a lot of sensor information and you store it in a database. Why not supply it real-time to your clients through the web, or to your employees on an intranet? The SOS protocol allows you to publish it in a standard way, and our Sensor Widgets automagically show the current value through many elegant graphical components: bearing, gauge, grid, map, panel, progress bar, table, thermometer, timechart, windrose. Each one is completely extensible, configurable through a wizard and via CSS, and totally Open Source (MIT license).

The Port of Barcelona and geomati.co developed the Sensor Widgets library on 2014-2015 to publish and analyze many years of data collected by the 179 sensors of the meteorological station network of the Port. An Oracle database and a 52º North SOS server were used to serve it, but the Sensor Widgets can be configured to display any other SOS 2.0 data, as they are pure Javascript and rely on standard protocols.

Demo and examples: http://sensors.fonts.cat

Make your own widget: http://sensors.fonts.cat/wizard/

Code repository: https://github.com/oscarfonts/sensor-widgets

Contact: Oscar Fonts ([email protected])

#sensors

Noves condicions d'ús, ara més senzilles i obertes

Per tal de generar valor afegit a partir de la informació cartogràfica, geològica i geofísica, l'ICGC ha actualitzat les condicions d'ús de la informació que produeix o n'és propietari.

Concretament, les noves condicions es basen en la llicència Creative Commons de Reconeixement 4.0 Internacional (CC BY 4.0), que permeten la reutilització de la informació cartogràfica, geològica i geofísica per a qualsevol objectiu lícit, especialment la reproducció i divulgació amb qualsevol mitjà, i la creació de productes o serveis d'informació amb valor afegit, simplement indicant l'autoria de la font (i aplicant els altres termes definits en les condicions i en el CC BY 4.0).

Web ICC

---

Quin gran moment. Després de tants anys, això s'ha de celebrar!!! Ara ja no hi ha excusa per (re)utilitzar la informació de formes creatives. :)

Fins dijous! Oscar Fonts

#icc #dades #obertes

ol3-layerswitcher in Bower

In collaboration with Matt Walker, now you can install the ol3-layerswitcher from Bower:

bower install ol3-layerswitcher --save

Easy!

GeoTalleres: talleres con documentación "open source"

Siempre tenemos menos tiempo del que necesitamos para hacer todo lo que queremos hacer, y cuando lo que queremos hacer es un taller hay algo que se queda a menudo fuera: los materiales que se entregan. Nos preocupamos de que los ejercicios funcionen, de tener un plan B offline por si fallara la conexión y de cientos de detalles, pero luego al final del taller viene siempre la misma pregunta

¿Hay documentación de todo esto que nos estás enseñando?

Y en muchos casos no la hay. Tras pasar repetidas veces por la misma experiencia nos hemos decidido a poner solución al problema aplicando las mismas dinámicas open source con las que trabajamos. GeoTalleres Consecuencia de ello es el proyecto GeoTalleres, un repositorio con materiales para la realización de talleres sobre tecnologías relacionadas con el ámbito geoespacial. El proyecto se encuentra todavía en formación y a día de hoy se esperan más contribuciones importantes, pero ya contiene una cantidad de documentación importante, como puede comprobarse aquí. El objetivo es regirse por unas normas sencillas con la finalidad de beneficiarse de los contenidos existentes así como de mejorarlos y contribuir con nuevos. Espero que os parezca interesante la iniciativa y confío que construir una base de materiales de forma colaborativa nos permita dedicar más tiempo a otros aspectos de los cursos, y conseguir así una mayor calidad.

#Sin categoría

SQLite support on gvSIG CE

We have been working on a new feature for the gvSIG CE project: SQLite support for both spatial and non-spatial data. There is already a post in the gvSIG CE blog that may worth to take a look.

From the technical point of view, the most challenging part has been the compilation of the native GDAL/OGR bindings for Windows. In fact, more than “challenging” it has been hell on earth, but we made it. We used MinGW for the compilation and it has been necessary to make a lot of little tweaks to the GDAL configuration files in order to make it work. Since it has been a greater effort than expected, we have tried to document it as good as possible in the project’s wiki. The result is a pretty straightforward documentation and abash script to automate the process.

Also, it is important to notice that these bindings replace the custom bindings that gvSIG had. Thus, we have less code to maintain and rely on the GDAL community to update the bindings whenever it’s necessary. All we have to do now is follow the instructions (or even better, run the script) to compile them.

#GDAL #gvSIG CE #SQLite

SQLite support on gvSIG CE

We have been working on a new feature for the gvSIG CE project: SQLite support for both spatial and non-spatial data. There is already a post in the gvSIG CE blog that may worth to take a look. From the technical point of view, the most challenging part has been the compilation of the native GDAL/OGR bindings for Windows. In fact, more than "challenging" it has been hell on earth, but we made it. We used MinGW for the compilation and it has been necessary to make a lot of little tweaks to the GDAL configuration files in order to make it work. Since it has been a greater effort than expected, we have tried to document it as good as possible in the project's wiki. The result is a pretty straightforward documentation and a bash script to automate the process. Also, it is important to notice that these bindings replace the custom bindings that gvSIG had. Thus, we have less code to maintain and rely on the GDAL community to update the bindings whenever it's necessary. All we have to do now is follow the instructions (or even better, run the script) to compile them.We have been working on a new feature for the gvSIG CE project: SQLite support for both spatial and non-spatial data. There is already a post in the gvSIG CE blog that may worth to take a look. From the technical point of view, the most challenging part has been the compilation of the native GDAL/OGR bindings for Windows. In fact, more than "challenging" it has been hell on earth, but we made it. We used MinGW for the compilation and it has been necessary to make a lot of little tweaks to the GDAL configuration files in order to make it work. Since it has been a greater effort than expected, we have tried to document it as good as possible in the project's wiki. The result is a pretty straightforward documentation and a bash script to automate the process. Also, it is important to notice that these bindings replace the custom bindings that gvSIG had. Thus, we have less code to maintain and rely on the GDAL community to update the bindings whenever it's necessary. All we have to do now is follow the instructions (or even better, run the script) to compile them.

#SQLite #gvSIG CE #GDAL

#GeoPoster un mapa para compartir

¿Por qué? Necesitábamos un visor en el que de manera sencilla pudiésemos compartir información. No queríamos muchos botones, nada de aspecto GIS. Nos interesaba que fuese una interfaz sencilla y amigable en la que cualquier usuario carente de formación SIG comprendiese de un simple vistazo el funcionamiento del visor. ¿Cómo? Hemos divido el desarrollo en dos componentes, una API REST desarrollada en Python usando la librería Flask que maneja la comunicación ente el cliente y el repositorio de datos PostGIS y un cliente desarrollado en JavaScript usando LeafLet como librería de mapas y Bootstrap + jQuery como encargados de montar el esqueleto del visor. ¿Para qué? Puedes usar nuestra API REST para servir tus propios datos. Dispones de un campo título y uno descripción para servir en ellos tu información. También puedes usar nuestro desarrollo para, de manera muy sencilla, adaptar esta API a un modelo de datos más complejo. El cliente del GeoPoster permite mediante el desarrollo del conector apropiado publicar en la web información que provenga de un servicio de datos diferente a nuestra API REST. ¿Y después? En breve se incorporarán nuevas funcionalidades al GeoPoster, uso de cuentas OpenID para los usuarios, gestión de conflictos, sincronización entre servidor y cliente, creación de mapas, asignación de diferentes roles entre los usuarios con acceso discriminado a los mapas... Como siempre lo tenéis todo en nuestro repositorio en GitHub, forkead y disfrutad. Allí encontraréis mas información. Si queréis ver como funciona en directo simplemente id a geomati.co/geoposter y usad demo/demogeoposter como usuario/clave. Ya nos contaréis. Saludos. Why? We needed a viewer in which we could share information easily. We did'nt want a lot of buttons, no GIS aspect. We were interested in an interface as simple as it can be, where any user with no GIS knowledge could understand how it runs. How? We have divided the development into two components, a REST API developed in Python using the Flask library that handles the communication between client and PostGIS data repository, and a client developed in JavaScript using the Leaflet map library and Bootstrap + jQuery to build the client. What for? You can use our REST API to serve your own data. You have a title and a description field to place rich text content. You can also use our development to, very simply, adapt the API to a more complex data model. The GeoPoster client allows, by developing the appropriate connector, to publish information on the web coming from different data services besides our REST API. And what next? In brief we will incorporate new features to GeoPoster, like OpenID for user accounts, conflict management, synchronization between server and client, creation of different maps, and assigning different roles to users, allowing access profiles to different maps... As always you have everything in our repository on GitHub, fork it and enjoy! Tou will find more information there. You can see a demo in geomati.co/geoposter/ using demo/demogeoposter as user/password. Any feedback wellcomed. Regards.

#javascript #GeoPoster #API REST

Adding Oracle support for 52N-SOS server

We have been collaborating with 52º North the last months. Precisely, we have been working on the Oracle support for the new release of the Sensor Observation Service server: 52N-SOS 4.0 [1]. The problem we were facing was that the last stable version (52N-SOS 3.2.0) is not capable of get the sensor data from Oracle databases and Oracle was a requirement of our customer, so moving the data to PostgreSQL was not an option. We also knew that a new version was being actively developed by the 52º North community and that it was using Hibernate to access data. So we decided that our goal was to cooperate with the 52º North community to get Oracle working via Hibernate. We put our hands to work and we implemented the Oracle database access, including some generic test data creation that we shared with PostgreSQL. Right now this part is being rebuilt on top of our first implementation. Aside from implementing the Oracle database access and share some code with the PostgreSQL part, we also improved a little the error messages for the installation process and the test client. Finally, we produced some documentation to build and install Oracle and the 52N-SOS 4.0 server with support for it. You can check this instructions in the official 52º North website [2][3]. This work was financed by the Barcelona Port Authority as part of their Sensor Observation Service deployment. [1] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIV [2] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIVDocumentation#Oracle_support [3] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIVDocumentation#Oracle_installationWe have been collaborating with 52º North the last months. Precisely, we have been working on the Oracle support for the new release of the Sensor Observation Service server: 52N-SOS 4.0 [1]. The problem we were facing was that the last stable version (52N-SOS 3.2.0) is not capable of get the sensor data from Oracle databases and Oracle was a requirement of our customer, so moving the data to PostgreSQL was not an option. We also knew that a new version was being actively developed by the 52º North community and that it was using Hibernate to access data. So we decided that our goal was to cooperate with the 52º North community to get Oracle working via Hibernate. We put our hands to work and we implemented the Oracle database access, including some generic test data creation that we shared with PostgreSQL. Right now this part is being rebuilt on top of our first implementation. Aside from implementing the Oracle database access and share some code with the PostgreSQL part, we also improved a little the error messages for the installation process and the test client. Finally, we produced some documentation to build and install Oracle and the 52N-SOS 4.0 server with support for it. You can check this instructions in the official 52º North website [2] [3]. This work was financed by the Barcelona Port Authority as part of their Sensor Observation Service deployment. [1] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIV [2] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIVDocumentation#Oracle_support [3] https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIVDocumentation#Oracle_installation

#SOS #Sin categoría #Oracle #52N

Trending Blogs

Recently Viewed Blogs

geomatico