OSGeo Planet

Fernando Quadro: Plugin do Elasticsearch no GeoServer

OSGeo Planet - Mon, 2018-10-08 17:54

O Elasticsearch é um popular mecanismo de análise distribuída que permite recursos de pesquisa complexos quase em tempo real. Os mapeamentos de tipo de campo padrão suportam tipos string, numéricos, booleanos, data e permitem documentos hierárquicos complexos. Mapeamentos de tipos de campos personalizados podem ser definidos para campos de documentos geoespaciais.

O tipo geo_point suporta geometrias de pontos que podem ser especificadas por meio de uma cadeia de coordenadas, geohash ou matriz de coordenadas. Já o tipo geo_shape suporta tipos Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection e GeoJSON, bem como tipos de envelope e círculo. Opções personalizadas permitem a configuração do tipo e precisão do índice espacial.

Este armazenamento de dados permite que recursos de um índice Elasticsearch sejam publicados através do GeoServer. Ambos os mapeamentos geo_pointe geo_shape são tipos suportados. Os filtros OGC são convertidos em consultas do Elasticsearch e podem ser combinados com consultas nativas do Elasticsearch em requisições WMS e WFS.

Para instalar o plugin, basta baixá-lo no repositório do Git. Depois de baixar, basta descompactar o arquivo zip, inserir os arquivos na pasta WEB-INF\lib e reiniciar o GeoServer.

Se você entrar na tela de “Stores” e ver a opção do Elasticsearch, como demonstra a figura acima, é porque o seu plugin está instalado corretamente, agora basta criar o seu Store do Elasticsearch.

Fonte: GitHub

Categories: OSGeo Planet

MapTiler: DIY car navigation on Raspberry Pi with OpenMapTiles

OSGeo Planet - Mon, 2018-10-08 11:00
Thumb

What started as a need for a rear camera for older car turned into a complete car system. Fabrice Aneche builds own car navigation with Raspberry Pi using OpenMapTiles as a base map in his spare time as a do-it-yourself project.

Raspberry Pi, LCD screen and a bunch of determination is needed to create a car system

After Fabrice bought his car, he realized how badly he is missing a rear cam. Instead of throwing a pile of money at the nearest car shop, he decided, as a true geek, to make own DIY system. And that’s how everything has begun.

As a heart of the system, he chose Raspberry Pi 3, an inexpensive single-board computer. It is connected to the Eleduino Raspberry Pi LCD screen, the video signal from the rear camera was captured using a USB adapter.

My Car, from 2011, only has an LCD display and no rear camera, so I bought a PAL rear camera, we passed some cables from the rear window to the front then everything begun.

The Raspberry Pi is powered by Linux with LXQTt desktop environment. After installing mplayer, the camera was running out of the box. Since everything worked, he thought about what to do next.

A rear cam A rear cam. Photo © Fabrice Aneche

Maps powered by OpenMapTiles

Since Fabrice has a GPS receiver around, he decided to utilize the screen for showing the actual position of the car on the map. As a map system, he chose OpenMapTiles for its’ ability to run offline on a device with scarce resources. Because the project is open-source, he hacked the code to serve precisely his specific needs.

For serving map tiles, he wrote own server called mbmatch in Go programming language. He chose one of the default styles for a day map and created his own for a nigh, which is based on Solarized color pallet.

This project is an excellent demonstration of the power of OpenMapTiles offline use.

OSRM was selected as a backend for routing and the selected route was again displayed on the map.

The complete car system is available under an open-source license on GitHub.

A map with the actual position A map with the actual position. Photo © Fabrice Aneche

Start your DIY project with OpenMapTiles

OpenMapTiles offers a free package for non-commercial personal projects. You can download the data, read the documentation and hack the code on GitHub.

Categories: OSGeo Planet

gvSIG Team: Registration period for workshops at 14th International gvSIG Conference is now open

OSGeo Planet - Mon, 2018-10-08 09:01

Registrations for free workshops at 14th International gvSIG Conference can be done from now. Conference will be held from October 24th to 26th at School of Engineering in Geodesy, Cartography and Surveying (Universitat Politècnica de València, Spain).

The workshops available are:

  • Workshop 1: gvSIG aplicado a Agricultura
  • Workshop 2: Environmental modelling using gvSIG and the HortonMachine
  • Workshop 3: gvSIG aplicado a Geología
  • Workshop 4: Field mapping and data centralization with Geopaparazzi /gvSIG Mobile and the Survey Sever
  • Workshop 5: gvSIG aplicado a Medio Ambiente
  • Workshop 6: Generación de informes con gvSIG Desktop
  • Workshop 7: gvSIG Mobile

Apart from the registration at the workshop, the registration to the gvSIG Conference must be done from the conference website.

In addition, all the information about workshops can be consulted at the gvSIG blog, including what you have to install in case you have to take your own device.

Categories: OSGeo Planet

gvSIG Team: Abiertas las inscripciones a los talleres de las 14as Jornadas Internacionales de gvSIG

OSGeo Planet - Mon, 2018-10-08 08:57

Ya están abiertas las inscripciones a los talleres gratuitos que se van a realizar durante las 14as Jornadas Internacionales de gvSIG. Las jornadas tendrán lugar del 24 al 26 de octubre en Valencia (España), en la Escuela Técnica Superior de Ingeniería Geodésica, Cartográfica y Topográfica (Universitat Politècnica de València).

Los talleres que se impartirán son los siguientes:

  • Taller 1: gvSIG aplicado a Agricultura
  • Taller 2: Environmental modelling using gvSIG and the HortonMachine
  • Taller 3: gvSIG aplicado a Geología
  • Taller 4: Field mapping and data centralization with Geopaparazzi /gvSIG Mobile and the Survey Sever
  • Taller 5: gvSIG aplicado a Medio Ambiente
  • Taller 6: Generación de informes con gvSIG Desktop
  • Taller 7: gvSIG Mobile

Para poder realizarlos, aparte de la inscripción al taller hay que inscribirse en las jornadas. Las inscripciones son gratuitas, con aforo limitado.

Así mismo, en el blog de gvSIG también está disponible toda la información de cada taller, con lo que hay que llevar instalado en caso de que se deba llevar equipo propio.

Categories: OSGeo Planet

EOX' blog: Building a Python interface to VirES

OSGeo Planet - Mon, 2018-10-08 08:08
This post is about a new python tool to interact with VirES for Swarm. VirES comprises three components: – VirES server: provides optimised, flexible access to the original mission data and models – VirES web client: a state-of-the-art web-based GUI […]
Categories: OSGeo Planet

gvSIG Team: Curso presencial de gvSIG Desktop aplicado a Arqueología en Valencia (España)

