Welcome to Planet OSGeo

February 27, 2015

Gis-Lab

Релиз GRASS 7.0.0

На днях вышел долгожданный релиз новой стабильной версии GRASS под гордым номером 7.0.0!

За 6 лет напряжённой разработки было сделано около 100500 10500 исправлений и улучшений по сравнению с версией 6.4.0.

Среди основных особенностей релиза:

  • планируется длительная поддержка релиза (LTS);
  • графический интерфейс wxPython значительно доработан и дополнен многими новыми полезными функциями (например, т.н. «шторка»);
  • добавлено много нового функционала в ядро системы, в том числе, новый Python-интерфейс к С-библиотекам;
  • появилось множество новых модулей разного назначения, в том числе, не имеющий аналогов среди открытых ГИС фреймворк для работы с пространственно-временными наборами данных;
  • значительно ускорена работа модулей для работы с векторными данными; повсеместно реализована поддержка т.н. «больших данных»;
  • по умолчанию в качестве драйвера базы данных теперь SQLite (вместо DBF);
  • проделана большая работа по унификации и стандартизации названий параметров в модулях, а также по обновлению документации;
  • и много другого, нового и интересного :)

За подробностями, ссылками и документацией добро пожаловать на официальный сайт GRASS!

by Александр Мурый at February 27, 2015 11:54 PM

NaturalGIS Blog

New geoprocessing tools in the QGIS Processing toolbox

QGIS 2.8 was not officially announced yet and, as always happens in the QGIS project, new features are already being added to QGIS master, aka next future release, in this case 2.10.

At NaturalGIS we do our share of effort, especially regarding improvements for the QGIS “Processing” toolbox, and recently started to add new geoprocessing tools for vectors. At the time we are writing the tools we added are:

  • Buffer
  • Single sided buffer (or offset lines)
  • Clip by extent
  • Clip by polygon
  • Create points along lines
  • Dissolve
ogr2ogr geoprocessing tools for QGIS Processing toolbox New QGIS geoprocessing tools

Some are completely new, like the Single sided buffer (or offset lines), Clip (vector) by extent (a similar tool is already available in QGIS but only to clip rasters layers) and Create points along lines, others are not (Buffer, Clip by polygon and Dissolve) as there are already plenty of alternatives in QGIS. The point here is that this “new” tools are quite faster than the already existing QGIS counterparts, or they offer new options.

For example the “Dissolve” tool is on average several times faster (up to 7 times, in our simple tests) than the QGIS counterpart, moreover the tool has the ability to compute some statistics on numerical attributes. See the image below:

ogr2ogr geoprocessing Dissolve tool Dissolve with stats

Under the hood the work is done by that great software that is ogr2ogr. In this case is used to run spatial SQL queries, using as engine SQLite/Spatialite

More of this ogr2ogr/sql based tools will be added in the next future, especially when a few missing features will be added to the QGIS Processing toolbox, meanwhile you can help us testing the above ones.

Under MS Windows you can install the development version of QGIS using the OSGeo4W installer. Under Ubuntu GNU/Linux you can use the nightly builds repository.

February 27, 2015 07:25 PM

NaturalGIS Blog

A new QGIS tool (based on ogr2ogr) to import vectors in PostGIS

In QGIS there are many tools that can be used to import vectors inside a PostGIS database, each one has pros and cons:

  • SPIT core plugin: available since early QGIS releases but now unmaintained tool and therefore candidate to be removed from future QGIS releases. It has the advantage to allow import several vectors in one run, but on the other hand it does not have an option to launder table/columns names and is overall quite slow especially for fair large vectors.
  • DB Manager: it has several pros, like supporting drag & drop import and a few important other options, but misses to allow import several vectors and is overall slow especially for fair large vectors.
  • QGIS browser: it allows import vectors using drag & drop but as the above tools missed to allow multiple vectors import. Overall slow especially for fair large vectors.
  • Processing toolbox ”Import into PostGIS”: it can import several vectors at once because, as any other tool in the QGIS Processing toolbox, it can run in batch mode. Overall slow especially for fair large vectors.

There are of course also command line alternatives, in particular shp2pgsql (together with psql) and ogr2ogr. Each one is rich of options/switches and they can be scripted to import several vectors in one go. While shp2pgsql is installed were PostGIS is installed, usually it is not on common users desktop machines. On the other hand ogr2ogr is installed and available on any machine where QGIS is installed because is part of the GDAL/OGR libary, that is basic dependency of any QGIS installation.

We compared how importing vectors in PostGIS performed using ogr2ogr compared to the tools available in QGIS, and then also compared to shp2pgsql. In short, the results are the following:

  • even without recurring to any particular switch/trick, ogr2ogr is on average much more faster than any available tools available in QGIS.
  • ogr2ogr and shp2pgsql performed in a similar way.

To compare ogr2ogr and shp2pgsql we used as input dataset a 4 million features (polygons) shapefile (1.3GB of space occupied) and also a small subset of it (4000 features, 10MB) using PostGIS installed on the local machine (Ubuntu GNU/Linux 14.04).

Without using any particular switch to make imports faster (like “-D” for shp2pgsql or “-config PG_USE_COPY YES” for ogr2ogr) ogr2ogr is much faster than shp2pgsql/psql with the small dataset (2.5 seconds against 35 seconds).

With the large dataset things gets the other way, with shp2pgsql/psql ending the task in 17 minutes against 19.5 minutes with ogr2ogr.

Adding the options “-D” to shp2pgsql and “-config PG_USE_COPY YES” to ogr2ogr is possible to get a dramatic improvement of the performace of both tools: ogr2ogr takes 0.8 seconds to process the small dataset and 2.21 minutes the process the big dataset, while shp2pgsql/psql takes respectively 24 seconds and 1.56 minutes.

ogr2ogr seemed a good choice to create a new tool for QGIS to allow import vectors in a fast way. We implemented such tool as part of the QGIS Processing toolbox and therefore is available the brand new QGIS 2.8 release.

QGIS Processing tools to import vector layers in PostGIS The new tool(s) in the QGIS Processing toolbox

The tool also exposes options that are not usually available in any other QGIS tool. Aming the others: Vector dimensions, Append, Append and add new fields, Skip failures, Simplification, Densification, Import selected features by extent, Import clipped features by extent and a few others.

Tools GUI Tool GUI

February 27, 2015 03:39 PM

Tyler Mitchell

VIDEO: Kibana 3 Dashboard – 3 Use Cases Demonstrated

Kibana dashboards, from the Elasticsearch project, can help you visualise activity and incidents in log files. Here I show 3 different types of use cases for dashboards and how each can be used to answer different questions depending on the person.  Video and details follow.

Text Search Dashboard

The first example is the simplest UI I could imagine: a query/search box, a histogram, and a table.  In this instance any user, at any level of curiosity, can find textual data in the logs using a keyword match.

Kibana 3 Dashboard: Text Search

Then they can also see the relative number of records that occur at given times within the time window of all the data available.  These are aggregate counts of all records that have some match to the query keyword or algebra.

Likewise, the table reflects the subset of data provided by the records, with the ability to only show fields of interest.

Process Details

A slightly more advanced use is to focus on a particular process (i.e. application) running on a machine that’s being logged.  Here we can then take a particular metric, i.e. CPU usage, and graph it instead of just a simple histogram.

Kibana 3 Dashboard: Process Details

A typical user may be in charge of a particular set of services in a system.  Here they can see how they perform and yet still dig into the details as desired.

I also do some cool “markers” to subtly show when events coincide with other process metrics.

All Events

The data example shown here has process, performance and event logging information.  I combine multiple queries and having them drive different parts of the dashboard – a pie chart, summary table, histogram, sparkline and other charts based on numeric data.

Kibana 3 Dashboard: All Events

These can then all be filtered based on time windows that are interactively selected.  This is really the typical picture of a dashboard – giving more densely packed information about a variety of metrics, ideal for system managers to get a handle on things.

Streaming Pipeline

The data are generated by Windows servers using a custom C# application that pushes data in a Kafka topic in a Hadoop cluster running in EC2. The data stream is then read from the topic using Actian DataFlow platform and pushed into Elasticsearch for Kibana to use at the end of the pipeline.  There are other reasons I have this kind of pipeline – namely that DataFlow can simultaneously also feed other outgoing part of the pipeline – RDBMS, graph, etc.   More on that in a future video/post.

Next Steps

  • My next plans are to show you Kibana version 4 in action, replicating some of what I’ve shown here.
  • If you haven’t seen it already, see this link and my video with some tips and tricks for using Kibana 3.
  • Tell me more about your interests in dashboards and I’ll consider focusing on them too.

The post VIDEO: Kibana 3 Dashboard – 3 Use Cases Demonstrated appeared first on spatialguru.com.

by Tyler Mitchell at February 27, 2015 04:23 AM

BostonGIS

PostGIS workshops at FOSS4G NA 2015 San Francisco

There will be two PostGIS workshops at FOSS4G NA 2015 on March 9th. Signup if you haven't already.

  • PostGIS Up and Running 9AM - 12 PM. This is an introductory workshop where we'll cover the basics of configuring PostGIS and using the PostGIS geometry and geography types. We also plan to demonstrate some new features coming in PostGIS 2.2, particularly of the 3D kind. If time permitting, we'll do a quick coverage of pgRouting as well.

    Someone asked on IRC if we will be handing out certificates of completion to folks who complete the workshop. Some people need this because they are allowed to attend workshops on company time, but not conferences. The thought hadn't crossed our mind, but we like the idea a lot. So yes you can have a certificate if you stay thru the whole session complete with Regina and Leo's seal of approval. We might even have some door prizes.

  • Advanced spatial analysis with PostGIS. Pierre Racine will be leading this workshop. Expect to be blown away by images of rasters dancing on legs of geometries. He'll also have some other cool advanced spatial analysis stuff beyond raster. Expect a lot of geometry processing tricks in this one.

Sadly I think our PostGIS In Action 2ed is going to be released a little after conference time and probably won't be ready until mid March, so probably just a wee bit too late for FOSS4G NA 2015, but just in time for PGCon.US New York 2015 March 25th-26th . Final book proofing is like getting our teeth pulled. I really hope it's worth the wait. We'll have coupons but no book. We will have some copies of our PostgreSQL: Up and Running 2nd Edition available though. If you've already bought one of our books and want it autographed, bring it along on your trip.

by Regina Obe (nospam@example.com) at February 27, 2015 12:04 AM

February 26, 2015

SourcePole

QGIS Instant Print Plugin

As a side product of a customer project, we’re publishing a QGIS plugin for printing maps to a file with just two mouse clicks.

To use the instant print tool, a composer needs to be created first. The only requirement is that it contains exactly one map item.

The instant print tool can then be activated from the plugin toolbar by clicking on the plugin icon icon.

In the dialog window which appears, one can pick the composer to use as page layout. A selection rectangle is displayed in the map canvas, sized according to the size of the map item in the composer and the scale chosen in the instant print dialog. The selection rectangle can be freely dragged around to choose the region one wishes to print. When dragging the selection rectangle, the previous rectangle is shown shaded and can be used as a snap reference when setting the new region. While the instant print tool is active, the canvas can be panned with the middle mouse button.

screenshot

To instant print tool can be installed with the QGIS plugin manager and the sources are available on Github.

February 26, 2015 09:52 PM

Tyler Mitchell

Google wants “mobile-friendly” – fix your WordPress site

TheNextWeb reports: “Google will begin ranking mobile-friendly sites higher starting April 21“.  It’s always nice having advance warning, so use it wisely – here’s how to tweak WordPress to increase your mobile-friendliness.

Google Mobile-Friendly Check

I use a self hosted WordPress site and wanted to make sure it was ready for action.  I already thought it was, because I’ve accessed in on a mobile device very often and it worked okay.

I even went onto the Google Web Admin tools and the mobile usability check said things were fine.

Google admin tool says mobile check is okay

