OSGeo Planet

GeoServer Team: GeoServer the most popular choice for Brazil SDI

OSGeo Planet - Wed, 2018-09-26 13:43

Last week the Brazilian government released a list of government agencies that have already implemented their spatial data infrastructure (SDI). This list has 21 agencies, and the interesting thing is that 18 out of 21 use GeoServer in their SDI.

Portal of Brazil’s spatial data infrastructure

Brazil has a 2008 decree, which establishes the creation of spatial data infrastructure by government agencies, and since then, this process of spatial data availability has been growing in the country.

Below, the GeoServer address of some of these agencies:

A spatial data infrastructure (SDI) is a data infrastructure implementing a framework of geographic data, metadata, users and tools that are interactively connected in order to use spatial data in an efficient and flexible way (Wikipedia, 2018).

Categories: OSGeo Planet

Fernando Quadro: Ajustando o PostgreSQL para melhorar a performance do PostGIS

OSGeo Planet - Wed, 2018-09-26 10:30

O PostgreSQL é um sistema de banco de dados muito versátil, capaz de funcionar eficientemente em ambientes de recursos muito baixos e ambientes compartilhados com uma variedade de outros aplicativos. Para garantir que ele seja executado adequadamente em muitos ambientes diferentes, a configuração padrão é muito conservadora e não é muito apropriada para um banco de dados de produção de alto desempenho. Adicione o fato de que os bancos de dados geoespaciais têm padrões de uso diferentes, e os dados tendem a consistir em menos registros, muito maiores do que os bancos de dados não espaciais, e você pode ver que a configuração padrão não será totalmente apropriada para nossos propósitos.

Com esse objetivo, irei apresentar abaixo alguns parâmetros que você pode alterar para que o seu PostGIS “voe”. Para cada parâmetro irei dar uma breve descrição falando para que ele serve, o seu valor padrão e qual o valor que sugiro a você alterá-lo.

Lembrando que essa é uma sugestão e você analisando sua infraestrutura e o volume da sua base de dados pode colocar valores mais apropriados para sua realidade.

1. Configurações no postgresql.conf:

1.1 Shared buffer: Define a quantidade de memória que o servidor de banco de dados usa para buffers de memória compartilhada. Estes são compartilhados entre os processos de back-end, como o nome sugere. Os valores padrão são normalmente insuficientes para bancos de dados de produção.

Valor padrão: 32 mb
Valor recomendado: Até 75% da memória do banco de dados

1.2 Work men: Define a quantidade de memória que as operações internas de classificação e as tabelas de hash podem consumir antes de o banco de dados alternar para arquivos em disco. Este valor define a memória disponível para cada operação; consultas complexas podem ter várias operações de classificação ou hash sendo executadas em paralelo e cada sessão conectada pode estar executando uma consulta.

Dessa forma, você deve considerar quantas conexões e a complexidade das consultas esperadas antes de aumentar esse valor. O benefício de aumentar é que o processamento de mais dessas operações, incluindo cláusulas ORDER BY e DISTINCT, junções de mesclagem e hash, agregação baseada em hash e processamento baseado em hash de subconsultas, pode ser realizado sem incorrer em gravações em disco.

Valor padrão: 1 mb
Valor recomendado: 16 MB

1.3 Maintenance_work_mem: Define a quantidade de memória usada para operações de manutenção, incluindo criação de aspiração, índice e chave estrangeira. Como essas operações não são muito comuns, o valor padrão pode ser aceitável.

Valor padrão: 1 mb
Valor recomendado: 16 MB

1.4 Wal_buffers: Define a quantidade de memória usada para dados de registro de adiantamento (WAL). Os registros de write-ahead fornecem um mecanismo de alto desempenho para garantir a integridade dos dados. Durante cada comando de alteração, os efeitos das alterações são gravados primeiro nos arquivos WAL e liberados no disco. Apenas quando os arquivos WAL forem liberados, as alterações serão gravadas nos próprios arquivos de dados. Isso permite que os arquivos de dados sejam gravados no disco de maneira ideal e assíncrona, garantindo que, em caso de falha, todas as alterações de dados possam ser recuperadas do WAL.

O tamanho desse buffer precisa ser grande o suficiente para conter os dados do WAL para uma única transação típica. Embora o valor padrão geralmente seja suficiente para a maioria dos dados, os dados geoespaciais tendem a ser muito maiores. Portanto, recomenda-se aumentar o tamanho desse parâmetro.

Valor padrão: 64k
Valor recomendado: 1 MB

1.5 Checkpoint_segments: Esse valor define o número máximo de segmentos do arquivo de log (geralmente 16 MB) que podem ser preenchidos entre os pontos de verificação automáticos da WAL. Um ponto de verificação do WAL é um ponto na sequência de transações do WAL no qual é garantido que os arquivos de dados foram atualizados com todas as informações antes do ponto de verificação. Neste momento, todas as páginas de dados sujas são liberadas para o disco e um registro de ponto de verificação é gravado no arquivo de log. Isso permite que o processo de recuperação de falhas localize o último registro de ponto de verificação e aplique todos os segmentos de log a seguir para concluir a recuperação dos dados.

Como o processo de ponto de verificação exige a liberação de todas as páginas de dados sujas no disco, ele cria uma carga de I/O significativa. O mesmo argumento acima se aplica; Os dados geoespaciais são grandes o suficiente para desequilibrar as otimizações não geoespaciais. Aumentar esse valor impedirá pontos de verificação excessivos, embora isso possa fazer com que o servidor reinicie mais lentamente no caso de uma falha.