OSGeo Planet - Fri, 2018-10-05 12:29

Del 26 al 29 de noviembre de 2018 se realizará en Valencia (España) un curso presencial sobre gvSIG Desktop aplicado a Arqueología, organizado por el Colegio de Doctores y Licenciados en Filosofía y Letras y en Ciencias e impartido por la Asociación gvSIG.

Durante el curso se mostrarán las principales funcionales de gvSIG a través de ejercicios prácticos relacionados con la gestión de yacimientos y zonas arqueológicas, los Bienes de Interés Cultural…

Realizando este curso, el alumno obtendrá el certificado oficial de gvSIG Usuario de la Asociación gvSIG.

Más información sobre precios, temario e inscripción en el siguiente enlace.

Categories: OSGeo Planet

Fernando Quadro: Geocursos lança cursos no formato EAD

OSGeo Planet - Thu, 2018-10-04 10:30

Nesta segunda-feira, 1 de Outubro, a Geocursos (Escola de Geotecnologias Livres) lançou seus dois primeiros cursos no formato EAD.

Agora, você pode adquirir um curso e assisti-lo no horário que lhe for mais conveniente. Os cursos ficarão disponíveis no período de 3 meses no portal do aluno, onde você poderá acessar as videoaulas e também baixar todo o material didático.

No momento foram disponibilizados dois cursos nesse novo formato:

Curso de OpenLayers 4 (16h) | https://bit.ly/2QjBus4

Curso de PostgreSQL (15h) | https://bit.ly/2P5pESa

Em breve mais módulos serão disponibilizados, então fiquem atentos as redes sociais da Geocursos!

Categories: OSGeo Planet

Fernando Quadro: Como realizar backup no GeoServer – Parte 3

OSGeo Planet - Wed, 2018-10-03 10:30

Neste post irei apresentar como gerenciar o backup e a restauração das informações do GeoServer através de sua API REST.

5. Backup através da API REST do GeoServer

A API REST de backup e restauração consiste em alguns recursos destinados a serem usados ​​de maneira assíncrona:

Vamos usar a ferramenta de linha de comando cURL para enviar solicitações HTTP REST para o GeoServer.

Os endpoints /rest/br/backup/ e /rest/br/restore aceitam um sufixo de formato opcional que permite que o arquivo de Backup/Restauração seja transmitido de/para o cliente em vez de ser gravado/lido no sistema de arquivos.

5.1 Iniciar um backup

Prepare um arquivo contendo um objeto JSON representando a configuração do procedimento de backup.

{ "backup":{ "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip", "overwrite":true, "options":{ } } }

Neste caso, não especificamos nenhuma opção na configuração de backup, de forma que os valores padrão serão usados.

As opções disponíveis são:

BK_BEST_EFFORT: Ignore quaisquer recursos com falha e continue com o procedimento de backup
BK_PARAM_PASSWORDS: Se as senhas do armazenamento de saída devem ser parametrizadas no backup. Com essa opção, todas as senhas armazenadas serão substituídas por um token parecido com ${workspaceName:storeName.passwd.encryptedValue}
BK_SKIP_SECURITY: Isso excluirá as configurações de segurança do backup (Experimental).
BK_SKIP_SETTINGS: Isso tentará excluir a maioria das configurações globais do backup, bem como as configurações de segurança (Experimental).

Além disso, um opcional Filter pode ser passado para restringir o escopo da operação de restauração a uma lista de espaços de trabalho. Por exemplo:

{ "backup":{ "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip", "overwrite":true, "options":{ "option": ["BK_BEST_EFFORT=true"] }, "filter": "name IN ('topp','geosolutions-it')" } }

O procedimento de backup será iniciado. Aqui está uma amostra da resposta:

HTTP/1.1 201 Created Date: Mon, 01 Aug 2016 14:35:44 GMT Location: http://mygeoserver/geoserver/rest/br/backup/1 Server: Noelios-Restlet-Engine/1.0..8 Content-Type: application/json Transfer-Encoding: chunked { "backup":{ "totalNumberOfSteps":9, "execution":{ "id":1, "version":1, "stepExecutions":{ "@class":"java.util.concurrent.CopyOnWriteArraySet" }, "status":[ "STARTED" ], "startTime":"2016-08-01 14:35:44.802 UTC", "createTime":"2016-08-01 14:35:44.798 UTC", "lastUpdated":"2016-08-01 14:35:44.803 UTC", "exitStatus":{ "exitCode":"UNKNOWN", "exitDescription":"" }, "progress":"1\/9" }, "options":{ "@class":"synchList", "option":[ "OVERWRITE=true" ] }, "warningsList":{ "@class":"synchList" }, "archiveFile":{ "@class":"resource", "$":"\/home\/sg\/BackupAndRestore\/test_rest_1.zip" }, "overwrite":true } }

No final do procedimento de backup, você poderá fazer o download do arquivo gerado para o seu sistema de arquivos local, fazendo uma solicitação HTTP GET para o mesmo endpoint, usando o ID de backup como abaixo e adicionando a extensão .zip no final.

curl -u "admin:geoserver" -i -X GET "http://mygeoserver/geoserver/rest/br/backup/1.zip" -o 1.zip

O status da operação pode ser consultado fazendo uma solicitação HTTP GET para o local listado na resposta:

http://mygeoserver/geoserver/rest/br/backup/$ID.{json/xml}

Substitua $ID pela ID da operação de backup que você gostaria de inspecionar:

curl -u "admin:geoserver" http://mygeoserver/geoserver/rest/br/backup/1.json OU curl -u "admin:geoserver" http://mygeoserver/geoserver/rest/br/backup/1.xml

O GeoServer responderá com o status do backup correspondente a esse ID:

Aqui você pode ver o status de todas as etapas envolvidas no procedimento de backup com hora de criação, hora de início, hora de término, status de saída, etc.

5.2 Cancelar um backup

Para cancelar um backup em andamento, é necessário enviar uma solicitação HTTP DELETE com o ID da tarefa:

curl -v -XDELETE -u "admin:geoserver" http://mygeoserver/geoserver/rest/br/backup/$ID

Substitua $IDpela ID da operação de backup que você deseja cancelar.

5.3 Restaurando um backup

Prepare um arquivo com um objeto JSON representando a configuração do procedimento de Restore:

{ "restore":{ "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip", "options":{ } } }

Neste caso, não especificamos nenhuma opção na configuração de restauração para que os valores padrão sejam usados.

Opções disponíveis são:

BK_DRY_RUN: Apenas testar o arquivo e não persistir a configuração restaurada

BK_BEST_EFFORT: Ignorar quaisquer recursos com falha e continuar com o procedimento de restauração