However, all was not golden when I ran the Google mobile-friendly checker.  (Obviously two different apps here, hopefully those will merge.)

Google mobile check failure

Try it here, now!  The complaints about were that some content is wider than screens and that links were too close together.  Fair enough.

WordPress Mobile-Friendly Activation

If you’re not already using WordPress’s Jetpack features, you’re really missing out.  I use it mostly for monitoring stats but there are several other features that make it very useful, including one called Mobile Theme.

  1. From the admin sidebar select Jetpack (install it first if not already enabled).  It will show you some suggested plugins to enable, plus show you a search bar to find others.
  2. Enter “mobile” and click on the Mobile Theme item.
  3. Activate it (lower-right corner button).
  4. And you’re done!

Going back to Google’s checker it shows a different preview now and also says things are fine.  Looking at the site after making these changes, it’s obviously better.

Google mobile check fixed success

However, I still have one plugin (Crayon markup) that helps display code samples that seems to force some posts to wider than the screen.  I assume the plugin creators will fix that up, but it’s not too bad at this point.  Unless Google complains, it doesn’t matter anyway!

The post Google wants “mobile-friendly” – fix your WordPress site appeared first on spatialguru.com.

by Tyler Mitchell at February 26, 2015 09:46 PM

Cameron Shorter

OSGeo-Live 8.5 released

Version 8.5 of the OSGeo-Live GIS software collection has been released, featuring over 50 open source, standards compliant geospatial applications.

Release Highlights

Added Cesium
Cesium is a JavaScript library for creating 3D globes and 2D maps in a web browser without any plugins. It uses WebGL for hardware-accelerated graphics, and is cross-platform, cross-browser, and tuned for dynamic-data visualization.

Added IPython
IPython notebooks contain a list of input/output cells which can contain code, text, mathematics, plots, maps and other media. They are a bit like a spreadsheet in that each cell can contain code or a formula, and a bit like a web page in that authors can create structured text along with easily embedding rich and sophisticated media.

Updated to GRASS 7
GRASS 7 is a major upgrade, in the making since 2008, and offers new modules, tools, analysis capabilities, optimisations, user interface improvements, new Python interface, and SQLite database driver as default.

Updated to OpenLayers 3
OpenLayers 3 is a fundamental redesign of the OpenLayers web mapping library to use modern design patterns. Applications 25 geospatial programs have been updated to newer versions.

About OSGeo-Live 

OSGeo-Live is a self-contained bootable DVD, USB flash drive and Virtual Machine, pre-installed with robust open source geospatial software, which can be trialled without installing anything. It includes:
  • Over 50 quality geospatial Open Source applications installed and pre-configured
  • Free world maps and sample datasets
  • Project Overview and step-by-step Quickstart for each application
  • Lightning presentation of all applications, along with speaker's script
  • Overviews of key OGC standards
  • Translations to multiple languages
Homepage: http://live.osgeo.org
Download details: http://live.osgeo.org/en/download.html

Credits

Over 180 people have directly helped with OSGeo-Live packaging, documenting and translating, and thousands have been involved in building the packaged software.
Developers, packagers, documenters and translators include:
Activity Workshop, Agustín Dí­ez, Aikaterini Kapsampeli, Alan Beccati, Alan Boudreault, Alessandro Furieri, Alexander Bruy, Alexander Kleshnin, Alexander Muriy, Alexandre Dube, Alexey Ardyakov, Alex Mandel, Amy Gao, Andrea Antonello, Andrea Yanza, Andrey Syrokomskiy, Andry Rustanto, Angelos Tzotsos, Anna Muñoz, Antonio Falciano, Antonio Santiago, Anton Novichikhin, Anton Patrushev, Argyros Argyridis, Ariel Núñez, Assumpció Termens, Astrid Emde, Balasubramaniam Natarajan, Barry Rowlingson, Benjamin Pross, Brian Hamlin, Bruno Binet, Bu Kun, Cameron Shorter, Christophe Tufféry, Christos Iossifidis, Cristhian Pin, Damian Wojsław, Dane Springmeyer, Daniel Kastl, Danilo Bretschneider, Daria Svidzinska, David Mateos, Denis Rykov, Diego González, Diego Migliavacca, Dimitar Misev, Dmitry Baryshnikov, Dominik Helle, Edgar Soldin, Eike Hinderk Jürrens, Elena Mezzini, Eric Lemoine, Erika Pillu, Estela Llorente, Etienne Delay, Etienne Dube, Evgeny Nikulin, Fabian Schindler, Fran Boon, François Prunayre, Frank Gasdorf, Frank Warmerdam, Friedjoff Trautwein, Gavin Treadgold, Giuseppe Calamita, Grald Fenoy, Grigory Rozhentsov, Guy Griffiths, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Hirofumi Hayashi, Howard Butler, Hyeyeong Choe, Ian Edwards, Ian Turton, Ilya Filippov, Jackie Ng, Jan Drewnak, Jane Lewis, Javier Rodrigo, Javier Sánchez, Jesús Gómez, Jim Klassen, Jing Wang, Jinsongdi Yu, Jody Garnett, Johan Van de Wauw, John Bryant, Jorge Arévalo, Jorge Sanz, José Antonio Canalejo, José Vicente Higón, Judit Mays, Klokan Petr Pridal, Ko Nagase, Kristof Lange, kuzkok, Lance McKee, Larry Shaffer, Lars Lingner, Luca Delucchi, Lucía Sanjaime, Mage Whopper, Manuel Grizonnet, Marc-André Barbeau, Marco Curreli, Marco Puppin, Marc Torres, Margherita Di Leo, Maria Vakalopoulou, Mario Andino, Mark Leslie, Massimo Di Stefano, Matteo De Stefano, Matthias Streulens, Mauricio Miranda, Mauricio Pazos, Maxim Dubinin, Michaël Michaud, Michael Owonibi, Micha Silver, Mike Adair, Milena Nowotarska, M Iqnaul Haq Siregar, Nacho Varela, Nadiia Gorash, Nathaniel V. Kelso, Ned Horning, Nobusuke Iwasaki, Oliver Tonnhofer, Òscar Fonts, Otto Dassau, Pasquale Di Donato, Patric Hafner, Paul Meems, Pavel, Pedro-Juan Ferrer, Pirmin Kalberer, Raf Roset, Regina Obe, Ricardo Pinho, Roald de Wit, Roberta Fagandini, Roberto Antolin, Roberto Antolí­n, Roger Veciana, Ruth Schoenbuchner, Samuel Mesa, Scott Penrose, Sergey Grachev, Sergey Popov, Sergio Baños, Simon Cropper, Simon Pigot, Stefan A. Tzeggai, Stefan Hansen, Stefan Steiniger, Stephan Meissl, Steve Lime, Takayuki Nuimura, Thierry Badard, Thomas Baschetti, Thomas Gratier, Tom Kralidis, Toshikazu Seto, Trevor Wekel, Valenty González, Vera, Xianfeng Song, Yoichi Kayama, Zhengfan Lin, Zoltan Siki

Sponsoring organisations

by Cameron Shorter (noreply@blogger.com) at February 26, 2015 08:21 PM

OSGeo News

New stable release: GRASS GIS 7.0.0

by jsanz at February 26, 2015 03:27 PM

OSGeo News

FOSS4G 2015 Call for Presentations/Papers/Workshops

by jsanz at February 26, 2015 03:19 PM

gvSIG Team

Publishing extension: manual edition of specifics attributes

Let´s see another feature of the new publishing extension.

Sometimes, it can be interesting to define the parameters more precisely and adjust the specifications to the ones that MapServer offers. For that reason, some mechanisms have been created to be able to complete these characteristics through some forms.

There are two access points. The first one is through the window View properties, which will define the characteristics of the Mapfile service (MapFile section).

11_gvSIG_Publish…and the second access point is with right click>’Properties’ in the layer(to define the MapFile attributes of each layer).

12_gvSIG_PublishThere are similar ways to define the services of TinyOWS and MapProxy.

In the next post, we will see how the Publishing extension allows the upload of the project previously generated in local to its final destiny in the server.


Filed under: english, gvSIG Desktop, gvSIG development Tagged: gvSIG 2.2, mapProxy, mapserver, publishing, TinyOWS

by mjlobato76 at February 26, 2015 12:47 PM

February 25, 2015

Markus Neteler

Compiling OTB Orfeo ToolBox software on Centos/Scientific Linux

The Orfeo ToolBox (OTB), an open-source C++ library for remote sensing images processing, is offering a wealth of algorithms to perform Image manipulation, Data pre-processing, Features extraction, Image Segmentation and Classification, Change detection, Hyperspectral processing, and SAR processing.

Since there is no (fresh) RPM package available for Centos or Scientific Linux, here some quick hints (no full tutorial, though) how to get OTB easily locally compiled. We are following the Installation Chapter.

Importantly, you need to have some libraries installed including GDAL. Be sure that it has been compiled with the  –with-rename-internal-libtiff-symbols and  –with-rename-internal-libgeotiff-symbols flags to avoid namespace collision a.k.a segmentation fault of OTB as per “2.2.4 Building your own qualified Gdal“. We’ll configure and build with the GDAL-internal Tiff and Geotiff libraries that supports BigTiff files

# configure GDAL
./configure \
 --without-libtool \
 --with-geotiff=internal --with-libtiff=internal \
 --with-rename-internal-libtiff-symbols=yes \
 --with-rename-internal-libgeotiff-symbols=yes \
...
make
make install

The compilation of the OTB source code requires “cmake” and some other requirements which you can install via “yum install …”. Be sure to have the following structure for compiling OTB, i.e. store the source code in a subdirectory. The binaries will then be compiled in a “build” directory parallel to the OTB-SRC directory:

OTB-4.4.0/
|-- build/
`-- OTB-SRC/
    |-- Applications/
    |-- CMake/
    |-- CMakeFiles/
    |-- Code/
    |-- Copyright/
    |-- Examples/
    |-- Testing/
    `-- Utilities/

Now it is time to configure everything for OTB. Since I didn’t want to bother with “ccmake”, below the magic lines to compile and install OTB into its own subdirectory within /usr/local/. We’ll use as many internal libraries as possible according to the table in the installation guide. The best way is to save the following lines as a text script “cmake_otb.sh” for easier (re-)use, then run it:

#!/bin/sh

OTBVER=4.4.0
(
mkdir -p build
cd build

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/otb-$OTBVER \
      -DOTB_USE_EXTERNAL_ITK=OFF -DOTB_USE_EXTERNAL_OSSIM=OFF \
      -DOTB_USE_EXTERNAL_EXPAT=OFF -DOTB_USE_EXTERNAL_BOOST=OFF \
      -DOTB_USE_EXTERNAL_TINYXML=OFF -DOTB_USE_EXTERNAL_LIBKML=OFF \
      -DOTB_USE_EXTERNAL_MUPARSER=OFF \
      ../OTB-SRC/

make -j4
# note: we assume to have write permission in /usr/local/otb-$OTBVER
make install
)

That’s it!

In order to use the freshly compiled OTB, be sure to add the new directories for the binaries and the libraries to your PATH and LD_LIBRARY_PATH variables, e.g. in $HOME/.bashrc:

export PATH=$PATH:/usr/local/bin:/usr/local/otb-4.4.0/bin
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64/:/usr/local/otb-4.4.0/lib/otb/

Enjoy OTB! And thanks to the OTB developers for making it available.

The post Compiling OTB Orfeo ToolBox software on Centos/Scientific Linux appeared first on GFOSS Blog | GRASS GIS Courses.

by neteler at February 25, 2015 09:18 PM

gvSIG Team

Creare etichette in funzione della scala (nuova estensione)

Abbiamo già visto come creare legende in funzione della scala con la nuova estensione “Legenda Complessa“. Usando la stessa estensione installata nel nostro gvSIG possiamo anche creare etichette in funzione della scala della nostra vista.