Valor padrão: 3
Valor recomendado: 6

1.6 Randon_page_cost: Esse é um valor sem unidade que representa o custo de um acesso aleatório a uma página do disco. Esse valor é relativo a vários outros parâmetros de custo, incluindo acesso sequencial à página e custos de operação da CPU. Embora não haja um marcador mágico para esse valor, o padrão é geralmente conservador.

Valor padrão: 4.0
Valor recomendado: 2.0

1.7 Seq_page_cost: Esse é o parâmetro que controla o custo de um acesso de página seqüencial. Esse valor geralmente não requer ajuste, mas a diferença entre esse valor e random_page_cost afeta muito as escolhas feitas pelo planejador de consulta. Esse valor também pode ser definido em uma base por sessão
Valor padrão: 1.0
Valor recomendado: 1.0

Após alterar a configuração do banco é necessário reiniciar o serviço para que elas possam ser carregadas. Com a alteração desses parâmetros o banco de dados já deve ter um aumento significativo na performance.

Fonte: Boundless

Categories: OSGeo Planet

gvSIG Team: Inscripciones abiertas en las 5as Jornadas gvSIG Uruguay

OSGeo Planet - Tue, 2018-09-25 15:34

Ya se encuentran abiertas las inscripciones de las 5as Jornadas gvSIG Uruguay y 3as Jornadas de Tecnologías Libres de Información Geográfica y Datos Abiertos, que se celebrarán los próximos días 18 y 19 de octubre en Montevideo (Uruguay).

Las inscripciones son totalmente gratuitas, y pueden realizarse a través del formulario habilitado en la web del evento. Las salas tienen aforo limitado, por lo que se recomienda no dejar las inscripciones para los últimos días.

Por otro lado, en unos días se publicará el programa de las jornadas con todas las ponencias y talleres que se van a impartir durante las mismas.

 

Categories: OSGeo Planet

Fernando Quadro: Definição de escalas no SLD

OSGeo Planet - Tue, 2018-09-25 10:30

Você já deve ter tido a ideia de utilizar escala para melhorar a performance do seu mapa, ou apenas deixar ele mais clean. Digo isso, pois apresentar todas as camadas e/ou todas as feições de uma camada no carregamento do mapa não é interessante nem visualmente, e nem para performance da sua aplicação.

Para definir em qual nível de zoom queremos que uma determinada informação seja apresentada precisamos utilizar as propriedades MinScaleDenominator e MaxScaleDenominator em nosso SLD. Porém, em muitos casos testamos ele em nosso editor de estilos (uDig, por exemplo) e tudo parece normal, mas quando carregamos na aplicação, dá problema!

Se você está projetando um mapa e planeja sobrepor ao Google Maps, Bing, entre outros e criar um esquema de mosaico, eu acho que o que você está procurando são as escalas para cada nível de zoom, neste caso você pode usar estas:

20 : 1128.497220 19 : 2256.994440 18 : 4513.988880 17 : 9027.977761 16 : 18055.955520 15 : 36111.911040 14 : 72223.822090 13 : 144447.644200 12 : 288895.288400 11 : 577790.576700 10 : 1155581.153000 9 : 2311162.307000 8 : 4622324.614000 7 : 9244649.227000 6 : 18489298.450000 5 : 36978596.910000 4 : 73957193.820000 3 : 147914387.600000 2 : 295828775.300000 1 : 591657550.500000

Com base nessas escalas, defina da forma que você achar mais adequado apresentar as informações na sua aplicação!

Fonte: StackExchange GIS

Categories: OSGeo Planet

Blog 2 Engenheiros: Como fazer uma Curva Hipsométrica usando GRASS GIS?

OSGeo Planet - Tue, 2018-09-25 06:00

Existe uma forte correlação entre as características hidrológicas e do relevo de uma bacia hidrográfica.

Horton (1932) apresenta vários fatores para a descrição da drenagem de uma bacia hidrográfica. Entre esses fatores, estão os morfológicos, aqueles relacionados ao relevo e às formas e tamanho do sistema de rios.

Uma forma de descrever e apresentar de forma sucinta uma das características da bacia hidrográfica é por meio da Curva Hipsométrica.

O que é uma Curva Hipsométrica?

A curva hipsométrica é representada por um gráfico com a relação entre a área ocupada pela referida altitude da bacia hidrográfica.

Também existem outros fatores para descrição do relevo, alguns deles são gradiente do canal, perfil da declividade e densidade de drenagem (STRAHLER, 1952).

A curva hipsométrica, ou hipsográfica, pode tanto ser representada por dados absolutos (onde o eixo x apresenta a área e o eixo y a altitude), ou relativos (em percentuais da área e altitude máxima).

Strahler (1952) coloca que o uso da curva hipsométrica com valores em percentuais é mais vantajoso pois permite que a curva obtida seja comparada com outras curvas de bacias hidrográficas com tamanhos, formas e altitude diferentes.

Curva Hipsométrica calculada com o comando r.ipso  (Benigno, 2012).Curva Hipsométrica calculada com o comando r.ipso (Benigno, 2012).

Quais tipos de informações podemos obter a partir da curva hipsométrica?