BK_PASSWORD_TOKENS: Uma lista separada por vírgula de chave e valores separados por sinal de igual deve ser substituída em senhas de armazenamento de dados em um backup de entrada. Por exemplo:

BK_PASSWORD_TOKENS=${workspace:store1.passwd.encryptedValye}=foo,${workspace:store2.passwd.encryptedValue}=bar

BK_SKIP_SECURITY: Isso excluirá as configurações de segurança da restauração. Padrão: falso (Experimental).

BK_SKIP_SETTINGS: Isso tentará excluir a maioria das configurações globais do backup, bem como as configurações de segurança. Padrão: falso (Experimental).

BK_PURGE_RESOURCES: Isso irá ignorar a exclusão de recursos sempre que possível. Em particular, os espaços de trabalho existentes não serão excluídos durante a restauração. Padrão: true (Experimental).

Além disso, um opcional Filter pode ser passado para restituir o escopo da operação de restauração a uma lista de espaços de trabalho. Por exemplo:

{ "restore":{ "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip", "options":{ "option": ["BK_DRY_RUN=true"] }, "filter": "name IN ('topp','geosolutions-it')" } }

Se o caminho for especificado, o arquivo especificado nesse caminho (remoto) será usado para iniciar o procedimento de restauração. Caso contrário, você precisa inserir o arquivo do seu sistema local.

Em seguida, faça uma solicitação POST HTTP para a interface REST do GeoServer para o procedimento de restauração:

curl -u “admin:geoserver” -i -H “Content-Type: application/json” -X POST –data @restore_post.json http://mygeoserver/geoserver/rest/br/restore/

O procedimento de restauração será iniciado. Aqui está uma resposta de exemplo:

HTTP/1.1 201 Created
Date: Mon, 01 Aug 2016 15:07:29 GMT
Location: http://mygeoserver/geoserver/rest/br/restore/2
Server: Noelios-Restlet-Engine/1.0..8
Content-Type: application/json
Transfer-Encoding: chunked

{
“restore”:{
“totalNumberOfSteps”:9,
“execution”:{
“id”:2,
“version”:1,
“stepExecutions”:{
“@class”:”java.util.concurrent.CopyOnWriteArraySet”
},
“status”:[
“STARTED”
],
“startTime”:”2016-08-01 15:07:29.398 UTC”,
“createTime”:”2016-08-01 15:07:29.393 UTC”,
“lastUpdated”:”2016-08-01 15:07:29.398 UTC”,
“exitStatus”:{
“exitCode”:”UNKNOWN”,
“exitDescription”:””
},
“progress”:”0\/9″
},
“options”:{
“@class”:”synchList”
},
“warningsList”:{
“@class”:”synchList”
},
“archiveFile”:{
“@class”:”resource”,
“$”:”\/home\/sg\/BackupAndRestore\/test_rest_1.zip”
}
}
}

Para carregar o arquivo do nosso sistema local, omita o parâmetro archiveFile no objeto JSON e passe o –upload-file para o cURL:

{ "restore":{ "options":{ }, } } curl -u "admin:geoserver" -i -H "Content-Type: application/json" --upload-file "archive_to_restore.zip" -X POST --data @restore_post.json http://localhost:8081/geoserver/rest/br/restore/

O arquivo archive_to_restore.zip (local) será carregado e usado pelo processo de restauração.

Consulta para o status de operações de restauração:

http://mygeoserver/geoser/restore/$ID.{json/xml} { "restore":{ "execution":{ "hash":2, "key":{ "@class":"long", "$":"2" }, "val":{ "@class":"restore", "totalNumberOfSteps":9, "execution":{ "id":2, "version":2, "stepExecutions":{ "@class":"java.util.concurrent.CopyOnWriteArraySet", "step":[ { "name":"restoreNamespaceInfos", "status":"COMPLETED", "exitStatus":{ "exitCode":"COMPLETED", "exitDescription":"" }, "startTime":"8\/1\/16 3:07 PM", "endTime":"8\/1\/16 3:07 PM", "lastUpdated":"8\/1\/16 3:07 PM", "parameters":{ "input.file.path":"file:\/\/\/opt\/tomcat-geoserver-2.9.x\/temp\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec", "time":1470064049392 }, "readCount":1, "writeCount":1, "failureExceptions":"" }, ... { "name":"restoreGeoServerSecurityManager", "status":"COMPLETED", "exitStatus":{ "exitCode":"COMPLETED", "exitDescription":"" }, "startTime":"8\/1\/16 3:07 PM", "endTime":"8\/1\/16 3:07 PM", "lastUpdated":"8\/1\/16 3:07 PM", "parameters":{ "input.file.path":"file:\/\/\/opt\/tomcat-geoserver-2.9.x\/temp\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec", "time":1470064049392 }, "readCount":0, "writeCount":0, "failureExceptions":"" } ] }, "status":"COMPLETED", "startTime":"2016-08-01 15:07:29.398 UTC", "createTime":"2016-08-01 15:07:29.393 UTC", "endTime":"2016-08-01 15:07:30.356 UTC", "lastUpdated":"2016-08-01 15:07:30.772 UTC", "exitStatus":{ "exitCode":"COMPLETED", "exitDescription":"" }, "progress":"9\/9" }, "options":{ "@class":"synchList" }, "warningsList":{ "@class":"synchList" }, "archiveFile":{ "@class":"resource", "$":"\/home\/sg\/BackupAndRestore\/test_rest_1.zip" } } } ...

Aqui você pode ver o status de todas as etapas envolvidas no procedimento de restauração com hora de criação, hora de início, hora de término, status de saída, etc.

5.4 Cancelar uma restauração

Par cancelar uma restauração em andamento, envie uma solicitação HTTP DELETE:

curl -v -XDELETE -u "admin:geoserver" http://mygeoserver/geoserver/rest/br/restore/$ID

Substitua $ID pelo ID da operação de restauração que você deseja cancelar.

Fonte: GeoServer Documentation

Categories: OSGeo Planet

gvSIG Team: Taller sobre generación de informes con gvSIG Desktop en las 14as Jornadas Internacionales gvSIG

OSGeo Planet - Tue, 2018-10-02 10:41

El próximo viernes 26 de octubre se impartirá un taller gratuito sobre generación de informes en gvSIG Desktop en Valencia (España), en el marco de las 14as Jornadas Internacionales gvSIG.

Esto será posible gracias al nuevo plugin que estará disponible en la nueva versión de gvSIG.

El taller estará enfocado a preparar capas y mapas en gvSIG para ser integrados en el diseñador de informes JasperSoft Studio, y a crear documentos de tipo ‘Informe’ en gvSIG que incluyan los informes creados con JasperSoft Studio (no es un taller sobre esta herramienta).

