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

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

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

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

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

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.

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.

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.

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.

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.

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 .

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.

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

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.

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

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.

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.

Release Highlights

About OSGeo-Live 

• 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

Credits

Sponsoring organisations

• The Open Source Geospatial Foundation provides development & hosting infrastructure for OSGeo-Live and many of the included applications.
• LISAsoft provides sustaining resources and staff toward management and packaging.
• Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support.
• Remote Sensing Laboratory at the National Technical University of Athens, provides hardware resources and development support.
• The DebianGIS and UbuntuGIS teams provide and quality-assure many of the core packages.
• Okeanos is the Greek Academic cloud service (IaaS) which is providing virtualized computing resources for building the OSGeoLive iso images.

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).

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

There 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.

# 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

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

#!/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
)

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/

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

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‘.

La possibilità di definire una etichetta modificabile in funzione della scala si trova all’interno della scheda “etichette definite dall’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.

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.

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.

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’.

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

Si 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).

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

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

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.

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¡¡

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‘.

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

Por 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.

Una 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.

Una funcionalidad de lo más interesante, ¿verdad?

• Course Data
• Lines
• Polygons
• Points
• Rasters

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.

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 …

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”.

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.

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.

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:

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.

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 :

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.

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’.

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

A 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).

En 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.

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

Pulsamos 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.

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.

• 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.

• 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

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

Terminamos 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.

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.

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

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: GRASS GIS 7.0.0 appeared first on Slashgeo.org.

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:

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:

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:

Antipattern 6: Self-signed SSL certificates

Srsly?

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>

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 zip, war, dmg, 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.

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:

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.

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:

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.

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.

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.

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:

Nº	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?

My 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.

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

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

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.