Observando a figura anterior, podemos afirmar que aproximadamente 40% da área estudada pelo autor apresenta cotas superiores à 40% da cota máxima.

Outra interpretação seria que 80% da área esta em cotas superiores à 20% da cota máxima.

A curva hipsométrica, ao passar no “meio” do gráfico, tende a representar relevos em equilíbrio (maturo), enquanto a curva ao se estender para o canto superior direito, representa ambientes novos. Curvas que se concentram na parte inferior esquerda caracterizam ambientes com geologia específica, onde rochas mais resistentes ao intemperismos formam transições abruptas de altitude.

Curvas Hipsométrica no GRASS GIS

Se você é usuário do QGIS, já sabe que existem vários plugins que são “emprestados” do GRASS GIS.

Embora alguns desses plugins tenham como objetivo criar a curva hipsométrica no QGIS (fato que não consegui realizar), iremos apresentar aqui como realizar esse procedimento no GRASS GIS 7.4.0.

Instalaremos o addon r.hypso no GRASS GIS e para que a instalação seja feito com sucesso, utilize a versão mais recente do GRASS SIG.

Assim como o QGIS, o GRASS GIS também é uma ferramenta de geoprocessamento. Caso você já tenha o QGIS instalado, provavelmente ele também estará (mas você pode baixar ele no site oficial também).

Neste tutorial, iremos utilizar os mapas topográficos disponibilizados na Mapoteca da EPAGRI, onde iremos montar a curva hipsométrica da região hidrográfica do extremo sul catarinense.

Se você baixar o MDT da mapoteca da EPAGRI, lembre-se de reprojetar ele para um datum convencional, pois ele vem no CRS USER: 100002.

Ao abrir o GRASS GIS, inicialmente ele vai abrir uma janela de comando e em seguida, uma janela de inicialização onde você irá fornecer os seguintes itens:

  • GRASS GIS Database Directory: Diretório onde serão salvos todos os projetos que você realizar no GRASS GIS;
  • GRASS Location: Aqui você indicara seus projetos (lembrando que os dados de cada projeto devem estar todos no mesmo sistema de coordenadas, sendo que ao criar um projeto novo, será solicitado qual sistema de coordenadas será utilizado);
  • GRASS Mapset: Conjunto de mapas que serão elaborados dentro do projeto anteriormente citado.

A figura abaixo mostra nosso projeto e conjunto de mapas criados.

Janela de Inicialização do GRASS GIS.Janela de Inicialização do GRASS GIS.

Após indicar onde serão salvos seus projetos, o nome do novo projeto e o nome do conjunto de mapas, clique em “Start GRASS Session”.

Em seguida, o compositor de camadas (Layer Manager) e o visualizador de mapas (Map Display) serão abertos.

Trabalhando dentro do GRASS GIS

Agora, vamos importar o MDT que baixamos para o nosso projeto. Esse procedimento é realizado clicando-se em File > Import Raster Data > Simplified raster import with projection [r.import].

Note que ao lado das funções, entre colchetes, há o nome da função para ser utilizada na linha de comando (console).

Importando rasters para dentro do GRASS.Importando rasters para dentro do GRASS.

Na janela que será aberta, você só precisará indicar a localização do raster e importá-lo. Se tudo ocorrer corretamente, o MDT aparecerá no visualizador de mapas.

Ok. Já temos nosso MDT  carregado, agora vamos instalar o r.hypso, pois algumas ferramentas do GRASS GIS são instaladas separadamente.

Para instalar um addon no GRASS, clique em Settings > Addons Extensions > Install Extensions from Addons. Na janela aberta, procure por r.hypso (dentro de Raster) e clique em Install.

Instalando addon r.hypso no GRASS.Instalando addon r.hypso no GRASS.

No GRASS GIS, após instalar qualquer Addon, eles estarão disponíveis na janela do gerenciador de camadas (layer manager), especificamente na aba Modules. Lá, procure por Addons e pelo r.hypso.

Caso ele não apareça, você terá que rodar o addon pela linha de comando (console) do GRASS – e é isso que iremos fazer.

Conferindo o manual do GRASS, podemos verificar quais parâmetros devemos fornecer para rodar o comando r.hypso. Confira abaixo o comando.

r.hypso map=mde_rh10 image=C:\Users\ferna\Desktop\B2E\curvaHip -a -b

Veja que fornecemos para o item map o nome do nosso MDT; para o item image onde serão salvos os arquivos e quais serão o seus nomes e usamos as bandeiras -a e -b para pedir ao GRASS gerar a curva hipsométrica (percentual) e hipsográfica (absoluta), respectivamente.

(1) Aba Console para acessar linha de comando; (2) Comando para rodar o r.hypso; (3) Curva Hipsométrica na forma de tabela.(1) Aba Console para acessar linha de comando; (2) Comando para rodar o r.hypso; (3) Curva Hipsométrica na forma de tabela.

Na figura acima, observe que o GRASS nos fornece a curva hipsométrica na forma de tabela (3) também.

Ao entrar na pasta fornecida, você notará dois arquivos no formato PNG com as curvas hipsométricas da área de estudo. Abaixo mostramos os nossos resultados obtidos.

Realizando a leitura dos dados absolutos (Curva Hipsográfica), é possível notar que 1000 km2 da região hidrográfica esta em cotas superiores à 400 metros.