Vediamo come funziona

Come sempre, il primo passo è quello di entrare nelle opzioni di etichettatura: apriamo la finestra delle proprietà del layer su cui vogliamo applicare l’etichetta (tasto destro sul nome del layer nella Tabella dei Contenuti della Vista) e selezioniamo la scheda ‘etichette‘.

proprietà

La possibilità di definire una etichetta modificabile in funzione della scala si trova all’interno della scheda “etichette definite dall’utente”.

etichette_utente

Per quanto riguarda il pannello, non è cambiato praticamente nulla nella struttura, in modo che possa essere gestita come di consueto; semplicemente considerate che devono essere selezionate la Classe “Etichetta classi di elementi diversamente“, e la nuova opzione “Multiple label by scale” nel menu a discesa, come mostrato nell’immagine seguente.

multilabel_scale

Dopo aver selezionato questa opzione, è possibile aggiungere una voce che caratterizza l’etichetta da visualizzare, cliccando direttamente sul campo “Espressione di etichetta” che è stato aggiunto sul tavolo.

rango_etichetta

La finestra è molto simile a quella disponibile nelle versioni precedenti tranne che per la nuova scheda in alto a destra che visualizza un nuovo form in cui si potrà definire l’intervallo di scala in cui visualizzare l’etichetta.


Filed under: gvSIG Desktop, Italian Tagged: escalas, etiquetado, etiquetas, gvSIG 2.2

by Giuliano Ramat at February 25, 2015 01:12 PM

gvSIG Team

Nuova estensione: Generare legende in funzione della scala

Continuiamo ad avvicinarci a gvSIG 2.2 con un nuovo strumento che permette di creare legende in funzione della scala (anche etichette come vedremo in un altro post).

Il plugin si chiama Estensione Legende Complesse e si può installare, come al solito, tramite il Gestore delle estensioni, con installazione dall’URL del testing repository (repository Testing gvSIG – http://downloads.gvsig.org/download/gvSIG-desktop-testing/).

Vediamo come funziona …

Facciamo la solita procedura per modificare la simbologia del layer: apriamo la finestra “Proprietà” del layer su cui si vuole lavorare (tasto destro del mouse sul nome del del layer nella tabella dei contenuti nella vista) e selezioniamo la scheda ‘Simbologia’.

23_gvSIG_escalasTra le varie opzioni disponibili per le legende si noterà che ne è stata aggiunta una nuova: “simbolo complesso“. Selezioniamola.

24_gvSIG_escalasSi aprirà un form in cui specificare gli intervalli di scala su cui lavorare e definire il tipo di legenda da applicare all’interno di ciascuno.

E’ possibile aggiungere nuovi intervalli attraverso il pulsante ‘aggiungi (rappresentato con una croce verde) ed eliminare precedenti intervalli tramite il tasto ‘elimina‘ (croce rossa).

rango

In funzione dei dati inseriti si completerà la combinazione definendo nel pannello inferiore i parametri caratteristici della legenda scelta.

26_gvSIG_escalas

Conclusa questa azione, si può ripetere l’operazione per tante volte quanti sono gli intervalli di scala che vogliamo definire per il layer.

27_gvSIG_escalas

Premiamo applica e verifichiamo il risultato. Se tutto è andato bene, il layer cambierà dinamicamente legenda in funzione della scala in cui è visualizzato.

Un altro caratteristica interessante è che negli intervalli di scala non inseriti, non viene visualizzata alcuna informazione in legenda, cioè siamo in grado di rendere il livello “invisibile” all’interno degli intervalli non definiti.

Nel prossimo post vedremo anche come generare etichette in funzione della scala.


Filed under: gvSIG Desktop, Italian, testing Tagged: escala, gvSIG 2.2, leyendas, simbología

by Giuliano Ramat at February 25, 2015 12:39 PM

gvSIG Team

How to manage the preferences of a plugin in gvSIG 2.1

English translation of the article by Joaquin del Cerro.

Hi,

A developer has asked in the gvSIG´s development list how he could add a new entry to the “preferences dialog of gvSIG” to manage the preferences of a plugin.

I am going to quickly explain how you could do this, along with where and how these preferences would be stored.

I will begin with where the plugin´s preferences should be stored. If gvSIG 2.1.0 is installed we can have a quick look at the gvSIG folder in “HOME”, where there will be a “plugins” folder, which contains one folder for each plugin. There won´t be one for each GVSIG plugin ,however there will be one folder for each plugin that needs to store preferences or information that must be updated during the running of gvSIG. If we Look inside the folder:

gvSIG/plugins/org.gvsig.coreplugin.app.mainplugin/

of “HOME”.

There we find the “plugin-persistence.dat” file. Ahí es donde cada plugin almacena sus datos relacionados con preferencias. This is the file where each plugin stores its data related to preferences. The format of this file is similar to the project files of gvSIG (.gvsproj), but it stores a different kind of information, and this one is particular for each plugin.

If we erase these files we will lose our preferences and the device will be started with the default values from the code. This file is matched with another that is located in the plugin folder.If we look in the folder:

gvSIG/extensiones/org.gvsig.coreplugin.app.mainplugin/

…of our installation of gvSIG, we will find a file “plugin-persistence.def” with the file´s definition “plugin-persistence.dat” stored in “HOME/gvSIG…”. For example, with “org.gvsig.coreplugin.app.mainplugin”, we will have something like:

<?xml version="1.0"?>
<definitions>
  <version>1.0.0</version>
  <classes>
    <class name="org.gvsig.coreplugin.app.mainplugin">
      <description>Persistence for the core plugin</description>
      <fields>

        <field name="showNotificationsInConsole" type="Boolean" defaultValue="false" mandatory="false">
          <description></description>
        </field>
        <field name="showNotificationsInStatusbar" type="Boolean" defaultValue="true" mandatory="false">
          <description></description>
        </field>

      </fields>
    </class>
  </classes>
</definitions>

Here we have defined that in the preferences of the plugin there are two properties of type “boolean“, “showNotificationsInConsole” and “showNotificationsInStatusbar” and their default values are “false” and “true” respectively.

The first step to manage the preferences of our plugin will be to create this file with the definition of the attributes that we want to have in our preferences. For values “simples“, String, Integer, Double, Boolean… the definition is very simple, but we can store more complex data structures like “List“, “Map” o “Set“, and if we need we can define our own estructure. For now, I think the “simple” type taking a look at the files “plugin-persistence.def” is enough,which you can find in the installation of gvSIG. If you have any questions ask for the development list. If I have time and people think it would be interesting, I will prepare an article commenting in detail on all the possibilities we have to define our preference data in this file.

One important thing to note… it is very important that we put “<class name=” and you put the exact same name of the plugin if not, it won´t load with it.

Ok, I assume that you have created your file “plugin-persistence.def”, and it is ready for dropping in the installation folder of your plugin. Now what can I do with it?

It is very simple. We are going to see some code:

PluginsManager pluginsManager = PluginsLocator.getManager();
PluginServices plugin = pluginsManager.getPlugin(MyClaseExtension.class);
DynObject pluginProperties = plugin.getPluginProperties();

With these three lines, we would force the loading of the file, if it existed “plugin-persistence.dat”. If it didn´t exist, an empty new “structure” would be created with the definition of “plugin-persistence.def” and ne would be left in “pluginProperties” for us to acces. We could do:

  Boolean showNotificationsInStatusbar = (Boolean) pluginProperties.getDynValue("showNotificationsInStatusbar")

To access the “showNotificationsInStatusbar” property of our preferences file. Or if we wanted we could do:

  pluginProperties.setDynValue("showNotificationsInStatusbar", Boolean.TRUE);

If we wanted to assign a value to the property of our preferences. If we change the preference settings, you can force to save them at that moment with:

  pluginProperties.savePluginProperties()

Or simply, when gvSIGis closed, these are saved automatically.

So it would be a very quick plan to can save or recover our plugin preferences. Now, what remains is to see how we can add a new entry to manage these preferences to the preferences dialogue of the application.

To create an entry in the preferences of gvSIG, we have to create a class that extends to the “AbstractPreferencePage” and fill in some methodology:

public class MyreferencesPage extends AbstractPreferencePage {

    private static final Logger logger = LoggerFactory.getLogger(MyPreferencesPage.class);

    public static final String ID = MyreferencesPage.class.getName();

    private MyPreferencesPanel preferences;
    private DynObject pluginProperties;
    private PluginServices plugin;

    public MyPreferencesPage() {
        initComponents();
    }

    private void initComponents() {
        I18nManager i18nManager = ToolsLocator.getI18nManager();
        PluginsManager pluginManager = PluginsLocator.getManager();
        this.plugin = pluginManager.getPlugin(this);
        this.pluginProperties = this.plugin.getPluginProperties();

        this.preferences = new MyPreferencesPanel();
        ...

        this.setLayout(new BorderLayout());
        this.add(this.preferences, BorderLayout.NORTH);
        initializeValues();
    }

    public void storeValues() throws StoreException {
    // We get the values from our pannel and
    // we save them in "pluginProperties"
    ...
        this.plugin.savePluginProperties();
    }

    public void setChangesApplied() {

    }

    public String getID() {
        return ID;
    }

    public String getTitle() {
        I18nManager i18nManager = ToolsLocator.getI18nManager();
        return i18nManager.getTranslation("Title of our page");

    }

    public JPanel getPanel() {
        return this;
    }

    public void initializeValues() {
    // We load our stored data in preferences,
    // "pluginProperties", at the controls of user interface

    ...
    Boolean showNotificationsInStatusbar = (Boolean) pluginProperties.getDynValue("showNotificationsInStatusbar");
    ...setSelected(showNotificationsInStatusbar.booleanValue());
    ...
    }

    public void initializeDefaults() {

    }

    public ImageIcon getIcon() {
        return IconThemeHelper.getImageIcon("my-preferences");
    }

    public boolean isValueChanged() {
      // If user has changed any value of our page
      // we will return "true" to recover them and
      // to be saved. In other case we will return "false"

      boolean changed = false;

      ...

      return changed;
    }

    public boolean isResizeable() {
      // The usual thing is to return true.
      // It indicates that the pannel will be at the dialog using a
      // layout that resizes it.
      return true;
    }

}

If we wanted that our preferences site to be “under” another one in the tree that appears on the preferences dialog, we would have to add to the construction of our class a call to “setParentID” indicating the ID of the page below the one we want to be our page. For example:

    public MyPreferencesPage() {
    setParentID(GeneralPage.id);
        initComponents();
    }

Our page would be located under “General” entry of the preferences dialog.

When we have created our class, we just have to register the gvSIG to be aware of it and it will be presented. To do this, in the “initialize” method of our extension, we can use something similar to these lines of code:

ExtensionPointManager extensionPoints =ToolsLocator.getExtensionPointManager();
ExtensionPoint ep = extensionPoints.add("AplicationPreferences", "");
ep.append("MyPage", "", new MyPreferencesPage());

Now, we just need to compile everything and see what happens.

I hope this has helped.

Bye¡¡


Filed under: development, english, gvSIG Desktop

by fjsolis at February 25, 2015 11:55 AM

Andrea Antonello

Geopaparazzi 4.2.0 is out: never out of data in the field

When I got that odd issue on the tracker about the GPS azimuth value not being properly handled in Geopaparazzi, I didn't think that this release would have any new feature. But well, once you sit down to fix things, you see things... and once you see thing, you want things :-)

First off, some bugs should be now fixed:
  • notes halo is ignored 
  • mapview doesn't render points and tracks when returning from standby
  • while downloading remote tiles sometimes the dashboard freezes 
  • azimuth should be only one: this is a big one, since now we the azimuth is always calculated properly and when a picture is taken it will be the right one.
  • geopap sometimes crashes when taking pictures
And that is already nice, particularly the azimuth one.

But here comes the Boom:

OSM data extraction from mapsforge tiles in offline mode


The mapsforge tiles are generated on the device from a particular vector format. This means that there are information available in the database. Problem is that, very very simply put, the information contained is extracted differently at different zoom levels, because in fact the library and the format have been done that way to allow rendering performance.

But still it is possible to extract almost everything we see, which is nice.

Let's see how this works. Assume you have a job to do, are out in the field and want view information overlayed on the ortofoto pictures from the local WMS service.

Well, the map file you get from mapsforge looks like the following:


Now go in the mapvieW menu and you will find a new entry: Import mapsforge data


The import view will appear:


From the view you can see that 2 types of data can be imported: points and ways.

Points

Since the points are often visible on a different zoomlevel then the current, also 3 zoomlevels below the current are investigated to extract data and double points are not considered. So if you start this at zoomlevel 16, you will also get 17, 18, 19. Since the same are at a different zoomlevel will have many more tiles, about 10000 tiles are read to import the data.

You can add a filter text to import only tags containing a given text or exclude all those containing the text.

Points are imported in the current projectdatabase and saved as forms notes containing all the values Openstreetmap has. As such they can also be edited.


Ways

Many types of ways are stored in the mapsforge map files and many of them are actually related to areas.

The user can choose to import:
  • ways: roads, railways, cableways and similar
  • waterways: lines that represent water
  • contours: contour lines if they are available
Since these data are heavy, the data are imported into a spatialite database.
This brings up a new issue: since this release a database for mapsforge extracted data is automatically created if there is none present. You will find a database named mapsforge_extracted.sqlite always present in your maps folder. And you will find 3 layers always present in the spatialite data layers: osm_waterlines, osm_roads and osm_contours.



But let's get back to import the data. Just select the data you want to import and push the start button. In the case you selected all data types, you should see first an import dialog like this:


and then something like this:


Nice ha? :-)
Depending on what has been imported first, the labels might not be coming from the right field. In that case you can simply change the label in the spatialite layer settings.