En él se mostrará cómo preparar la información en gvSIG para ser publicada de forma que se pueda acceder a ella desde el diseñador de informes, cómo usarla desde este y cómo usar esos informes en gvSIG. El usuario aprenderá a publicar la información de las capas y las vistas de gvSIG, utilizando dichas capas en el diseñador de informes e incrustando vistas en él. Finalmente se mostrará cómo crear documentos en gvSIG con los informes creados, y cómo filtrar los datos a mostrar en un informe.

El taller se realizará en el Aula 1.5 (Ptolomeo) de la Escuela Técnica Superior de Ingeniería Geodésica, Cartográfica y Topográfica (Universitat Politècnica de València), que dispone de ordenadores, por lo que no es necesario llevar ordenador propio.

Las inscripciones al taller se abrirán el día 4 de octubre en el siguiente enlace. Las plazas serán limitadas.

Aparte, te recordamos que el periodo de inscripción a las jornadas ya está abierto, pudiendo realizarse el registro a través del formulario habilitado para ello, siendo además obligatorio para la realización de los talleres.

El taller será grabado, por lo que si no puedes asistir tendrás disponible el vídeo a posteriori para seguirlo.

Categories: OSGeo Planet

Fernando Quadro: Como realizar backup no GeoServer – Parte 2

OSGeo Planet - Tue, 2018-10-02 10:30

Como mencionado no post anterior, irei apresentar neste como realizar um backup via interface administrativa e também como realizar uma restauração de um backup previamente realizado.

3. Backup através da interface do usuário do GeoServer

Para executar um backup completo, forneça o caminho completo do arquivo zip de destino, onde irá armazenar os dados de configuração. É importante ressaltar que o backup irá armazenar apenas os arquivos de configuração e não os dados em si.

É possível selecionar as opções de backup, ativando as caixas de seleção apropriadas antes de iniciar o processo de backup.

Observe que, ao executar uma tarefa de backup ou restauração, o GeoServer não permitirá que os usuários acessem outras seções, bloqueando o catálogo e a configuração até que o processo seja concluído, embora seja sempre possível parar ou abandonar um procedimento de backup ou restauração.

No final do backup, o usuário será redirecionado para uma página chamada Execution Summary.

A mesma página pode ser acessada também mais tarde clicando em um link de execução na página principal. Observe que a lista de execuções não é mantida e, portanto, ela será redefinida após você reiniciar o GeoServer.

Na parte inferior da página, é possível baixar o arquivo diretamente clicando no link Download Archive File.

Caso algumas exceções ou avisos sejam capturados pelo processo, eles serão apresentados no resumo de execução. O “Error Detail Level” permite inspecionar as causas, expondo o rastreamento para cada um deles.

4. Restaurando backup via interface administrativa (UI)

As etapas são quase as mesmas do backup. Basta selecionar o caminho completo do arquivo zip antes de iniciar o processo de restauração.

Observe que uma restauração que não seja Dry Run perderá toda a configuração atual do GeoServer substituindo-a por uma nova, portanto, tenha cuidado e faça um backup de tudo antes de iniciar uma restauração.

4. 1 DRY-RUN

A opção Dry Run permite que um usuário teste um arquivo zip antes de executar uma restauração completa.

Se ocorrer alguma exceção, ela será listada na página de resumo da execução. A causa original pode ser inspecionada aumentando o nível de detalhes de erros.

4.2 Restaurando apenas espaços de trabalho específicos

É possível fazer backup ou restaurar apenas um subconjunto dos espaços de trabalho disponíveis no catálogo. A partir da interface WEB é atualmente possível selecionar todos ou apenas um espaço de trabalho para backup ou restauração

Por meio das APIs REST, é possível filtrar também mais de um espaço de trabalho, conforme explicado nos próximos posts.

Note que a partir de um arquivo de backup contendo espaços de trabalho filtrados não será possível restaurar também os que faltam. Para fazer isso, é aconselhável fazer backup de todo o catálogo e restaurar apenas os espaços de trabalho necessários.

No próximo post você verá como realizar o backup utilizando a API REST do GeoServer, não perca!

Fonte: GeoServer Documentation

Categories: OSGeo Planet

Jackie Ng: A short MapGuide poll: What you said

OSGeo Planet - Mon, 2018-10-01 14:27
A month-and-a-half ago, I put up a short poll regarding DWF support in MapGuide.

I got 97 responses in the time window that I left that poll open, and this is what you said.

Regarding whether you use this DWF support in MapGuide:



I also posed a hypothetical situation where we removed DWF support from MapGuide and asked how badly you'd be affected as a result:

My motivation for this poll was simple. I believe that DWF support in MapGuide is now a technical burden that is not worth carrying on.

This feature is terminal. You won't see any DWF-related enhancements (not from me anyways). Any DWF-related issues still open will most likely never be fixed. Because I doubt that anyone would be familiar enough with the underlying DWF toolkit library to keep maintaining this support as it stands.

Also, presumably this DWF support was originally put in as value proposition from Autodesk to integrate with AutoCAD and friends. Well, since they've officially bailed out at the beginning of this year, that is yet another reason I'm cold on DWF support in MapGuide. Given my dwindling free time on anything MapGuide related, I'd rather spend it (wherever I can) on making MapGuide a better GIS/WebMap server than trying to maintain support for technologies that Autodesk themselves have given up on.

And judging by these poll results, I would gather that you (the poll respondent) would mostly agree with my sentiments.
Categories: OSGeo Planet

gvSIG Team: Taller sobre gvSIG aplicado a Agricultura en las 14as Jornadas Internacionales gvSIG

OSGeo Planet - Mon, 2018-10-01 13:05

En las próximas 14as Jornadas Internacionales gvSIG, que tendrán lugar en Valencia (España) del 24 al 26 de octubre, se impartirá un taller gratuito sobre gvSIG aplicado a Agricultura.

Este taller está definido para quien quiera iniciarse en el mundo de los Sistemas de Información Geográfica en el ámbito de la agricultura, donde se verán varios ejercicios prácticos, como puede ser el cálculo de zonas de cultivo afectadas por una plaga o fenómeno meteorológico (granizo, fuertes vientos), o el cálculo del número de hectáreas afectadas para cada uno de los usos del suelo (olivar, cítricos, almendro..).

El taller tendrá lugar la tarde del miércoles 24 de octubre en el Aula 1.6 (Mercator) de la Escuela Técnica Superior de Ingeniería Geodésica, Cartográfica y Topográfica (Universitat Politècnica de València), que dispone de ordenadores, por lo que no es necesario llevar ordenador propio.

Las inscripciones al taller se abrirán el día 4 de octubre en el siguiente enlace. Las plazas serán limitadas.