Também observamos que grande parte dela encontram-se em locais com altitudes baixas. A figura abaixo, também obtida no GRASS, deixa tudo isso bem claro.

MDT em 3D gerado no GRASS para o arquivo usado neste tutorial.MDT em 3D gerado no GRASS para o arquivo usado neste tutorial.

Ficou com alguma dúvida ou tem alguma sugestão de postagem? Fique a vontade e utilize os comentários para falar conosco.

Fontes Consultadas: BENIGNO, Marcello. Determinação da Curva Hipsométrica de uma Bacia Hidrográfica com o GRASS SIG. 2012. Disponível em: <http://profmarcello.blogspot.com/2012/11/determinacao-da-curva-hipsometrica-de.html>. Acesso em 22 set. 2018. HORTON, R.E. Drainage-Basin Characteristics. Eos, Transactions American Geophysical Union. V. 13, n. 1. 1932. pg. 350-361. STRAHLER, A.N. Hypsometric (Area-Altitude) Analysis of Erosional Topography. Geological Society of America Bulletin. v. 63, 1952. pg. 1117-1142.
Categories: OSGeo Planet

GeoServer Team: Java 2018 Code Sprint

OSGeo Planet - Mon, 2018-09-24 19:57

Java 11 is released tomorrow! GeoServer has a window until January 2019 before Java 8 is no longer officially supported!

To make the transition the GeoServer team is setting up a Java 2018 Code Sprint – and we need your support to help enough participants attend!

  • October 22-26th
  • Groups gathering in North America, Europe and Oceania

With recent policy changes setting the Java platform on a six-month release cycle. We also have significant work ensuring the libraries we use either work with the “jigsaw” module system or are replaced.

Already we have identified changes needed for GeoServer to run at all:

  • Upgrade Spring: The application framework uses the reflection feature of Java to wire GeoServer together – and needs to be updated to work with the additional Java 11 restrictions.
  • Upgrade Log4J: A Java 11 compatible version of Log4J is available and provides tools for visualization and exploring log messages.
  • Repackage the application adding automatic module names

Our goal is to ensure that the next release of GeoServer can run with Java 8 or Java 11.

How to participate

Please visit the osgeo wiki page and add yourself to the list of participants. We are trying to bring as contributors together as possible and would love it if you could join us!

In addition to GeoServer representatives from GeoTools and GeoNetwork will be taking part.

How to sponsor

We have three sponsorship levels available, with contributions devoted to helping participants attend:

  • Gold: $7500 USD
  • Silver: $1500 USD
  • Bronze: $750 USD

Sponsor logos are included on the event page and blog posts in addition to being featured in the associated project release announcements. More importantly your financial support goes towards making sure GeoServer remains available on a supported Java platform.

Please see the wiki page for details on how to sponsor.

Categories: OSGeo Planet

GeoServer Team: GeoServer 2.14.0 Released

OSGeo Planet - Mon, 2018-09-24 16:00

We are happy to announce the release of GeoServer 2.14.0. Downloads are available (zipwar, and exe) along with docs and extensions.

This is the first stable release of the 2.14 series of GeoServer, and is recommended for all production systems. With this release, the 2.13 series moves to maintenance, and the 2.12 series moves to unsupported.

This release is made in conjunction with GeoTools 20.o and GeoWebCache 1.14.0

This release includes a number of new features and improvements:

WMS “nearest match” support for time dimension

WMS time dimension can now be configured for “nearest match”, that is, to return the nearest time to the one requested (either explicitly, or implicitly via the default time value).

In case of mismatch the actual time used will be returned along with the response as a HTTP header. It is also possible to configure a maximum tolerance, beyond that the server will throw a service exception.

Channel selection name allow expressions

GeoServer 2.14.0 allows expressions to be used in SourceChannelName SLD elements, and in their code counterpart, thus allowing dynamic channel selection. This is welcomed news for anyone building applications that display multispectral or hyperspectral data, thus avoiding the need to build many different styles for the various interesting false color combinations.

Here is an SLD example:

<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> Map algebra

This release adds support for an efficient map algebra package knows as Jiffle. Jiffle has been the work of a former GeoTools contributor, Michael Bedwards, that has been salvaged, upgraded to support Java 8, and integrated in jai-ext. From the there support has been added into the GeoTools gt-process-raster module and as a result in GeoServer WPS, to be used either directly or as a rendering transformation.

The following SLD style calls onto Jiffle to perform a NDVI calculation on top of Sentinel 2 data:

<?xml version="1.0" encoding="UTF-8"?> <StyledLayerDescriptor 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" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd" version="1.0.0"> <NamedLayer> <Name>Sentinel2 NDVI</Name> <UserStyle> <Title>NDVI</Title> <FeatureTypeStyle> <Transformation> <ogc:Function name="ras:Jiffle"> <ogc:Function name="parameter"> <ogc:Literal>coverage</ogc:Literal> </ogc:Function> <ogc:Function name="parameter"> <ogc:Literal>script</ogc:Literal> <ogc:Literal> nir = src[7]; vir = src[3]; dest = (nir - vir) / (nir + vir); </ogc:Literal> </ogc:Function> </ogc:Function> </Transformation> <Rule> <RasterSymbolizer> <Opacity>1.0</Opacity> <ColorMap> <ColorMapEntry color="#000000" quantity="-1"/> <ColorMapEntry color="#0000ff" quantity="-0.75"/> <ColorMapEntry color="#ff00ff" quantity="-0.25"/> <ColorMapEntry color="#ff0000" quantity="0"/> <ColorMapEntry color="#ffff00" quantity="0.5"/> <ColorMapEntry color="#00ff00" quantity="1"/> </ColorMap> </RasterSymbolizer> </Rule> </FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>