Before we look into it, let's see what happens in the case we use a map that also shows contour lines. To do so, we want to clear those layers. The fastest way to do so is to simply delete the mapsforge database and let geopap recreate it.
So after doing so and loading a map with contours I will have the same region as:



If you now import everything available exactly as before, you will get:


To have a better idea, change the background map to something different. I also change the contours color to white:






Label support is not advanced, so they get readable only once you zoom in:




That is quite cool ha? All from offline data!!

You now might wonder why all imported notes have a (MF) in their name. That is done so one can quickly select and remove them. Believe me, that is a feature you want to have. The region I am showing you has few points and already around 50 notes have been imported. In towns this is exponential.

This anyways brings us to the next point:

Enhancement of notes handling

While working on this, I noticed that when importing notes, all my notes got hidden in the mass of imported notes. Also, many of the imported notes are POIs that I do not care about (ex. benches, towers, etc).

The current notes list didn't have the tools to handle this. So how does it work now?
Enter the new notes list:


This is how it looks like after the previous import. Somewhere there is also a note I created manually "My tiny note".

As you can see, notes can now be selected (checkbox on left). You can zoom to the note as before and all other icons are now in the last one on the right side.

If you tap it, you get a context menu:


  • Edit: as before it allows you to edit a note if it is a form note and view image notes
  • Share: share the note in social networks
  • Delete: delete the note
  • Use as selection: this gives the possibility to select only those notes that have the same name as the one used to pop the menu
  • All notes: opens a submenu for actions that apply to all notes
 Lets assume I want to remove all bus stops. I select the menu on any of the bus stops and tap on the Use as selection.

Only the bus stops will be visible and selected:






Now access the All notes menu:





well, it is quite clear what to do. Delete all selected.


What if I want to remove all mapsforge notes? Insert (MF) in the filter text and remove all selected.

Last but not least, with all this spatialite fiddling, a big help has been added for vector editing.

Import a template spatialite database

If you go in the import section, you will find a new entry: Default Database.

When hitting that, you are asked to name the new database to create, let's use testdb for the sake of this example.






Now you will have to restart geopap, sadly that is still required. One it is done, go in the spatialite database view. 3 new layer of the database testdb.sqlite will be visible:






While lines and points won't be of much use in geopap yet, you will find the polygon layer interesting, since it is editing ready. Enable editing and edit right away. Since it is a template db, the attributes table has been created as 20 fields with names from field1 to field10. As said, very simple, but in my opinion still of use when you have to quickly collect some polygon data with attributes.






That is all for this release... enjoy!!!







by andrea antonello (noreply@blogger.com) at February 25, 2015 11:21 AM

gvSIG Team

Generar etiquetas por escala (nueva extensión)

Ya hemos visto como crear leyendas por escalas con la nueva extensión “Complex Legend”. Teniendo ese mismo complemento instalado en nuestro gvSIG también podremos generar etiquetas en función de la escala a la que se encuentre nuestra Vista.

Vamos a repasar su funcionamiento

Como siempre, el primer paso será ir a las opciones de etiquetado: abrimos la ventana de propiedades de la capa sobre la que se aplicará el etiquetado (con botón derecho sobre el nombre de la capa en la Tabla de Contenidos de la Vista) y seleccionamos la pestaña ‘Etiquetado‘.

28_gvSIG_escalasLa definición de una etiqueta sensible a la escala se encuentra dentro del panel de “Etiquetas definidas por el usuario”.

29_gvSIG_escalasPor lo que respecta al panel asociado, apenas ha cambiado su estructura, por lo que se puede manejar de forma habitual; simplemente habrá que tener en cuenta que hay que tener seleccionada la operación “Definir diferentes clases de entidades y etiquetarlas de manera diferente” y la nueva opción de “Multiple label by scale del menú desplegable, tal y como se especifica en la imagen que sigue.

30_gvSIG_escalasUna vez marcada esta opción, se puede añadir una entrada que definirá la etiqueta a mostrar, pinchando directamente sobre el campo de “Expresión de etiqueta” que se ha añadido sobre la tabla.

La ventana que se muestra es muy similar a la que ya se conocía anteriormente, salvo que aparece una nueva pestaña en la parte superior que mostrará el formulario donde se indicará el rango de la escala sobre la que estará visible la etiqueta.

31_gvSIG_escalasUna funcionalidad de lo más interesante, ¿verdad?


Filed under: gvSIG Desktop, spanish Tagged: escalas, etiquetado, etiquetas, gvSIG 2.2

by Alvaro at February 25, 2015 08:03 AM

February 24, 2015

Jody Garnett

CSS Workshop is Live on GeoServer User Manual

Quick thanks to Travis and Mike for porting my FOSS4G CSS Workshop into the GeoServer User Guide (and to Eva Shon who helped with the initial workshop).

Here is the direct links to the latest user guide:


The GeoServer community would love a hand testing GeoServer 2.7-RC1. It has an all new GeoTools based css extension and we need your feedback!

by Jody Garnett (noreply@blogger.com) at February 24, 2015 01:56 PM

gvSIG Team

Verso gvSIG 2.2: Estensione di pubblicazione

Questa estensione diventerà uno strumento indispensabile per gli utenti che hanno bisogno di pubblicare le proprie mappe utilizzando applicazioni MapServer, MapProxy e TinyOWS.

L’obbiettivo è quello di consentire la pubblicazione automatica dei servizi cartografici, cercando di ottenere risultati il ​​più possibile fedeli al lavoro originale che abbiamo realizzato in gvSIG 2.1.