Aparte, te recordamos que el periodo de inscripción a las jornadas ya está abierto, pudiendo realizarse el registro a través del formulario habilitado para ello, siendo además obligatorio para la realización de los talleres.

Categories: OSGeo Planet

Fernando Quadro: Como realizar backup no GeoServer – Parte 1

OSGeo Planet - Mon, 2018-10-01 10:30

O GeoServer possui um plugin que permite realizar backup e restore de suas informações, e neste post irei mostrar pra você como fazê-lo.

Primeiro vamos baixar o plugin. Como ele é um plugin que ainda não foi adicionado “oficialmente” ao GeoServer, apenas na versão Community, vamos pegar o arquivo direto no repositório:

1. Instalação

1.1. Faça o download do geoserver-2.14-SNAPSHOT-backup-restore-plugin.zip; É importante baixar a versão que corresponde ao GeoServer que você está executando.

1.2. Pare o GeoServer.

1.3. Navegue até a pasta

webapps/geoserver/WEB-INF/lib

1.4. Descompacte o conteúdo do arquivo zip na pasta lib.

1.5. Reinicie o GeoServer.

O plugin de backup e restauração pode ser usado por meio da interface do usuário e também via interface HTTP REST, e é o que veremos na sequencia.

2. Uso via interface administrativa:

2.1. Após finalizada a instalação do plugin, você verá uma nova seção na IU do GeoServer

2.2 Ao clicar no rótulo, você terá acesso às configurações do Backup e Restauração:Backup and Restore

Aqui você poderá especificar vários parâmetros para o procedimento de Backup/Restore:

2.2.1 Archive full path: Caminho no sistema de arquivos para o arquivo criado pelo procedimento de backup, no caso de um backup ser executado ou o arquivo para restauração, no caso de um procedimento de restauração.

2.2.2 Filter by Workspace: Parâmetro opcional que permite restringir o escopo do backup / restauração a espaços de trabalho que atendem ao filtro especificado.

2.2.3 Backup Options:

2.2.3.1 Overwrite Existing Archive: Quando ativado, o procedimento de backup sobrescreverá qualquer arquivo existente anteriormente

2.2.3.2 Skip Failing Resources: Se ativado e erros forem encontrados durante o backup de recursos existentes, pule o recurso e prossiga com o procedimento de backup

Backup Executions: Relatório de execução e backups executados anteriormente

2.2.4 Restore Options:

2.2.4.1 Dry Run: Teste o procedimento de restauração usando o archive fornecido, mas não aplique nenhuma alteração na configuração atual. Útil para testar arquivos antes de executar uma restauração

2.2.4.2 Skip Failing Resources: Se ativado e erros forem encontrados durante a restauração de recursos, pule o recurso e prossiga com o procedimento de restauração

2.2.5 Restore Executions: Relatório de execução e restauração anteriormente executada

No próximo post realizaremos um backup completo utilizando a interface administrativa do GeoServer, não perca!

Fonte: GeoServer Documentation

Categories: OSGeo Planet

Paul Ramsey: PostGIS Code Sprint 2018 #2

OSGeo Planet - Mon, 2018-10-01 08:00

An important topic of conversation this sprint was what kinds of core PostgreSQL features might make PostGIS better in the future?

PostGIS Code Sprint 2018 #2

Wider Typmod

The current attribue typmod column is a 32-bit integer. For geometry, we are already packing that 32 bits to the limit: a couple bits for dimensionality, some more for the type number, and the bit kahune, a bunch for the SRID number. Having even a 64-bit typmod number would allow even more interesting things, like declared coordinate precision, to fit in there. Maybe we are abusing typmod and there’s a better way to do what we want though?

Parallel GIST Scan

The PostGIS spatial index is built using the PostgreSQL GIST index infrastructure, so anything that makes GIST scans faster is a win for us. This would be a big win for folks with large tables (and thus deep trees) and who run scans that return a lot of indexed tuples.

Faster GIST Index Building

B-Tree index builds are accellerated by pre-sorting the inputs; could the same trick be used in building GIST indexes? Again, for large tables, GIST index building is slower than B-Tree and “faster” is the #1 feature all existing users want.

Multi-Threading in Functions

This isn’t a feature request, so much as a request for clarification and assurance: PostGIS calls out to other libraries, like GEOS, and it’s possible we could make some of our algorithms there faster via parallel processing. If we do our parallel processing within a function call, so the PostgreSQL thread of execution isn’t doing anything until we return, is it OK for us to do threading? We use pthreads, or maybe OpenMP.

Compressed Datum Slicing

“Detoast datum slice” doesn’t actually get around to the slicing step until after the datum is decompressed, which can make some queries quite slow. We already try to read boxes from the headers of our objects, and for large objects that means decompressing the whole thing: it would be nice to only decompress the first few bytes. I have an ugly patch I will be testing to try and get committed.

Forced Inlining

A problem we have with PostgreSQL right now is that we cannot effectively cost our functions due to the current inlining behaviour on our wrapper functions like ST_Intersects(). When raised on the list, the hackers came to a tentative conclusion that improving the value caching behaviour would be a good way to avoid having inlining in incorrect places. It sounded like subtle and difficult work, and nobody jumped to it.

We propose leaving the current inlining logic unchanged, but adding an option to SQL language functions to force inlining for those functions. That way there is no ambiguity: we always want our wrapper functions inlined; always, always, always. If we could use an INLINE option on our wrapper function definitions all the current careful logic can remain in place for more dynamic use cases.

Extension Version Dependency

PostGIS is growing a small forest of dependent extensions

  • some inside the project, like postgis_topology and now postgis_raster
  • some outside the project, like PgRouting and pgpointcloud

When a new version of PostGIS is installed, we want all the PostGIS extensions to be updated. When a third party extension is installed, it may require features from a particular recent version of PostGIS.

The extension framework supports dependency, but for safety, as the ecosystem grows, version dependencies are going to be required eventually.

Global Upgrade Paths

Right now extension upgrade paths have to explicitly state the start and end version of the path. So an upgrade file might be named postgis--2.3.4--2.3.5.sql. That’s great if you have four or five versions. We have way more than that. The number of upgrade files we have keeps on growing and growing.

Unlike upgrade files for smaller projects, we drop and recreate all the functions in our upgrade files. That means that actually our current version upgrade file is capable of upgrading any prior version. Nonetheless, we have to make a copy, or a symlink, many many version combinations.

If there was a global “version”, we could use our master upgrade script, and only ship one script for each new version: postgis--ANY--2.3.5.sql

Size Based Costing in the Planner

Right now costing in the planner is based heavily on the “number of rows” a given execution path might generate at each stage. This is fine when the cost of processing each tuple is fairly uniform.