The performance is good enough for interactive display, and the result looks as follows (click to enlarge):

PostGIS store improvements and measured geometries support

The PostGIS datastore has been for years the only one that could encode a few filter functions used in filters down into native SQL, but it required a datastore creation flag to be enabled.
Starting with this release it will do so by default.

The functions supported for SQL encoding by the store are:

  • String functions: strConcat, strEndsWith, strStartsWith, strEqualsIgnoreCase, strIndexOf, strLength, strToLowerCase, strToUpperCase, strReplace, strSubstring, strSubstringStart, strTrim, strTrim2
  • Math functions: abs, abs_2, abs_3, abs_4, ceil, floor
  • Date functions: dateDifference

This release adds support for “array” data type in the store, with full reading and writing support, as well as native filtering (with index support, where feasible).

Finally, it’s now possible to read geometries with measures from PostGIS and encode the results in GML. GML does not natively support measures, so the encoding is off by default and you’ll have to enable it explicitly, as well as ensure that the clients involved in WFS usage recognize this extra ordinate. The work will continue in the next few month in order to cover more formats.

 

Image mosaic improvements

The image mosaic module never sleeps, in this release we see the following improvements:

  • Support for remote images (e.g. S3 or Minio). In order to leverage this the mosaic index will have to be created up-front (manually, or with some home grown tools)
  • A new “virtual native resolution” read parameter allows the mosaic to compose outputs respecting a native resolution other than its native one (useful in case you want to give selective resolution access to different users)
  • Supporting multiple WKBs footprint for pixel precise overviews masking
  • A new read mask parameter allows to cut the image to a given geometry (again, helps in providing different selective views to different users)
  • Speed up NetCDF mosaics by allowing usage of stores coming from a repository, instead of re-creating them every time a NetCDF file is needed (to be setup in the auxiliary store config file, while the repository instance needs to be passed as a creation hint).
  • The mosaic now works against images without a proper CRS, setting them into the “CRS not found” wildcard CRS, aka “EPSG:404000”
App-schema improvements

The app-schema module got significant performance and functionality improvements since 19.x series, in particular:

  • Better delegation of spatial filters on nested properties to native database
  • Improved support for multiple nested attribute matches in filters
  • It is now possible to use Apache SOLR as a data source for app-schema
  • The configuration files can be hosted on a remote HTTP server
The MongoDB store upgrades to official extension

Wanted to use the MongoDB store but worried about its unsupported status? Worry no more, in GeoServer 2.14 the MongoDB datastore upgraded to official extension status.

Style editor improvements

The GeoServer style editor now includes a fullscreen side-by-side editing mode, to make it easier to preview your styles while editing them. Click the fullscreen button at the top-right of the screen to toggle fullscreen mode.

The toolbar also has two new additions, a color picker helping to find the right color and turn it into a HEX specification, and a file chooser that allows to pick an external graphic and build the relevant ExternalGraphic element:

 

Windows build restored

GeoServer failed to properly build on Windows for a long time. GeoServer 2.14.x is the first branch in years to successfully build on Windows, and we have added an AppVeyor build to help keep the build going in the future.

The work to make it build there has been fully done in spare time, and we are still experiencing random build failures. If you are a Java developer on Windows, we could really use your help to keep GeoServer Windows build friendly.

New community modules

The 2.14 series comes with a few new community modules, in particular:

  • OAuth2 OpenID connect module (still very much a work in progress)
  • A WFS3 implementation has been added that matches the current WFS3 specification draft, and it’s being updated to become an official compliant one.

Mind, community modules are not part of the release, but you can find them in the nightly builds instead.

JTS Upgrade

Java Topology Suite (JTS) has been upgraded to version 1.16. This marks a significant change in package naming, the library has switched from “com.vividsolutions” to “org.locationtech”  packages and all GeoServer code has been updated to follow suit.

This has some side-effects on output produced by REST featuretype and structured coverage requests, specifically the package names used for geometry types in the binding parameter of any geometry attributes.

Any REST clients which rely on this binding information should be updated to support the new names. GeoServer will still support reading the old “com.vividsolutions” names, but will only output the new”org.locationtech” names.

For more details, refer to the upgrade guide in the GeoServer documentation.

Other assorted improvements

There are many improvements to look at in the release notes (2.14.02.14-RC), cherry picking a few here:

  • The ncWMS community module has seen significant performance improvements
  • WPS has a CSV input/output supporting geometryless data, as well as geometries with WKT encoding, as well as supporting pure PNG/JPEG image for raster data
  • Time/Elevation parsers are no longer silently cutting the read data to 100 entries
  • The WMTS multidimensional GetHistogram operation is now significantly faster, and a new GetDomainValues operation allows to page through the values of a domain (time, elevation) that has too many values to be efficiently explored with DescribeDomain or GetFeature. The DescribeDomain was also improved to allow a selection of the domains that should be described.
  • The SLDService community module has now the ability to return a full SLD style (as opposed to snippets), allows for custom classification and custom color selection. Also, keep an eye on this module, as it’s about to graduate to supported status
  • The monitoring module can now log the hit/miss status of tiled requests, quite helpful to verify the benefit of caching, especially while using WMS direct integration
  • Fix “Chunk [] is not a valid entry” error for the embedded GWC reload endpoint
  • Tiled layers preview does not use Proxy Base Url
  • featuretype.xml bindings reference com.vividsolutions.jts classes