L’estensione si trova sotto il nome di ‘org.gvsig.publish‘, e può essere installato attraverso il ‘Gestore delle estensioni’ selezionando installazione da URL e selezionando dalla lista il repository di test (Testing gvSIG repository – http://downloads.gvsig.org/download/gvsig-desktop-testing/).

Una volta installato avrete accesso alle funzionalità di pubblicazione tramite Vista> Esporta> Esporta vista a mapfile, oppure tramite il pulsante corrispondente.

Vediamo ora una breve guida sul funzionamento di questa applicazione:

Selezione della cartella di lavoro locale

Per operare più agevolmente, l’estensione richiede che si definisca una cartella in locale per memorizzare e creare l’intera struttura del progetto.

Si può lavorare su una nuova directory vuota (creata ex novo o già esistente) oppure su di una su cui abbiamo già lavorato in precedenza (per unire più lavori in un unico progetto).

Opzioni avanzate: Selezione dei servizi

Se attiviamo la casella di controllo ‘avanzate’ è possibile accedere ai servizi disponibili attraverso la scheda ‘servizi’ dove è possibile selezionare i servizi desiderati eseguendo la pubblicazione una volta sola.

Ogni servizio genererà un sottocartella nella directory di progetto in cui saranno creati i file necessari per il corretto funzionamento del servizio desiderato.

Inoltre, è possibile definire il nome con cui il servizio sarà visualizzata dai clienti e la relativa descrizione.

01_gvSIG_Publish

Creazione del progetto

Se la cartella locale di destinazione in cui memorizzare il progetto non è vuota, l’applicazione chiederà di scegliere tra la sovrascrivere, aggiungere o cancellare.

  • Sovrascrivi: crea tutti i file necessari per il progetto, potendo modificare il contenuto dei precedenti file se richiesto.
  • Inserisci: se si desidera aggiungere ulteriori informazioni a un progetto esistente, senza perdere le informazioni precedenti.

Questo è giusto un assaggio, nei post successivi vedremo le possibilità fornite da questo plugin per l’editing manuale di attributi specifici e come caricare il progetto sul server. Per non parlare delle possibilità di combinazione con un altro plugin, che speriamo di pubblicare presto, in grado di generare legende ed etichette in funzione della scala …


Filed under: gvSIG Desktop, Italian, testing Tagged: gvSIG 2.2, mapProxy, mapserver, publicación, TinyOWS

by Giuliano Ramat at February 24, 2015 12:55 PM

gvSIG Team

gvSIG 2.1: da Excel a gvSIG

Durante l’ultimo Summer Google Code è stato sviluppato un nuovo plugin per gvSIG 2.1. Questo plugin permette di caricare i dati precedentemente salvati in formato Microsoft Excel.

Questo plug-in sarà incluso di default nella prossima generazione di gvSIG, ma è possibile testarlo fin da subito.

E’ possibile installare il plug-in attraverso il Gestore delle Estensioni selezionando l’opzione “Installazione standard”, che accede ai plug-in di base già inclusi nella distribuzione gvSIG; sia attraverso il “Installazione da URL”, accedendo anche ai plug-in disponibili sul repository remoto di gvSIG.
Possiamo anche installare alcun plug-in dalla opzione “Installazione da file”; questa opzione può essere molto utile per testare le estensioni che non sono né nella distribuzione standard né sul repository remoto.
Diamo uno sguardo rapido al video in cui si mostra come installare il plug-in di Excel, il file può essere scaricato da qui.

Una volta installato, è necessario riavviare gvSIG e verificare che l’aggiunta di una nuova tabella in formato Excel sia supportata.

Attraverso questo plug-in è possibile:

  • Caricare fogli di calcolo Excel come tabelle
  • Caricare fogli di calcolo Excel come layer

In gvSIG possiamo definire le seguenti proprietà del file Excel da aggiungere.

Le proprietà principali sono:

  • File: percorso del file
  • Locale: elenco a discesa per scegliere la configurazione che definisce il set di caratteri usati come separatori per migliaia e decimali.
  • Foglio da aggiungere: elenco a discesa per selezionare il file di Excel da caricare come tabella.
  • Usa prima riga come intestazione: Se questa opzione è attivata, la prima riga verrà usata per definire i nomi dei campi.
  • CRS: se il foglio di lavoro di Excel contiene dei campi coordinate, questo parametro consente di specificarne il sistema di riferimento.
  • Punti (X, Y, Z): campi che contenengono le coordinate. Nel caso in cui foglio Excel contenga coordinate, almeno i campi X e Y devono essere indicati.

Possiamo anche definire altre proprietà (nella scheda “Avanzate”) come, ad esempio, forzare il tipo di campo quando si carica la tabella. Nel manuale del plug-in si possono trovare delle informazioni più dettagliate.
Come detto, in gvSIG 2.1, è possibile aggiungere un foglio Excel e, in presenza di coordinate, lo possiamo aggiungere direttamente come layer.

Vediamo un esempio in cui si aggiunge un foglio di calcolo Excel come tabella contenente l’età media della popolazione africana. In questo esempio abbiamo specificato che la prima riga contiene i nomi dei campi.

Nel secondo esempio si vede come aggiungere un foglio di calcolo di Excel, che ha i campi con le coordinate, direttamente come un layer. In questo caso definiamo il CRS ed i nomi dei campi contenenti le coordinate x ed y, denominati “X” e “Y”.


Filed under: gvSIG Desktop, Italian Tagged: Excel, gvSIG 2.1, Table

by Giuliano Ramat at February 24, 2015 11:23 AM

gvSIG Team

On the road to gvSIG 2.2: Publishing extension

This extension will become an indispensable tool for users who need to publish their maps using MapServer, MapProxy and TinyOWS.

Its aim is to enable a process automation for the maps publishing services , trying to obtain results as true as possible to the original work made in our gvSIG 2.1

The extension can be found with the name ‘org.gvsig.publish‘, and it can be installed from the ‘Plugin Manager’, selecting the URL installation and in the drop-down of (Testing gvSIG repository – http://downloads.gvsig.org/download/gvsig-desktop-testing/).

Once installed, we will have access to the publishing functionality either through the menu View>Export>Export view to mapfile, either via the button appropriate.

Let´s see with a quick guide, how this extension works:

Selection of the local work directory

In order to operate more comfortably, this extension requires that you define a local folder on your computer to store and create the whole project structure.

It can be a new directory (created if doesn´t exist), empty or one which already has previously worked (to join several works in one only project).

Advanced options: Services selection

If we check the ‘Advanced options’, we will be able to access to the available services through the ‘Service’ tab, in which we can mark as many as we need, performing the publishing once.

Each service will create a subfolder with its name in the project directory and inside of the subfolder, all the files needed for that concrete service will be stored.

Also, we have offered the possibility to indicate the name under which the service will be displayed to customers and the description in the same form.

01_gvSIG_Publish

Project creation

If the final directory where the project is going to be stored is not empty, the app will ask us to choose between overwrite, add or cancel.

  • Overwrite: It will create all the files needed for the project, being able to change the previous files content if it is required.

  • Add: if we want to add more information to a project without losing any previous information.

In following posts, we will carry on with more possibilities of this new plugin, such as the manual edition of specific attributes and the upload of the project to the server. There are, as well, good possibilities with its combination with other plugin (which we hope to release soon) allowing to generate legends and label by scales.


Filed under: english, gvSIG Desktop, testing Tagged: gvSIG 2.2, mapProxy, mapserver, publishing, SDI, spatial data infrastructure, TinyOWS

by mjlobato76 at February 24, 2015 10:56 AM

gvSIG Team

gvSIG 2.1: Trascinare i layers dall’esplora risorse

In gvSIG 2.1 troviamo un altro piccolo miglioramento, ma che porta molti vantaggi per gli utenti. E ‘ la possibilità di trascinare i layer dall’esplora risorse all’interno nella nostra Vista per aggiungervi automaticamente il layer.

Nel video possiamo vedere questa procedura:


Filed under: gvSIG Desktop, Italian Tagged: gvSIG 2.1

by Giuliano Ramat at February 24, 2015 10:38 AM

gvSIG Team

Etichettatura avanzata in gvSIG 2.1

Una delle caratteristiche che si possono trovare in gvSIG 2.1 è l’etichettatura avanzata che comprende molte opzioni e strumenti per personalizzare le etichette in base alle esigenze dell’utente. L’etichettatura avanzata è stato migrata da gvSIG 1.x a gvSIG 2.1 , mantenendo tutte le opzioni di personalizzazione esistenti ed aggiungendo alcune opzioni fra le più richieste dalla comunità degli utenti come, ad esempio, l’opzione alone.

Di seguito sono disponibili due video che mostrano alcune ( fra le tante ) opzioni di etichettatura.

Nel secondo video si mostra come visualizzare le etichette unicamente per gli elementi selezionati.


Filed under: gvSIG Desktop, Italian Tagged: etiquetado, etiquetar, gvSIG 2.1, halo

by Giuliano Ramat at February 24, 2015 10:22 AM

gvSIG Team

gvSIG 2.1: Editazione alfanumerica nella Vista

Una delle nuove funzioni incluse in gvSIG 2.1, grazie al contributo della società brasiliana GAUSS geotecnologia e engenharia, è uno strumento tanto facile quanto utile: un editor alfanumerico che permette di modificare gli attributi di qualsiasi elemento di un layer senza doverne aprire la tabella.

Il suo funzionamento è simile allo strumento “Informazioni”, ma con in più la possibilità di modificare gli attributi dell’elemento selezionato. In questo modo le operazioni di modifica risultano decisamente velocizzate.

Di seguito è possibile vedere un video su questo nuovo ed utile strumento :


Filed under: gvSIG Desktop, Italian Tagged: editing, editor, gvSIG 2.1

by Giuliano Ramat at February 24, 2015 10:01 AM

gvSIG Team

Verso gvSIG 2.2

road

Dopo l’uscita di gvSIG 2.1, inizia il cammino verso gvSIG 2.2, durante il quali chiediamo la vostra collaborazione, sia per la fase di test che per ogni altro possibile contributo sia tecnico che economico.

Eravamo in attesa del rilascio di gvSIG 2.1 per stabilire un regolare programma di pubblicazione delle nuove versioni di gvSIG. La nostra intenzione, ispirandosi a progetti come Ubuntu, è quello di pubblicare due versioni ogni anno, verso maggio e dicembre, quest’ultima in concomitanza con la Conferenza Internazionale gvSIG a Valenzia.

In questo modo sia i gruppi di sviluppo che le varie organizzazioni che utilizzano gvSIG potranno pianificare le loro attività sia per quanto riguarda l’invio di contributi tecnici che per l’aggiornamento delle versioni.

gvSIG 2.2 dovrebbe essere quindi disponibile in maggio.

Cosa abbiamo in programma per questa nuova versione? A livello di sviluppo non ci saranno grandi cambiamenti nel nucleo, essendo la 2.2 una versione che permetterà di continuare il debug oltre ad aggiungere nuove estensioni di cui stiamo ultimando lo sviluppo.

Nelle prossime settimane verranno rilasciate nuove estensioni che dovrebbero essere incluse nella prossima versione di gvSIG (e si potranno utilizzare anche su gvSIG 2.1) per permettere agli utenti di aiutarci nella fase di test. Segui le notizie che verranno periodicamente pubblicate visto che ci saranno novità veramente interessanti.


Filed under: gvSIG Desktop, Italian, technical collaborations, testing Tagged: gvSIG 2.2, road map

by Giuliano Ramat at February 24, 2015 08:31 AM

gvSIG Team

Nueva extensión: Generar leyendas por escala

Seguimos avanzando hacia gvSIG 2.2 con un nuevo complemento que permite trabajar con leyendas por escala (también con etiquetados, pero eso lo veremos en otro post).

El plugin se denomina Complex Legend extension  y, como es habitual, podemos instalarlo a través del administrador de complementos, indicando instalación desde URL y en el desplegable el repositorio de testing (Testing gvSIG repository – http://downloads.gvsig.org/download/gvsig-desktop-testing/).

Veamos como funciona…

Realizamos el proceso habitual para cambiar la Simbología de una capa: abrimos la ventana de “Propiedades” de la capa sobre la que se aplicará la leyenda (con botón derecho sobre el nombre de la capa en la tabla de contenidos de la vista) y seleccionamos la pestaña ‘Simbología’.

23_gvSIG_escalasDentro de las distintas opciones de leyendas disponibles veremos que se ha añadido una nueva: “Símbolo complejo”. La seleccionamos.

24_gvSIG_escalasA continuación se presentará un formulario en el que se comenzarán a definir los rangos de escalas con los que se trabajará y los tipos de leyenda a utilizar en cada tramo.

Podemos incluir nuevos rangos a través del botón ‘añadir‘ (representado con una cruz verde) y eliminar el seleccionado mediante el botón ‘borrar‘ (aspa roja).

25_gvSIG_escalasEn función de los datos introducidos se irá completando el combo y se rellenará el panel inferior con el formulario necesario para rellenar los parámetros característicos de la leyenda.

26_gvSIG_escalasDespués de esto, sólo queda repetir esta operación tantas veces como rangos se deseen definir para la capa.

27_gvSIG_escalasPulsamos aceptar y vamos a comprobar el resultado. Si todo ha ido bien, la capa irá cambiando la leyenda de forma dinámica en función de la escala a la que se encuentre la vista.

Otra utilidad interesante es que en los rangos no cubiertos por la leyenda no se mostrará ninguna información, es decir, podemos hacer que la capa esté “invisible” para escalas no definidas.

En un próximo post veremos como generar etiquetas por escala.


Filed under: gvSIG Desktop, spanish, testing Tagged: escala, gvSIG 2.2, leyendas, simbología

by Alvaro at February 24, 2015 07:57 AM

February 23, 2015

gvSIG Team

gvSeismic: añadir información de sísmica de formatos no soportados

Ya hemos visto como trabajar con los formatos de sísmica soportados por la extensión de gvSeismic en gvSIG. Pero…¿podemos trabajar con nuevos formatos que no soporte la extensión?

En definitiva, en este caso, se trata de generar lo que se conoce como un sistema de parseado nuevo.

Los pasos a seguir serían los siguientes:

  • Añadir una capa nueva a la vista y, dentro de la pestaña Archivo, cargar el nuevo fichero.

03_gvSIG_Seismic

  • En este punto pueden ocurrir dos cosas: que el fichero se muestre o no. Si no se muestra, se deberá escribir un asterisco (*) en el cuadro de texto del nombre de fichero, y pulsar la tecla Intro. Se nos mostrarán todos los ficheros disponibles. Una vez hecho esto, seleccionamos el fichero que queremos añadir a nuestra Vista.

  • Importante: Antes de pulsar el botón “Abrir” debemos seleccionar la opción “CSV file” en el desplegable de tipos de archivo.

04_gvSIG_Seismic

  • Ya tenemos el fichero en la ventana de “Añadir capa”. Ahora vamos a definir las características del parseador para extraer la información. Para ello pulsamos el botón ‘Propiedades‘ y nos dirigimos a la pestaña ‘Advanced‘.

  • Las características a definir son:

    • Header: Indica el nombre de los campos, separados por comas.

      Por ejemplo, según la especificación del UKOOA-84, si este fichero no fuera soportado por la extensión, se debería poner: nombre_linea, num_linea, latitud, longitud, este, norte, elevacion

    • Number of lines to skip: si el fichero tiene cabecera, indicar cuántas líneas lo componen, para que no sean interpretadas como datos.

    • Fields definition: Aquí se especifica la posición de cada uno de los campos sobre la línea de datos.

      Veamos un ejemplo:, si se tiene esta línea (y apoyados en la definición del estándar):

      A-58A-1-A-58A-17 469070050.14N0710535.72W 268745.3 775813.1 123.2

      vemos que comienza con un espacio en blanco, y luego empieza el nombre de línea, que irá desde la 2a posición hasta la 17 (A-58A-1-A-58A-17); el número de punto se ubica entre la 18 y 25 (469); la latitud va desde la 26 a la 35 (070050.14N); la longitud lo hace desde la 36 a la 46 (0710535.72W), etc. Esta línea se rellenaría indicando la posición inicial y la final de cada campo, separando los distintos campos por espacios (en el último campo con indicar únicamente el principio es suficiente):

      2:17 18:25 26:35 36:46 47:55 56:64 65:

    • CRS: el sistema de proyección de los datos del fichero.

    • FieldTypes: el tipo de dato de cada campo: string (texto), integer (número entero), float (número decimal), double (número decimal de coma flotante), boolean (valores binarios verdadero/falso) y geometry (campos con geometrías).

      En el ejemplo: string, integer, string, string, float, float, float

    • Point: se indican los campos que definirán la geometría punto.

      En el ejemplo: este, norte

05_gvSIG_Seismic

Si la definición de los datos es correcta, la capa se añadirá a la vista:

06_gvSIG_SeismicTerminamos la serie de post dedicada a la nueva extensión gvSeismic. En breve seguiremos publicando post sobre las novedades en las que estamos trabajando en el camino a gvSIG 2.2.


Filed under: gvSIG Desktop, spanish, testing Tagged: gvSIG 2.2, sísmica

by Alvaro at February 23, 2015 08:47 AM

Tyler Mitchell

iPhone cable – loose connection?

iPhone cable – mysterious loose connection bothering you?  Before buying a new gold plated cord or adapter, clean out the port with a toothpick.  You will be amazed!

The post iPhone cable – loose connection? appeared first on spatialguru.com.

by Tyler Mitchell at February 23, 2015 05:29 AM

February 22, 2015

Paulo van Breugel

GRASS GIS 7.0 is out!

It has taken many years of development, but finally the new stable major release GRASS GIS 7.0.0 is available. Many congratulations to the developers, they did an incredible job. This version provides numerous new functionalities, including completely new modules (e.g., the spatio-temporal database support) and massive improvements in data handling, with support for massive vector […]

by pvanb at February 22, 2015 10:40 PM

Markus Neteler

New stable release of GRASS GIS 7.0.0!

The GRASS GIS Development team has announced the release of the new major version GRASS GIS 7.0.0. This version provides many new functionalities including spatio-temporal database support, image segmentation, estimation of evapotranspiration and emissivity from satellite imagery, automatic line vertex densification during reprojection, more LIDAR support and a strongly improved graphical user interface experience. GRASS GIS 7.0.0 also offers significantly improved performance for many raster and vector modules: “Many processes that would take hours now take less than a minute, even on my small laptop!” explains Markus Neteler, the coordinator of the development team composed of academics and GIS professionals from around the world. The software is available for Linux, MS-Windows, Mac OSX and other operating systems.

Detailed announcement and software download:
http://grass.osgeo.org/news/42/15/GRASS-GIS-7-0-0/

About GRASS GIS
The Geographic Resources Analysis Support System (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an open source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The post New stable release of GRASS GIS 7.0.0! appeared first on GFOSS Blog | GRASS GIS Courses.

by neteler at February 22, 2015 10:15 PM

Slashgeo (FOSS Articles)

New stable release: GRASS GIS 7.0.0

The GRASS GIS Development team has announced the release of the new major version GRASS GIS 7.0.0. This version provides many new functionalities including spatio-temporal database support, image segmentation, estimation of evapotranspiration and emissivity from satellite imagery, automatic line vertex densification during reprojection, more LIDAR support and a strongly improved graphical user interface experience. GRASS GIS 7.0.0 also offers significantly improved performance for many raster and vector modules: “Many processes that would take hours now take less than a minute, even on my small laptop!” explains Markus Neteler, the coordinator of the development team composed of academics and GIS professionals from around the world. The software is available for Linux, MS-Windows, Mac OSX and other operating systems.NagsHead

Detailed announcement and software download:

http://grass.osgeo.org/news/42/15/GRASS-GIS-7-0-0/

About GRASS GIS

The Geographic Resources Analysis Support System (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The post New stable release: GRASS GIS 7.0.0 appeared first on Slashgeo.org.

by markusN at February 22, 2015 10:10 PM

February 21, 2015

Geomatic Blog

EMT Madrid, or Open Data antipatterns

Today, february 21st 2015, is the Open Data Day. And given that I’m far asay from my favourite Open Data nerds down at the Medialab Prado, I decided to work on giving the old ¿Cuánto Tarda Mi Autobús? website a facelift.

The story behind ¿Cuánto tarda mi autobús? is rather simple. A couple of years ago I got my first smartphone, and one of the things I wanted to do is check for the bus times in Madrid. Back then, EMT Madrid (the public company which runs the buses) was heavily promoting its new website in the Spanish GIS scene. The major problem was that the website for checking the times was made with Flash (actually, with ESRI Flex) and simply there is no way to use that with a smartphone.

So I reverse-engineered the protocol (if you call “reading a WSDL document” reverse engineering), did a bit of PHP plus Leaflet, and I was able to check the bus times with a web app.


 

Fast-forward to the present. EMT had released the API details under the banner of «Open Data EMT», I had a saturday to devote to the Open Data Day, and my little web app needed some love after two years of no updates at all.

But, oh boy, every time I try to develop anything with interfaces made by big subcontractors, I cannot stop cringing at the amount of WTF found around.

The antipatterns

Antipattern 1: «Open Data» which isn’t actual Open Data.

In the same way that Open Source software can only be Open Source if it meets the Open Source Definition, Open Data is only Open Data if it meets the Open Definition. Period. These definitions are evolved versions of the DFSG and Free Software Definition, curated with years of experience and discussions about what is open and what is not.

So, the Open Definition states:

2.1.8 Application to Any Purpose

The license must allow use, redistribution, modification, and compilation for any purpose. The license must not restrict anyone from making use of the work in a specific field of endeavor.

From «OpenData EMT»’s terms and conditions:

1. The re-user agent is explicitly prohibited from distorting the nature of the information, and is obliged to:
a. Not to manipulate nor falsify the information.
b. Ensure that any information displayed in your system is always up to date.
c. Not to use the information to undermine or damage EMT’s public image.
d. Not to use the information in sites that might lead to a relation with illegal acts or attempts to sabotage EMT or any other entity, organization or person.

So apparently I cannot:

  • Display historical information (because my data must be up-to-date).
  • Say that the system is a complete piece of steaming crap from a technological point of view.
  • Use the information in sites such as Facebook or Twitter, because those sites might be used for an attempted sabotage to «any entity or person». Who the fuck wrote this blanket clause, folks?

Please, don’t call it «Open Data».

I have to give praise to the EMT, though. The previous version of the agreement obliged the reuser to not disclose that he/she signed an open data agreement. At least they fixed that.

Antipattern 2: Your SOAP examples contain raw XML.

The whole point of SOAP was to abstract data access. And, still, every public SOAP interface I’ve ever seen includes examples with raw XML fragments that you’re supposed to build up.

If you cannot write code that access SOAP without writing XML, you’re doing it wrong.

Think about how WMS interfaces work nowadays: you just publish the WMS endpoint, and your GIS software takes care of the capabilities and the

Antipattern 3: Keep default fake values in your production code.

From the docs:

tempuri

Note «tempuri.org». A quick search will tell you that the system was designed using Visual Studio, and some lazy so-called software engineer didn’t bother to change the defaults.

Antipattern 4: Fuck up your coordinate systems

Note to non-spaniard readers: The city of Madrid is located roughly at latitude 40.38 north, longitude 3.71 west.

Now look at this example from the EMT docs about how bus coordinates are returned:

positionbus

Antipattern 5: Mix up your coordinate systems

Write things like “UTM” and “geodetic” in your documentation, but do not write which UTM strip you’re referring to (hint: it’s 30 north, and the SRS is EPSG:23030). Make some of your API methods to return coordinates in EPSG:23030 and some others to return coordinates in EPSG:4326.

And for extra fun, have your input coordinate fields accept both of those SRSs as strings with comma-defined decimal point, and then do this in the documentation:

coordinateint

Antipattern 6: Self-signed SSL certificates

Srsly?

sslcert

Antipattern 7: Wrap everything up in HTTP + JSON and call it “REST”

REST is a beautiful technology because it builds up pretty much on top of raw HTTP. Every object (“resource”) has its own URI (“universal resource identifier”), and the HTTP verbs are used semantically (GET actually gets information, POST modifies information, DELETE deletes a resource, and so on).

Also, HTTP status codes are used for the return status. An HTTP status code 200 means that the data is OK, a 404 means that the resource doesn’t exist, a 401 means that you are not authorized to get/post/delete the resource. Reusing the semantics of HTTP is way cool.

So, in a REST interface for bus stops, the stop number 1234 (a resource) would be located at its URI, e.g. http://whatever/stops/1234. It’s beautiful because the URI has a meaning, and the HTTP verb GET (which is the default when a web browser is fetching something) has a meaning. The server would answer with a “200 OK” and then the resource.

Low-level, it should look like:

GET /stops/1234 HTTP/1.1

-----

HTTP/1.1 200 OK
Content-Type: text/JSON

{
"stopId": 1234, 
"latitude": 40.3,
"longitude": -3.71,
"stopName": "Lorep Ipsum Street",
"lines": ["12", "34"]
}

Now compare the theoretical RESTful way to fetch one bus stop with the real-life mess:

POST /emt-proxy-server/last/bus/GetNodesLines.php HTTP/1.1
idClient=user&passKey=12345678-1234-1234-12345678&Nodes=1234

-----

HTTP/1.1 200 OK
Content-Type: text/JSON

{
"resultCode":0,
"resultDescription":"Resultado de la operacion Correcta",
"resultValues":{
  "node":1234,
  "name":"ROBERTO DOMINGO-AV.DONOSTIARRA",
  "lines":["21\/1"],
  "latitude":40.434861209797,
  "longitude":-3.6608600156554
  }
}

So, meaningless URI, POST request to fetch a resource, duplicated return status codes (for the HTTP layer and some other underlying layer).

Let me say this very, very clearly: In REST, you do not wrap a resource in a call to get that resource. Geez.

My takeaway

Readers will do good to keep in mind that I’m using my spare time in order to participate in the Open Data Day, for fun. The problem is that working with such an arquitecture is no fun at all. I can deal with these kind of enterprisey, Dilbertesque software stacks in a day-to-day basis, but only if I’m getting paid to endure the cringing and teeth-grinding.

I think it’s because the mind of an Open Source / Open Data nerd like me is difficult to understand by the classic propietary software people. I develop software just for the fun of doing so, just because I can, just because I like the feeling of empowerment of creating my own tools.

I write a lot of open source stuff. I fix wikipedia from time to time, I map stuff on OpenStreetMap if something’s wrong. I like to do it, and I empower other people to build upon my work.

Building upon good Open Source/Data doesn’t feel like standing on the shoulders of giants. It feels like standing on the soulders of a mountain of midgets… and if you’re lucky, you’ll be one of those midgets and someone will stand upon your shoulders.

For me, that involves a great deal of humility. When I watch the closed-source crowd talk about their latest product or software, they are congratulating themselves, but when I watch the open-source crowd, they’re constantly critizising themselves. And I can critizise them and they can critizise me and we all learn and that’s why they’re awesome.

</rant>


Archivado en: formatos, geodatos, opinión

by RealIvanSanchez at February 21, 2015 04:20 PM

OSGeo News

Geo for All - Open Education Award 2015. Nominations till 28th Feb 2015

by jsanz at February 21, 2015 11:52 AM

GeoServer Team

GeoServer 2.7-RC1 Released

The GeoServer team is pleased to announce the release of GeoServer 2.7-RC1 with some great new features. The download page for 2.7-RC1 provides links for zipwardmg, and exe bundles. As a release candidate, 2.7-RC1 is considered experimental and is provided for testing purposes. This release is not recommended for production (even if you are enthusiastic about the new features).

This release is made in conjunction with GeoTools 13-RC1 and GeoWebCache 1.7-RC1. Thanks to Ben Caradoc-Davies (Transient Software, New Zealand) for making this release, Kevin Smith (Boundless) for releasing GeoWebCache 1.7-RC1, Jody Garnett (Boundless) for building the dmg and testing, and a big thanks to Andrea Aime (GeoSolutions) for gathering up the contents (and pictures) for this blog post, which is based almost entirely on his post announcing the release of 2.7-beta.

A complete change log since 2.7-beta is available from the issue tracker.

Please Download and Test

The committers have a great release for you to look forward to, we would like to ask you to download and test. By trying GeoServer out on a wide range of platforms and datasets we can all help the next release be great.

Testing is a key part of the open source social contract. This is your best chance to identify issues early while we still have time to do something about it. If you make use of commercial support ask your vendor about their plans for 2.7-RC1 testing.

When testing Geoserver 2.7-RC1 please let us know on the user list how it works for you. We will be sure to thank you in the final release announcement and product presentations.

New Features

Color composition and blending

Color composition and blending are two new extensions to SLD allowing the web map styler to control how overlapping layers in a map are merged together. Beyond the simple stacking and translucency control a wide range of effects are now possible by allowing masking and specific color operations for blending layers together in new ways.

A common well known example is a polygon thematic map on top of a DEM, which tends to provide under-par results using only transparency control, but generates very appealing ones when using the “multiply” blending mode:

Alpha masking also allows for neat cartographic tricks, like the one below, where the polygon fill has been cut at the border of the states generating a “inner line” effect:

Check out the documentation for a list of supported operations and some examples. We would like to thank Cleveland Metroparks for sponsoring this improvement.

WPS Clustering

GSIP 119 added support for asynchronous requests over a cluster of GeoServer instances. In WPS an asynchronous request starts by returning the client a URL that can be polled in order to know about the execution progress, and eventually to retrieve the final results.  Previous to 2.7-beta the status information was kept in memory, thus only the GeoServer instance running the process could meaningfully respond to a poll from the client. With GeoServer 2.7-beta a new extension point allows the programmer to create a process status repository that can be shared among the GeoServer instances.

The first default implementation of the shared repository is a Hazelcast based one, leveraging in-memory, replicated and distributed maps to share the state information, while the results (which can be pretty large) are stored in a shared file system. The community is welcome to develop other variants that could store the information in other places, for example, a relational database, a nosql one, or in the cloud (e.g., S3 storage).

WPS Security

GSIP 121 added the ability to provide fine grained access control to processes based on our usual role based authentication system: each process or group of processes can be associated to a list of roles that can access them, while other users will be disallowed seeing or accessing the same processes.

../../_images/security-groups.png

WPS Limits

Integrating with the security, GSIP 123 added support for process execution limits, bringing WPS up to par with the other OGC services in terms of limiting the resources used by a single request. In the main WPS panel one can now configure how much processing time to give synchronous and asynchronous requests:

../../_images/execution.png

Also, in the new process security page one can configure a global limit for the size of complex inputs (see above), it is also possible to configure limits on a process by process basis, in order to restrict the size of inputs, the range of numerical values, and the multiplicity of repeatable inputs, to constrain the effort of a WPS process call. All these limits will be dutifully reflected in the DescribeProcess output.

../../_images/process_limits.png

If you’re not satisfied with the above limits and would like to develop new ones, no worries, the current code is setup on a pluggable WPSInputValidator extesion point that will allow you to create new types of input validators.

WPS Dismiss

The final Finally, GSIP 122 added the ability to dismiss an ongoing process from the client that requested the execution, or as an administrator. The new Dismiss operation comes from the WPS 2.0 specification, which GeoServer does not support yet, so it has to be seen as a vendor extension to WPS 1.0, which leverages the executionId parameter returned in the asynch status links to allow execution cancellation, you can read more about it in the user documentation. The administrator instead gets a new user interface panel showing the currently running operations, allowing selection and forceful dismissal of processes that are running:

../../_images/statuspage.png

The user guide contains more details about its usage. We would like to thank NATO STO CMRE for sponsoring all the above WPS improvements.

Refresh of the CSS module

The initial CSS extension (responsible for using CSS to generate SLD styles) was written in Scala. Although wildly popular, and featured up until GeoServer 2.6, the module has not been maintained to the level expected of a GeoServer extension.

Andrea has taken it unto himself to address this gap, rewriting the functionality in Java and making the result available to the GeoTools library.

The new CSS engine performs the same function as the Scala original and has managed to make a few key improvements. In particular the Java implementation can efficiently handle large CSS files without bogging down with minutes of translation time.

The user interface for the CSS editor has also been revamped a bit, making better usage of available screen space, and sporting syntax highlighting and formatting thanks to CodeMirror. This change addresses a common gripes correctly supporting relative images (the generated SLD preserves the relative path) and polygon with strokes are now translated to a single polygon symbolizer (to the benefit of GetLegendGraphic calls). Finally, you’ll notice that the download size have been significantly trimmed, as we don’t need anymore the Scala runtime.

The new translator has been tested against a few hundreds CSS styles already, but of course it’s new, so it’s of paramount importance that you test your own styles, and let us know if you notice any regression.

We take the occasion to thank David Window for creating the initial CSS module, and Andrea Aime for porting it to java and acting as the new maintainer.

Relative time support in WMS/WCS

As you probably knows GeoServer supports time based filtering in both WMS (aka WMS-T) and WCS (as part of WCS-EO). Up until now you had to specify the desired time either as an absolute value, e.g. &time=2011-05-02, or as an absolute range of values, e.g. &time=2011-05-02/2011-05-05.

The work done in GSIP 124 adds support for a vendor specific extension to the time syntax which allows the specification of relative times, e.g., the last 36 hours, “PT36H/PRESENT”, or the day after December 25 2012, “2010-12-25T00:00:00.0Z/P1D”.

This allows for more compact requests, but more importantly, it allows to generate stable, publishable links to instants or intervals relative to the present server time, e.g., the weather forecast for tomorrow, two days and three days in the future, or the temperature maps for the last three days, maybe in a KML document generated with animations over time.

Miscellaneous

In addition a wide range of improvements have been made:

  • For those making printed maps, we added a new vendor parameter forcing GeoServer to ignore the WMS simple scale computation algorithm, and run a local and accurate one instead, resulting in better integration between printing requirements and maps with scale dependencies.
  • The flow-control module now also supports rate based rules, with the ability to slow down, or simply reject, requests that are incoming from a specific client at an excessive rate.
  • For those working at the dateline, you’ll be pleased to know that the WCS 2.0 GetCoverage requests can now handle bounding boxes crossing the dateline, and they will take the two halves of your coverage from the antipodes, merge them together in a single output file that will be returned to you (much like the same support for WMS, introduced in 2.6.0).
  • For people using configuration in the database, the JDBCConfig module and core modules have seen a number of changes to increase scalability and push down into the database as much filtering as possible in a larger number of commonly used code paths.
  • The DDS module, allowing extraction of DEM portions using the WMS protocol in order to feed Nasa Worldwind, has seen a number of fixes and now allows the specification of a texture compression format.
  • Finally, the map preview has been switched to OpenLayers 3, although the nostalgic can get back the OL2 based one by adding the “-DENABLE_OL3=false” parameter to the JVM startup options. Thanks to Bart for helping add this to GeoServer.

This concludes the most visible changes, if you are missing some please check the full changelog for details, there is quite a bit more stuff in there.

Community modules

In addition to the core GeoServer and extensions we have an active community area for experiments and new volunteers. This release comes with a number of new community modules that you might find useful.

Clustering modules

The community section now holds two clustering modules allowing a cluster of GeoServer instances to work against a shared vision of the data directory.

The first one, contributed by GeoSolutions, works using J2EE JMS messages to share the state against the various nodes, and allows the usage of the normal file based configuration, either in a shared data dir mode, or data dir per node mode. This is know as the “JMS clustering”, see the documentation for more details. The module is ready for testing as it’s part of the nightly builds.

The second one, contributed by Boundless, works by using Hazelcast distributed messages, and it’s designed to work best against the JDBConfig module. At this time there are no released artifacts or documentation, but the adventurous user will find it pretty easy to figure out.

GeoFence

The GeoFence advanced security subsystem has been donated to the GeoServer project by GeoSolutions earlier this year, this module is the plugin connecting a GeoServer instance to the GeoFence rule engine.

GeoFence allows to setup complex security rules and leverage the full power of the underlying GeoServer security subsystem, for example, it’s possible to establish security rules mixing in the same condition data and service being used, limit attributes available to certain users/operations, filter data so that certain records are not visible to the public, force certain default style to given user roles, and so on. The GeoFence wiki contains documentation on how to use and configure the system.

SOLR data store

The SOLR data store allows GeoServer to connect to a SOLR server and publish its spatial document via the OGC protocols, efficiently making maps, serving them via the WFS service, and allowing spatial analysis via WPS. The user interface allows to classify sets of documents as layers, and map the document variable structure into the fixed structure of simple feature types served by GeoServer.

You can read an introduction in this blog post, and delve into details in the user documentation.

New WPS output formats

The gs-gpx and gs-kml modules offer two new PPIO to translate feature collection resulting off WPS processes in the respective formats. The KML one, in particular, also supports limited input parsing, allowing to send KML documents as inputs to the WPS services.

The WPS download process

The wps-download community module forms the basis of an “advanced clip and ship” tool that allows a client to ask for data in a specific area, eventually reprojecting it, estimate the download size, and allow the preparazion of a zip package with the desired data, all via asynchronous calls, providing a good replacement for WFS/WCS when the amount of data to be extracted is too large to be delivered via synchronous HTTP calls.

About GeoServer 2.7

Articles and resources for GeoServer 2.7 series:

 

by Ben Caradoc-Davies at February 21, 2015 06:47 AM

Tyler Mitchell

Kafka Consumer – Simple Python Script and Tips

When you’re pushing data into a Kafka topic, it’s always helpful to monitor the traffic using a simple Kafka consumer script.  Here’s a simple script I’ve been using that subscribes to a given topic and outputs the results.  It depends on the kafka-python module and takes a single argument for the topic name.  Modify the script to point to the right server IP.

from kafka import KafkaClient, SimpleConsumer
from sys import argv
kafka = KafkaClient("10.0.1.100:6667")
consumer = SimpleConsumer(kafka, "my-group", argv[1])
consumer.max_buffer_size=0
consumer.seek(0,2)
for message in consumer:
 print("OFFSET: "+str(message[0])+"\t MSG: "+str(message[1][3]))

Max Buffer Size

There are two lines I wanted to focus on in particular.  The first is the “max_buffer_size” setting:

consumer.max_buffer_size=0

When subscribing to a topic with a high level of messages that have not been received before, the consumer/client can max out and fail.  Setting an infinite buffer size (zero) allows it to take everything that is available.

If you kill and restart the script it will continue where it last left off, at the last offset that was received.  This is pretty cool but in some environments it has some trouble, so I changed the default by adding another line.

Offset Out of Range Error

As I regularly kill the servers running Kafka and the producers feeding it (yes, just for fun), things sometimes go a bit crazy, not entirely sure why but I got the error:

kafka.common.OffsetOutOfRangeError: FetchResponse(topic='my_messages', partition=0, error=1, highwaterMark=-1, messages=)

To fix it I added the “seek” setting:

consumer.seek(0,2)

If you set it to (0,0) it will restart scanning from the first message.  Setting it to (0,2) allows it to start from the most recent offset – so letting you tap back into the stream at the latest moment.

Removing this line forces it back to the context mentioned earlier, where it will pick up from the last message it previously received.  But if/when that gets broke, then you’ll want to have a line like this to save the day.


For more about Kafka on Hadoop – see Hortonworks excellent overview page from which the screenshot above is taken.

The post Kafka Consumer – Simple Python Script and Tips appeared first on spatialguru.com.

by Tyler Mitchell at February 21, 2015 12:54 AM

February 20, 2015

Gary Sherman

Plugin Builder 2.8

The Update

Plugin Builder 2.8 is now available. This is a minor update that adds:

  • Suggestion for setting up an issue tracker and creating a code repository
  • Suggestion for a home page
  • Tag selection from a list of current tags
  • Documentation update, including information about using pb_tool to compile, deploy, and package your plugin
  • New URLs for Plugin Builder’s home page and bug tracking

Optional is now Recommended

In previous versions the following items were “Optional” when creating a new plugin:

  • Bug tracker
  • Home page
  • Repository
  • Tags

We’ve changed those from “Optional” to “Recommended” because they are important for the success and longevity of your plugin(s). Setting up a code repository on GitHub automatically gives you issue tracking and the ability for others to collaborate with fixes and enhancements through pull requests.

Using GitHub also gives you the ability to setup a home page right from your repository using GitHub pages.

Adding one or more tags to your plugin helps people find them easier when browsing the QGIS Plugins website.

Getting It

You can install Plugin Builder 2.8 from the Plugins -> Manage and Install Plugins… menu. Version 2.8 works on QGIS versions 2.0 and up.

February 20, 2015 09:00 AM

gvSIG Team

gvSeismic: funcionamiento básico

Vamos a explicar el funcionamiento básico de la extensión de gvSIG para trabajar con datos sísmicos.

Una vez instalada la extensión, en la ventana de ‘Añadir capa‘, se encontrará una nueva pestaña perteneciente a la extensión. A través de ella se podrá realizar la carga de tantos ficheros de sísmica como se quiera.

Una vez seleccionados los ficheros con los que queremos trabajar, gvSIG indicará si es soportado por los drivers de la extensión (se mostrarán en rojo los no soportados) y si se ha detectado de forma automática el sistema de coordenadas, siendo necesario indicarlo a mano a través del botón propiedades en caso de no tener ninguno asociado.

Una vez todo indicado, con el botón ‘Aceptar’ se cargarán los datos en la Vista actual.

Entre los formatos soportados, se encuentran aquellos que se corresponden con las extensiones:

  • UKOOA-84

  • SPS-RPS

  • P1-90

  • NAV

  • GEOG

  • H19

  • SUK-RUK

  • PTO

¿Y si tenemos ficheros que no están soportados por la extensión gvSeismic?

gvSIG puede cargar estos datos igualmente, dando algún paso más a la metodología presentada en el procedimiento estándar. Atendiendo a la naturaleza de la causa que ha propiciado el error, se pueden extraer dos casos.

El caso más común es que nos encontremos con un fichero soportado por gvSIG, pero que no se reconoce como tal . Vamos a ver a qué puede ser debido y cómo se soluciona.

Cada uno de los formatos soportados tiene sus particularidades. Para poder obtener la información que contienen la extensión dispone de varios parseadores (uno por cada formato), que se encargan de extraer la información. En ocasiones encontraremos que tanto el nombre de las extensión como la información de la cabecera es variable dentro de ficheros de un mismo tipo (por ejemplo, los ficheros UKOOA-84 tienen extensiones .uk, .UK4, .uk84, …). Esta variabilidad puede hacer que en algunos casos no reconozca automáticamente la información.

La solución es muy simple, el primer paso es cerciorarse que es de ese tipo específico, comprobando que los datos tienen la misma estructura y distribución (la cabecera puede ser diferente), es decir, los campos se distribuyen sobre el texto acorde a la especificación.

Un ejemplo en el caso UKOOA-84:

RENGLÓN

COLS

1

NOMBRE DE LA LÍNEA (JUST. A LA IZQUIERDA)

2-17

2

NÚMERO DEL PUNTO (JUST. A LA DERECHA)

18-25

3

LATITUD (GGMMSS.SSS)

26-35

4

LONGITUD (GGMMSS.SSS)

36-46

5

ESTE (UTM)

47-55

6

NORTE (UTM)

56-64

7

PROFUNDIDAD DEL AGUA O ELEVACIÓN

65-70

Si esto se cumple, el siguiente paso sería modificar la extensión del fichero que no es leído por una soportada. Por ejemplo, si el fichero original es ‘nuevofichero.uk2‘ (no reconocido por gvSeismic), se debería cambiar la extensión a una soportada ‘nuevofichero.uk‘. Solucionado.

En un siguiente post complicaremos más la situación…¿y si queremos leer un nuevo formato que no está soportado por la extensión gvSeismic de gvSIG?


Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.2, P1-90, sísmica, UKOOA-84

by Alvaro at February 20, 2015 08:13 AM

Tyler Mitchell

Web Mapping Illustrated – 10 year celebration giveaway [ENDED!]

web-mapping-tyler-mitchell-largeMy O’Reilly, 2005 book

Update: All copies are gone!  If you want Geospatial Desktop or Geospatial Power Tools – go to LocatePress.com – quantity discounts available.  For Web Mapping Illustrated go to Amazon.


 

I’m giving away a couple copies of my circa 2005 classic book.  Details below…  When O’Reilly published Web Mapping Illustrated – Using Open Source GIS Toolkits – nothing like it existed on the market.  It was a gamble but worked out well in the end.

Primarily focused on MapServer, GDAL/OGR and PostGIS, it is a how-to guide for those building web apps that included maps.  That’s right, you couldn’t just use somebody else’s maps all the time – us geographers needed jobs, after all.

To help give you the context of the times, a couple months before the final print date, Google Maps, was released.  I blithely added a reference to their site just in case it became popular.

The book is still selling today and though I haven’t reviewed it in a while, I do believe many of the concepts are still as valid as when it was written.  In fact, it’s even easier to install and configure the apps now due to packaging and distribution options that didn’t exist back then.  Note this was also a year before OSGeo.org’s collaborative efforts started to help popularise the tools further.

In celebration of 10 years of sales I have a couple autographed copies as giveaways to the first two people who don’t mind paying only for the shipping (about USD$8) and who drop me a note expressing their interest.

Additionally, I have some of Gary Sherman’s excellent Geospatial Desktop books as giveaways as well.  Same deal, pay actual shipping cost only from my remote hut in northern Canada.  Just let me know you’d like one of them and I’ll email you the PayPal details.  Sorry, not autographed by Gary, though I was editor and publisher, so could scribble on it for you if desired.

The post Web Mapping Illustrated – 10 year celebration giveaway [ENDED!] appeared first on spatialguru.com.

by Tyler Mitchell at February 20, 2015 07:56 AM

GeoTools Team

GeoTools 13-RC1 Released

The GeoTools community is pleased to announce the availability of GeoTools 13-RC1, the first release candidate of the GeoTools 13 series:

This release is also available from our maven repository, and is made in conjunction with GeoWebCache 1.7-RC1 and GeoServer 2.7-RC1.

We would like your feedback on these new features and improvements:
  • GeoPackage support is now compatible with QGIS and OGR.
  • The rendering engine has been overhauled with two new features:
    • Color-blending has been introduced as both a FeatureTypeStyle and Symbolizer vendorExtension allowing for a range of special effects. Thanks to Cleveland Metro Parks for this improvement.
    • FeatureTypeStyle vendorExtension "firstMatch" will stop at the first rule.
    • Anchor points are now supported.
  • The gt-css module is a brand-new implementation of css style support written in Java. Thanks to Andrea for brining this exciting approach to styling within easy reach of Java developers.
  • A new gt-solr data store is available for working with with Apache Solr 
  • AbstractDataStore is now deprecated - please make plans to migrate to ContentDataStore.
    • There is an extensive ContentDataStore Tutorial to help with your migration. Thanks to Travis for updating the initial tutorial used at FOSS4G.
    • PropertyDataStore has now been ported to use ContentDataStore, and a wide range of issues have been resolved during extensive QA testing (readers, events, transactions). We would like to thank Torben for this extensive work.
  • CSVDataStore has been improved with write access and the ability to work with different kinds of CSV files (including lat/lon and WKT). Thanks to Travis for this work.
  • The gt-wfs client has improved:
    • Better compatibility with MapServer.
    • Extensive work has been done to support WFS 2.0 transacations. Thanks to Niels for this work.
    • The gt-wfs client now supports WFS 2.0 stored queries. Thanks Sampo for this work.
  • Documentation continues to improve, now with a complete function list.
  • For a full list of improvements changes 13-beta, please see the Jira release notes

About GeoTools 13

by Ben Caradoc-Davies (noreply@blogger.com) at February 20, 2015 03:11 AM

Tyler Mitchell

Neo4j Cypher Query for Graph Density Analysis

Graph analysis is all about finding relationships. In this post I show how to compute graph density (a ratio of how well connected relationships in a graph are) using a Cypher query with Neo4j. This is a follow up to the earlier post: SPARQL Query for Graph Density Analysis.

Installing Neo4j Graph Database

In this example we launch Neo4j and enter Cypher commands into the web console.

  1. Neo4j is a java application and requires OracleJDK 7 or OpenJDK 7 to be on your system.
  2. Download the Community Edition of Neo4j.  In my case I grabbed the Unix .tar.gz file and unzipped the files.   Install on Windows may vary.
  3. From command line and within the newlycreatedneo4j-community folder, start the database:
    1. bin/neo4j start
  4. Use web console at: http://localhost:7474 – the top line of the page is a window for entering Cypher commands.
  5. Load sample CSV data using a Cypher command – I cover this in a separate post here.  Be sure the path to the file is the same on your system, matching where you saved the CSV files to.

Quick Visualization

Using the built-in Neo4j graph browser, you can easily see all your relationships as nodes and edges.  For a query, return results that include all the objects:

MATCH (p:Person)
RETURN p

Friends graph sample viewed in Neo4j

Compute Graph Density

Graph Density requires total number of nodes and total number of relationships/edges.  We do them both separately, then pull them together at the end.

Compute the number of unique nodes in the graph

MATCH (p:Person)
RETURN count(p)

count(p)
21
<span class=""><span class="ng-binding">Returned 1 row in 49 ms</span></span>

This tells us that there are 21 people as Subjects in the graph.  (I’m not sure how this differed from the 20 I had in my other post – perhaps part of the header from the CSV came in?)

Therefore, a maximum number of edges between all people would be 21² (we’ll use only 21×20 as a person might not link to themselves in this example).

Compute the number of edges in the graph

Here we only select subjects that are “Person” and only where they have a relationship called “HAS_FRIEND”.

(The “p:”, “r:” and “f:” prefixes act like the “?…” variables references in SPARQL – you set them to whatever you want as a pointer to the data returned from the MATCH statement.)

MATCH (p:Person)-[r:HAS_FRIEND]-(f:Person)
RETURN count(DISTINCT r)

count(DISTINCT r)
57

 When we defined the data from CSV, we set up a relationship that I thought would be just one-way.  But you can see, if you don’t provide the DISTINCT keyword, that you’ll get double the record counts, so I’m assuming it’s treating the relationships as bi-directional.

Total edges is 57.  Do the quick math and see that the ratio is then:

57 / (21 x 20)
= 57 / 420
= 0.136...

Rolling it all together

We can do all this in a single query and get some nice readable results, even though the query looks a bit long.  Note that I snuck in an extra “-1″ to account for that stray record I didn’t account for.

MATCH (p:Person)-[r:HAS_FRIEND]-(f:Person) 
RETURN count(DISTINCT p) as nrNodes, 
 count(DISTINCT r) as nrEdges,
 count(DISTINCT r)/((count(DISTINCT p)-1) * (count(DISTINCT p) - 1.0)) AS graphDensity

nrNodes nrEdges graphDensity
21      57      0.1425

Challenge: Why did I get different results than in the SPARQL query example?

In the earlier post I had only 20 nodes, but in this one got 21.  Can you explain why?

Future Post

What’s your favourite graph analytic?  Let me know and I’ll try it out in the future post.

One of things I have planned is to do some further comparisons between graph analytics in SPARQLverse and other product like Neo4j but with large amounts of data instead of these tiny examples.  What different results would you expect?

The post Neo4j Cypher Query for Graph Density Analysis appeared first on spatialguru.com.

by Tyler Mitchell at February 20, 2015 01:25 AM