For us, the cost of processing a tuple can vary wildly: calculating the area of a 4 point polygon is far cheaper than calculating the area of a 40000 point polygon. Pulling a large feature out of TOAST tuples is more expensive than pulling it from main storage.

Having function COST taken into more consideration in plans, and having that COST scale with the average size of tuples would make for better plans for PostGIS. It would also make for better plans for PostgreSQL types that can get very large, like text and tsvector.

The analysis hooks might have to be enriched to also ask for stats on average tuple size for a query key, in addition to selectivity, so a query that pulled a moderate number of huge objects might have a higher cost than one that pulled quite a few small objects.

We Are Not Unreasonable People

We just want our due, you know?

Thanks, PostgreSQL team!

Categories: OSGeo Planet

Paul Ramsey: PostGIS Code Sprint 2018 #1

OSGeo Planet - Sun, 2018-09-30 08:00

When I tell people I am heading to an open source “code sprint”, which I try to do at least once a year, they ask me “what do you do there?”

When I tell them, “talk, mostly”, they are usually disappointed. There’s a picture, which is not unearned, of programmers bent over their laptops, quietly tapping away. And that happens, but the real value, even when there is lots of tapping, is in the high-bandwidth, face-to-face communication.

PostGIS Code Sprint 2018 #1

So, inevitably I will be asked what I coded, this week at the PostGIS Code Sprint and I will answer… “uhhhhh”. I did a branch of PostgreSQL that will do partial decompression of compressed tuples, but didn’t get around to testing it. I tested some work that others had done. But mostly, we talked.

PostGIS 3

Why move to PostGIS 3 for the next release? Not necessarily because we will have any earth-shattering features, but to carry out a number of larger changes. Unlike most PostgreSQL extensions, PostGIS has a lot of legacy from past releases and has added, removed and renamed functions over time. These things are disruptive, and we’d like to do some of the known disruptive things at one time.

Split Vector and Raster

When we brought raster into PostGIS, we included it in the “postgis” extension, so if you CREATE EXTENSION postgis you get both vector and raster features. The rationale was that if we left it optional, packagers wouldn’t build it, and thus most people wouldn’t have access to the functionality, so it wouldn’t get used, so we’d be maintaining unused garbage code.

Even being included in the extension, by and large people haven’t used it much, and the demand from packagers and other users to have a “thin” PostGIS with only vector functionality have finally prevailed: when you ALTER EXTENSION postgis UPDATE TO '3.0.0' the raster functions will be unbundled from the extension. They can then be re-bundled into a “postgis_raster” dependent package and either dropped or kept around depending on user preference.

Remove postgis.so Minor Version

For users in production, working with packaged PostgreSQL, in deb or rpm packages, the packaging system often forces you to have only one version of PostGIS installed at a time. When upgrading PostgreSQL and PostGIS the net effect is to break pg_upgrade, meaning PostGIS users are mandated to do a full dump/restore.

Removing the minor version will allow the pg_upgrade process to run through, and users can then run the sql ALTER EXTENSION postgis UPDATE command to synchronize their SQL functions with the new binary postgis.so library.

This is good for most users. It’s bad for users who expect to be able to run multiple versions of PostGIS on one server: they won’t easily be able to. There will be a switch to make it possible to build with minor versions again, but we expect it will mostly be used by us (developers) for testing and development.

Serialization

As I discussed recently, the compression of geometries in PostgreSQL can have a very large effect on performance.

A new serialization could:

  • use a more effective compression format for our kind of data, arrays of autocorrelated doubles
  • add space for more flag bits for things like
    • encoding a smaller point format
    • flagging empty geometries
    • noting the validity of the object
    • noting the presense of a unique hash code
    • extra version bits
    • optional on-disk internal indexes or summary shapes

It’s not clear that a new serialization is a great idea. The only really pressing problem is that we are starting to use up our flag space.

Validity Flag

Testing geometry validity is computationally expensive, so for workflows that require validity a lot of time is spent checking and rechecking things that have already been confirmed to be valid. Having a flag on the object would allow the state to be marked once, the first time the check is done.

The downside of a validity flag is that every operation that alters coordinates must then carefully make sure to turn the flag off again, as the object may have been rendered invalid by the processing.

Exception Policy

A common annoyance for advanced users of PostGIS is when a long running computation stops suddenly and the database announces “TopologyException”!

It would be nice to provide some ways for users to indicate to the database that they are OK losing some data or changing some data, if that will complete the processing for 99% of the data.

We discussed adding some standard parameters to common processing functions:

  • null_on_exception (true = return null, false = exception)
  • repair_on_exception (true = makevalid() the inputs, false = do the null_on_exception action)
Modern C

C is not a quickly changing langauge, but since the PostgreSQL project has moved to C99, we will also be moving to C99 as our checked standard language.

Named Parameters

A lot of our function definitions were written before the advent of default values and named parameters as PostgreSQL function features. We will modernize our SQL extension file so we’re using named parameters everywhere. For users this will mean that correct parameter order will not be required anymore, it will be optional if you use named parameters.

M Coordinate

PostGIS supports “4 dimensional” features, with X, Y, Z and M, but while everyone knows what X, Y and Z are, only GIS afficionados know what “M” is. We will document M and also try and bring M support into GEOS so that operations in GEOS are “M preserving”.

Project Actions Web Site

The web site is getting a little crufty around content, and the slick styling of 7 years ago is not quite as slick. We agreed that it would be OK to modernize, with particular emphasis on:

  • thinking about new user onboarding and the process of learning
  • supporting mobile devices with a responsive site style
  • using “standard” static site infrastructure (jekyll probably)
Standard Data

We agreed that having some standard data that was easy to install would make a whole bunch of other tasks much easier:

  • writing standard workshops and tutorials, so all the examples lined up
  • writing a performance harness that tracked the performance of common queries over time
  • having examples in the reference documentation that didn’t always have to generate their inputs on the fly
News File Policy

It’s a tiny nit, but for developers back-porting fixes over our 4-5 stable branches, knowing where to note bugs in the NEWS files, and doing it consistently is important.

  • Bug fixes applied to stable branches always listed in NEWS for each branch applied to
  • Bug fixes applied to stable and trunk should be listed in NEWS for each branch and NEWS in trunk
  • Bug fixes applied to only trunk can be left out of trunk NEWS (these bugs are development artifacts, not bugs that users in production have reported)
Next…

We also discussed features and changes to PostgreSQL that would help PostGIS improve, and I’ll write about those in the next post.

Categories: OSGeo Planet

Even Rouault: SRS barn raising: 4th report