Security consideration

Please update your production instances of GeoServer to receive the latest security updates and fixes.

This release addresses several security vulnerabilities:

  • Prevent arbitrary code execution via Freemarker Template injection
  • XXE vulnerability in GeoTools XML Parser
  • XXE vulnerability in WPS Request builder
  • Various library upgrades (see above) from versions with known CVEs
  • Potential access to admin pages without being logged in

Thanks to Steve Ikeoka, Kevin Smith, Brad Hards, Nuno Oliveira and Andrea Aime for providing fixes to these issues.

If you encounter a security vulnerability in GeoServer, or any other open source software, please take care to report the issue in a responsible fashion.

About GeoServer 2.14
Categories: OSGeo Planet

GeoTools Team: GeoTools 20.0 Released

OSGeo Planet - Mon, 2018-09-24 15:59
The GeoTools team is pleased to announce the release of GeoTools 20.0: geotools-20.0-bin.zip geotools-20.0-doc.zip geotools-20.0-userguide.zip geotools-20.0-project.zip This is the first release of the 20.x series, now marked as stable and deemed suitable for production systems, while 19.x switches to maintenance mode and 18.x moves to unsupported. This release is also available from our
Categories: OSGeo Planet

Fernando Quadro: Substituição de variáveis no SLD

OSGeo Planet - Mon, 2018-09-24 10:30

A substituição de variáveis ​​no SLD é uma funcionalidade do GeoServer (adicionada na versão 2.0.2) que permite passar valores nas requisições WMS para estilos. Isso permite definir valores dinamicamente, como cores, fontes, tamanhos e limites de filtro.

As variáveis ​​são especificadas nas requisições GetMap do WMS usando o parâmetro env seguido por uma lista de nomes e valores separados por ponto e vírgula conforme demonstrado abaixo:

...&env=name1:value1;name2=value2&...

Em um SLD, os valores das variáveis ​​são acessados ​​usando a função env que recupera um valor de variável especificado substituindo na solicitação atual:

<ogc:Function name="env">    <ogc:Literal>size</ogc:Literal> </ogc:Function>

Um valor padrão pode ser fornecido, e será usado se a variável não for especificada na solicitação:

<ogc:Function name="env">    <ogc:Literal>size</ogc:Literal>    <ogc:Literal>6</ogc:Literal> </ogc:Function>

A função env pode ser usada em um SLD em qualquer lugar onde uma expressão OGC é permitida. Por exemplo, ele pode ser usado em elemento CSSParameter, em elementos de tamanho e deslocamento e até em expressões de filtros nas regra. Também é aceito em alguns lugares onde expressões completas não são permitidas, como no elemento Mark/WellKnownName.

O seguinte elemento Symbolizer foi parametrizado em três locais, com os valores padrão fornecidos em cada caso, veja:

<PointSymbolizer>   <Graphic>     <Mark>       <WellKnownName><ogc:Function name="env">             <ogc:Literal>name</ogc:Literal>             <ogc:Literal>square</ogc:Literal>          </ogc:Function>       </WellKnownName>       <Fill>         <CssParameter name="fill">           <ogc:Function name="env">             <ogc:Literal>color</ogc:Literal>             <ogc:Literal>FF0000</ogc:Literal>          </ogc:Function>         </CssParameter>       </Fill>     </Mark>     <Size>        <ogc:Function name="env">           <ogc:Literal>size</ogc:Literal>           <ogc:Literal>6</ogc:Literal>        </ogc:Function>     </Size>   </Graphic> </PointSymbolizer>

Quando nenhuma variável é fornecida na requisição WMS, o SLD usa os valores padrão e renderiza o conjunto de dados, conforme mostrado abaixo na camada sf:bugsites:

Se a solicitação for alterada para especificar os seguintes valores de variáveis:

&env=color:00FF00;name:triangle;size:12

O resultado então será:

Agora basta você aplicar nos seus estilos SLD.

Fonte: GeoServer Documentation

Categories: OSGeo Planet

GeoSolutions: GeoSolutions workshop and presentation at INSPIRE Conference 2018

OSGeo Planet - Mon, 2018-09-24 09:44

INSPIRE Conference 2018

Dear All, we are writing this blog post to thank all those who attended our GeoServer workshop and presentation, as well as those who talked to us at our booth at the INSPIRE Conference 2018 in Antwerp last week.

The material for the GeoServer is available online here (see the INSPIRE and Complex Features sections) and it requires you to download the training package, available here, that contains all the data and software needed to perform the exercises (find the instructions for getting started here).

As of the presentation INSPIRE services with GeoServer and HALE, where are we? we gave, you can find it here below.

If you are interested in learning about how we can help you achieving your goals with our open source products GeoServer, GeoNodeMapStore and GeoNetwork as well as throw our Enterprise Support Services and GeoServer Deployment Warranty offerings, feel free to contact us!

The GeoSolutions team,
Categories: OSGeo Planet

PostGIS Development: PostGIS 2.5.0

OSGeo Planet - Sun, 2018-09-23 00:00

The PostGIS development team is pleased to release PostGIS 2.5.0.