OSGeo Planet - Fri, 2018-09-28 12:11
This is the fourth progress report of the GDAL SRS barn effort.
The in-progess task at the time of the last report was the addition of a method createFromPROJString() that takes a PROJ string and builds ISO-19111 corresponding objects. It has now been completed for ProjectedCRS. Not all arbitrary valid PROJ strings can be currently mapped to ISO-19111 objects, but at least strings expressing CRS definitions can. A few constructs involving Helmert transforms are also parsed as CoordinateOperation.
A few random tasks completed:
  • Map time-dependent Helmert transforms, and fixes for existing Helmert transforms
  • Map Molodensky and Abridged Molodensky transformation methods from/to PROJ strings
  • Map Longitude rotation transformation method
  • Update to recognize VRF and TRF WKT2-2018 keywords
  • Add import/export of VERTICALEXTENT and TIMEEXTENT WKT2 elements
  • Add import/export of WKT2:2018 USAGE node
  • Progress in implementation of "esoteric" ISO-19111 classes: DatumEnsemble, DynamicVerticalReferenceFrame, OrdinalCS, DerivedProjectedCRS, EngineeringCRS, ParametricCRS, DerivedVerticalCRS
  • Several fixes

The most interesting task regarding the high-level objectives of the roadmap of the barn campaign is the creation of a proj.db SQLite3 database containing CRS (and related objects) and coordinate operations (datum shifts, ...) definitions. The workflow to build it is:
  1. Import EPSG dataset PostgreSQL .sql dumps
  2. Run scripts/build_db.py that will ingest those dumps in a temporary SQLite3 database and then extract needed information from it and marshall it a more digestable form for our final proj.db. At the end the script, outputs new .sql scripts in the data/sql subdirectory of the PROJ directory. We keep in version control those text files, for better tracability of changes.
  3. At make time, we build the proj.db database by importing those .sql scripts.
Steps 1 and 2 are done (typically by PROJ developers) each time you need to update to a newer version.Step 3 is done automatically at PROJ build time, from a git clone or a tarball of an official release.
The proj.db structure allows for multiple authorities. Instead of having a single code column to identify and reference objects, we use a tuple (authority_name, code) as a key, both columns being of text type for better generality. So ('EPSG', '4326') or ('IGNF', 'LAMB1') are possible. At that time, only EPSG derived objects are in the database. Import of other dictionaries are task for later.
Having a database is good, but using it is better. So the next task was to implement a factory class able to build an object in our ISO-19111 modelling from its (auth_name, code). This is now completed for all object categories of the database. The in-progress task is the generalization/augmentation of the current method createOperation(sourceCRS, targetCRS) that creates coordinate method without external input than the definition of the CRS as a createOperations(sourceCRS, targetCRS, context) that also uses the proj.db database to find registered coordinate operations (typically between the geographic CRS), and take into account specified area of interest and desired accuracy, to propose a list of candidate coordinate operations (chaining for example the reverse projection, a datum shift, and a forward projection). I'm also working on a new `projinfo`utility that will be similar in purpose to the `gdalsrsinfo`, offering the possibility to ingest PROJ strings (legacy PROJ.4 format and new PROJ pipelines), WKT 1, WKT 2, authority codes and output as PROJ (legacy and new), WKT 1, WKT2:2015, WKT2:2018. A mode to list coordinate operations possible between two CRS will also be available.

One interesting statistics: the number of lines of C++ code (including blank lines and comments) added to PROJ per this work is now greater than the number of historical C code: 47 000 lines (14 K being tests) vs 43 000.
Categories: OSGeo Planet

Fernando Quadro: GeoServer dominando a INDE

OSGeo Planet - Fri, 2018-09-28 10:30

A INDE está completando esse ano 10 anos de existência desde a publicação do seu decreto em 27 de novembro de 2008. Esse mês foi disponibilizado um novo visualizador dos dados da INDE, com as fontes disponíveis oficialmente até o momento.

Analisando essas fontes percebi que das 21 fontes de dados disponíveis, 20 utilizam software livre (SL) e apenas uma utiliza software proprietário. E o que mais me chamou atenção é que das 20 fontes de SL, 18 utilizam o GeoServer, 2 MapServer e 1 Plataforma ESRI.

Apesar de ter constatado que algumas fontes não disponibilizam toda a informação (apenas WMS, por exemplo), ter visto esse “domínio” do GeoServer foi muito gratificante.

Abaixo, vou colocar o endereço dos servidores (que utilizam GeoServer), para aqueles que tenham interesse em consumí-los:

Dados da Anatel: http://sistemas.anatel.gov.br:80/geoserver/ANATEL/wms
Dados do BNDES: http://www.geoservicos.inde.gov.br/geoserver/BNDES/wms
Dados da FUNAI: http://cmr.funai.gov.br/geoserver/ows
Dados da Embrapa: http://geoinfo.cnpm.embrapa.br/geoserver/ows
Dados do IBGE: http://geoservicos.ibge.gov.br/geoserver/wms
Dados do IBAMA: http://siscom.ibama.gov.br/geoserver/ows
Dados do ICMBIO: http://mapas.icmbio.gov.br/geoserver/ows
Dados do ICA: http://www.aisweb.decea.gov.br/geoserver/ICA/wms
Dados do Min. Plan: http://www.geoservicos.inde.gov.br/geoserver/MPOG/wms
Dados do MDIC: http://geoservicos.inde.gov.br/geoserver/MDIC/wms
Dados da Sec. Ass. Estra: http://geoservicos.inde.gov.br/geoserver/SAE/wms
Dados da SPM: http://www.geoservicos.inde.gov.br/geoserver/SPM/wms
Dados do Espiríto Santo: http://geoserver.geobases.es.gov.br/geoserver/web/
Dados de São Paulo: https://ide.emplasa.sp.gov.br/geoserver/wms (WFS Desabilitado)
Dados INEA/RJ: http://www.geoservicos.inde.gov.br/geoserver/
Dados da UFABC: http://geoservicos.inde.gov.br/geoserver/UFABC/wms
Dados Meio Ambiente MG: http://idesisema.meioambiente.mg.gov.br
Prefeitura de BH: http://bhmapogcbase.pbh.gov.br/bhmapogcbase/ows

Fonte: Visualizador da INDE

Categories: OSGeo Planet

Paul Ramsey: 5x Faster Spatial Join with this One Weird Trick

OSGeo Planet - Fri, 2018-09-28 08:00

My go-to performance test for PostGIS is the point-in-polygon spatial join: given a collection of polygons of variables sizes and a collection of points, count up how many points are within each polygon. It’s a nice way of testing indexing, point-in-polygon calculations and general overhead.

Setup

First download some polygons and some points.

Load the shapes into your database.

shp2pgsql -s 4326 -D -I ne_10m_admin_0_countries.shp countries | psql performance shp2pgsql -s 4326 -D -I ne_10m_populated_places.shp places | psql performance

Now we are ready with 255 countries and 7343 places.

Countries and Places

One thing to note about the countries is that they are quite large objects, with 149 of them having enough vertices to be stored in TOAST tuples.

SELECT count(*) FROM countries WHERE ST_NPoints(geom) > (8192 / 16); Baseline Performance

Now we can run the baseline performance test.

SELECT count(*), c.name FROM countries c JOIN places p ON ST_Intersects(c.geom, p.geom) GROUP BY c.name;

On my laptop, this query takes 25 seconds.

If you stick the process into a profiler while running it you’ll find that over 20 of those seconds are spent in the pglz_decompress function. Not doing spatial algorithms or computational geometry, just decompressing the geometry before handing it on to the actual processing.

Among the things we talked about this week at our PostGIS code sprint have been clever ways to avoid this overhead:

  • Patch PostgreSQL to allow partial decompression of geometries.
  • Enrich our serialization format to include a unique hash key at the front of geometries.

These are cool have-your-cake-and-eat-too ways to both retain compression for large geometries and be faster when feeding them into the point-in-polygon machinery.

However, they ignore a more brutal and easily testable approach to avoiding decompression: just don’t compress in the first place.

One Weird Trick

PostGIS uses the “main” storage option for its geometry type. The main option tries to keep geometries in their original table until they get too large, then compresses them in place, then moves them to TOAST.

There’s another option “external” that keeps geometries in place, and if they get too big moves them to TOAST uncompressed. PostgreSQL allows you to change the storage on columns at run-time, so no hacking or code is required to try this out.

-- Change the storage type ALTER TABLE countries ALTER COLUMN geom SET STORAGE EXTERNAL; -- Force the column to rewrite UPDATE countries SET geom = ST_SetSRID(geom, 4326); -- Re-run the query SELECT count(*), c.name FROM countries c JOIN places p ON ST_Intersects(c.geom, p.geom) GROUP BY c.name;

The spatial join now runs in under 4 seconds.

What’s the penalty?

  • With a “main” storage the table+toast+index is 6MB.
  • With a “external” storage the table+toast+index is 9MB.
Conclusion

For a 50% storage penalty, on a table that has far more large objects than most spatial tables, we achieved a 500% performance improvement. Maybe we shouldn’t apply compression to our large geometry at all?

Using “main” storage was mainly a judgement call back when we decided on it, it wasn’t benchmarked or anything – it’s possible that we were just wrong. Also, only large objects are compressed; since most tables are full of lots of small objects (short lines, points) changing to “external” by default wouldn’t have any effect on storage size at all.

Categories: OSGeo Planet

Fernando Quadro: O elemento ChannelSelection agora aceita expressões no SLD

OSGeo Planet - Thu, 2018-09-27 10:30

A partir do GeoServer 2.14-RC ​​é possível que sejam utilizadas expressões em elementos SourceChannelName quando você estiver criando seu estilo SLD para uma camada raster, permitindo assim a seleção dinâmica de canais. Isso é uma boa notícias para qualquer pessoa que esteja criando aplicativos que exibam dados multiespectrais ou hiperespectrais, evitando assim a necessidade de construir muitos estilos diferentes para as várias combinações de cores que lhe possam ser interessantes.

Aqui está um exemplo de SLD:

<RasterSymbolizer>   <ChannelSelection>     <RedChannel>       <SourceChannelName>           <ogc:Function name="env">              <ogc:Literal>B1</ogc:Literal>              <ogc:Literal>2</ogc:Literal>           </ogc:Function>       </SourceChannelName>     </RedChannel>     <GreenChannel>       <SourceChannelName>           <ogc:Function name="env">              <ogc:Literal>B2</ogc:Literal>              <ogc:Literal>5</ogc:Literal>           </ogc:Function>       </SourceChannelName>     </GreenChannel>     <BlueChannel>       <SourceChannelName>           <ogc:Function name="env">              <ogc:Literal>B3</ogc:Literal>              <ogc:Literal>7</ogc:Literal>           </ogc:Function>       </SourceChannelName>     </BlueChannel>   </ChannelSelection> <RasterSymbolizer>

Fonte: GeoServer Blog

Categories: OSGeo Planet

gvSIG Team: Taller sobre gvSIG aplicado a Geología en las 14as Jornadas Internacionales gvSIG

OSGeo Planet - Thu, 2018-09-27 08:48

El próximo jueves 25 de octubre en Valencia (España), durante las 14as Jornadas Internacionales gvSIG, se impartirá un taller gratuito sobre gvSIG aplicado a Geología.

gvSIG resulta una herramienta útil para la representación y análisis de datos geológicos. La integración de datos obtenidos desde distintas fuentes y a partir de bases de datos no homogéneas puede fácilmente realizarse a partir de gvSIG. Esta integración puede permitir analizar la distribución de dichos datos pero también servir como base para la realización de cálculos sencillos que pueden ser de interés para la previsión de las variaciones en profundidad de elementos geológicos como también sobre la variación de los espesores de unidades en el subsuelo. Por otro lado, estos datos pueden integrarse con observaciones tomadas en campo (fotografías, datos estructurales o contactos de unidades geológicas). La versatilidad del análisis que ofrece esta herramienta permite también la integración con otras fuentes de información relacionadas con el conocimiento del patrimonio arqueológico, natural o distintas figuras ambientales.

Por otro lado el análisis integrado puede permitir la toma de decisiones relacionadas con cuestiones tan dispares como la investigación de recursos minerales, la protección del patrimonio paleontológico, la rentabilidad económica de una explotación minera o su viabilidad ambiental. En este taller abordaremos este tipo de análisis y analizaremos herramientas de edición y geoprocesos de gvSIG desde una perspectiva geológica, realizando una cartografía geológica a partir de datos tomados en campo y la planificación de una investigación geológica. Además se utilizarán fuentes de información pública procedentes del Instituto Geológico y Minero de España (IGME), el Instituto Geográfico Nacional (IGN), Confederaciones Hidrográficas o sobre figuras de protección ambiental (en este caso en Aragón).

El taller se realizará en el Aula 1.5 (Ptolomeo) de la Escuela Técnica Superior de Ingeniería Geodésica, Cartográfica y Topográfica (Universitat Politècnica de València), que dispone de ordenadores, por lo que no  es necesario llevar ordenador propio.

Las inscripciones al taller se abrirán el día 4 de octubre en el siguiente enlace. Las plazas serán limitadas.

Aparte, te recordamos que el periodo de inscripción a las jornadas ya está abierto, pudiendo realizarse el registro a través del formulario habilitado para ello, siendo además obligatorio para la realización de los talleres.

Categories: OSGeo Planet
Syndicate content