Although this release will work for PostgreSQL 9.4 and above, to take full advantage of what PostGIS 2.5 offers, you should be running PostgreSQL 11beta4+ and GEOS 3.7.0 which were released recently.

Best served with PostgreSQL 11 beta4 and pgRouting 2.6.1.

WARNING: If compiling with PostgreSQL+JIT, LLVM >= 6 is required Supported PostgreSQL versions for this release are: PostgreSQL 9.4 - PostgreSQL 12 (in development) GEOS >= 3.5

2.5.0

Continue Reading by clicking title hyperlink ..
Categories: OSGeo Planet

Fernando Quadro: WMS com suporte “nearest match” para a dimensão Tempo

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

A dimensão de tempo do WMS agora pode ser configurada para “nearest match” também conhecida como “correspondente mais próximo”, ou seja, para retornar a hora mais próxima da solicitada (de forma explícita ou implícita pelo valor de hora padrão).

Em caso de incompatibilidade, o tempo real usado será retornado junto com a resposta como um cabeçalho HTTP. Também é possível configurar uma tolerância máxima, além de que o servidor lançará uma exceção de serviço.

Fonte: GeoServer Blog

Categories: OSGeo Planet

gvSIG Team: Workshop about digital field mapping and data centralization at 14th International gvSIG Conference

OSGeo Planet - Fri, 2018-09-21 09:32

During the 14th International gvSIG conference, held the next 24-26th October in Valencia, a workshop about digital field mapping and data centralization will be given.

During the workshop the users will be initially guided through the installation and use of the digital field mapping app geopaparazzi/gvSIG Mobile.

The user will then be presented with the Geopaparazzi Survey Server and the data synchronization app, that allows to synchronize the survey data from a geopaparazzi/gvSIG Mobile project to the centralized server. The user will learn how to customize the surveyor’s information on the central database and browse the aggregated survey data on the server. This will be done on the dashboard of the server but also on the map view, from which the user will be able to select the work of a particular surveyor and peak into the surveyed data.

During the workshop also the export options to KMZ and PDF from the server will be shown.

If your are active in the field of digital field mapping you should not miss this workshop! All the information about registration and requirements (cartography, installation…) will be available at this post soon.

Categories: OSGeo Planet

Paul Ramsey: Digital Transformation and Fundamental Change

OSGeo Planet - Fri, 2018-09-21 07:00

I’m a huge supporter of modernizing government IT practices, but there’s something apocolyptic about the rhetoric of “digital transformation” folks which I cannot quite wrap my head around. Maybe it’s because I’m on the outside looking in, so I cannot perceive the cultural problems that they see.

“We plan on doing things differently. This will require a culture shift.

This is more than an IT project; we have to fundamentally change how the public service operates.” - @AlexBenay #NextGen #IndustryDay pic.twitter.com/lfDGGx5Pzx

— Amanda Bernardo (@AmandaBernardo) September 19, 2018

To me, the message that “we have to fundamentally change how the public service operates” seems like a recapitulation, at the organizational and leadership level, of the worst mistake of old school IT: the old system is no good, we need a brand new system.

Back in the early aughts, when I was a fluffy young IT boffin, and discovered open source software, I was pretty sure we were on the cusp of a radical and immediate transformation: the open source model was so self-evidently better that a culture change would necessarily flow through IT.

Here we are, coming up on 20 years later and… things are still slowly getting better?

There was no radical change, the overall culture of IT slowly changed, and the things that I once had to argue loudly for – agile development (we called it RAD), GitHub (we called it open development), open source (OK, we called it that too) – are now accepted as somewhat normal practices.

Government culture will change because the rest of the culture is also changing. Sure, government is heirarchical. It used to be a whole lot more heirarchical as were the post-WW2 corporate and military cultures it co-existed with.

Small organizations are getting flat and more agile. Larger ones are following along at their own pace. As the largest of the organizations, government sometimes runs slowest. The challenge is to speed up the pace of change without breaking the beast.

I don’t see how a message like “we have to fundamentally change how the public service operates” isn’t going to give rise to a lot of push-back from people who aren’t necessarily opposed in principal to digital, but who are surely opposed in practice to being talked down to.

At the same time, for people inclined to support digital, it implies a manichean, “year zero” approach to change that is fundamentally unrealistic. With lots of institutional support and political backing and always the best of intentions among civil servants, a more digital government will arrive in 10 years instead of 20.

Categories: OSGeo Planet

gvSIG Team: Workshop about environmental modelling using gvSIG and the HortonMachine at 14th International gvSIG Conference

OSGeo Planet - Thu, 2018-09-20 11:12

During the 14th International gvSIG conference, held the next 24-26th October in Valencia, a free workshop about environmental modelling using gvSIG and the HortonMachine will be given.

The HortonMachine library is an open geospatial library integrated in gvSIG containing tools for the management of environmental data and hydro-geomorphological analyses. The algorithms contained in the library are the result of more than 10 years of research, development and real application by different researchers and professionals working in the field of natural hazards.

The tools aim to the evaluation of different environmental variables (rainfall, discharge, biomass, hillslopes stabilities, …) mainly starting from a digital elevation model (DEM). These tools are classified into 7 different sections, from data management (raster, vector and point cloud), data collection in the field, and environmental modelling in particular related to hillslope stability, floods, debris flow and transportation of wood during flooding events.

These tools can be used for flood and shallow landslides hazard and risks zones as required by the national and international directives, in particular the EU flood directive.

The workshop is a first introduction on the use of some of the tools dedicated to geomorphologic analysis and flood mapping.

During the workshop the participants will be guided through the use of gvSIG on a test case covering part of the activities to be done to define the maximum discharge in a river for different return times following a new available tutorial.

If you are interested in some environmental modelling please join us at this workshop! All the information about registration and requirements (cartography, installation…) will be available at this post soon.

Categories: OSGeo Planet

Fernando Quadro: Melhorias no editor de estilos do GeoServer 2.14

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

O editor de estilo GeoServer agora inclui um modo de edição lado a lado em tela cheia, para facilitar a visualização de seus estilos ao editá-los.

A barra de ferramentas também possui duas novas adições, um seletor de cores que ajuda a encontrar a cor certa e a transformá-la em uma codificação Hexadecimanl e um seletor de arquivos que permite selecionar um elemento gráfico externo e criar o elemento ExternalGraphic. Veja:

Fonte: GeoServer Blog

Categories: OSGeo Planet

gvSIG Team: The program of the 14th International gvSIG Conference is now available

OSGeo Planet - Wed, 2018-09-19 12:58

The program of the 14th International gvSIG Conference is now available. It includes a a great number of presentations in different thematic sessions and 7 free workshops about gvSIG Suite.

Conference will take place from October 24th to 26th in Valencia, Spain, and registrations have to be done from the form available at the event website.

Registration for workshops will be independent. We will inform about it and all the workshops information at gvSIG Blog soon.

Categories: OSGeo Planet

gvSIG Team: Programa de las 14as Jornadas Internacionales ya disponible

OSGeo Planet - Wed, 2018-09-19 12:43

Ya está disponible el programa de las 14as Jornadas Internacionales gvSIG, con una gran cantidad de ponencias divididas por sesiones temáticas, y siete talleres gratuitos sobre la Suite gvSIG.

Las jornadas tendrán lugar del 24 al 26 de octubre en Valencia, España, y para poder asistir es necesario inscribirse previamente desde el formulario habilitado en la web de las jornadas. Se recomienda no esperar al último momento, ya que las salas cuentan con un aforo limitado.

Para los talleres se deberá realizar una inscripción independiente. En breve se informará sobre la apertura de inscripciones a los talleres. Toda la información relativa a los mismos la podréis encontrar en el blog de gvSIG.

Categories: OSGeo Planet

Fernando Quadro: Álgebra de Mapas no GeoServer

OSGeo Planet - Wed, 2018-09-19 10:31

O GeoServer 2.14 adiciona suporte a um pacote de álgebra de mapas eficiente conhecido como Jiffle. O Jiffle tem sido o trabalho de um ex-colaborador do GeoTools, Michael Bedwards, que foi recuperado, atualizado para suportar o Java 8 e integrado no jai-ext.

A partir daí, o suporte foi adicionado ao módulo gt-process-raster do GeoTools e, como resultado, ao serviço WPS do GeoServer, para ser usado diretamente ou como uma transformação de renderização.

A seguir as chamadas do Jiffle em um estilo SLD para executar um cálculo de NDVI sobre os dados do Sentinel-2:

<?xml version="1.0" encoding="UTF-8"?> <StyledLayerDescriptor 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" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd" version="1.0.0">   <NamedLayer>     <Name>Sentinel2 NDVI</Name>     <UserStyle>       <Title>NDVI</Title>       <FeatureTypeStyle>         <Transformation>           <ogc:Function name="ras:Jiffle">             <ogc:Function name="parameter">               <ogc:Literal>coverage</ogc:Literal>             </ogc:Function>             <ogc:Function name="parameter">               <ogc:Literal>script</ogc:Literal>               <ogc:Literal>                 nir = src[7];                 vir = src[3];                 dest = (nir - vir) / (nir + vir);               </ogc:Literal>             </ogc:Function>           </ogc:Function>         </Transformation>         <Rule>           <RasterSymbolizer>             <Opacity>1.0</Opacity>             <ColorMap>               <ColorMapEntry color="#000000" quantity="-1"/>               <ColorMapEntry color="#0000ff" quantity="-0.75"/>               <ColorMapEntry color="#ff00ff" quantity="-0.25"/>               <ColorMapEntry color="#ff0000" quantity="0"/>               <ColorMapEntry color="#ffff00" quantity="0.5"/>               <ColorMapEntry color="#00ff00" quantity="1"/>             </ColorMap>           </RasterSymbolizer>         </Rule>       </FeatureTypeStyle>     </UserStyle>   </NamedLayer> </StyledLayerDescriptor>

O desempenho é bom o suficiente para exibição interativa, e o resultado é o seguinte:

Fonte: GeoServer Blog

Categories: OSGeo Planet

GeoTools Team: GeoTools 20 Release Candidate Available

OSGeo Planet - Wed, 2018-09-19 03:40
The GeoTools team is pleased to announce the release of GeoTools 20-RC: geotools-20-RC-bin.zip geotools-20-RC-doc.zip geotools-20-RC-userguide.zip geotools-20-RC-project.zip This release candidate is also available from our Maven repository, and is made in conjunction with GeoServer 2.14-RC. This release includes a various major changes. Please Test this Release Candidate A release
Categories: OSGeo Planet
Syndicate content