Welcome to Planet OSGeo

October 25, 2014

Tyler Mitchell

Query Vector Data Using a WHERE Clause – ogrinfo

The following is an excerpt from the book: Geospatial Power Tools – Open Source GDAL/OGR Command Line Tools by Tyler Mitchell.  The book is a comprehensive manual as well as a guide to typical data processing workflows, such as the following short sample…

Use SQL Query Syntax with ogrinfo

Use a SQL-style -where clause option to return only the features that meet the expression. In this case, only return the populated places features that meet the criteria of having NAME = ’Shanghai’:

$ ogrinfo 10m_cultural ne_10m_populated_places -where "NAME = 'Shanghai'"

Feature Count: 1 Extent: (-179.589979, -89.982894) - (179.383304, 82.483323) 
 SCALERANK (Integer) = 1 
 NATSCALE (Integer) = 300 
 LABELRANK (Integer) = 1 
 FEATURECLA (String) = Admin-1 capital 
 NAME (String) = Shanghai
 CITYALT (String) = (null) 
 popDiff (Integer) = 1 
 popPerc (Real) = 1.00000000000 
 ls_gross (Integer) = 0 
 POINT (121.434558819820154 31.218398311228327)

Building on the above, you can also query across all available layers, using the -al option and removing the specific layer name. Keep the same -where syntax and it will try to use it on each layer. In cases where a layer does not have the specific attribute, it will tell you, but will continue to process the other layers:

   ERROR 1: 'NAME' not recognised as an available field.

NOTE: More recent versions of ogrinfo appear to not support this and will likely give FAILURE messages instead.

Geospatial Power Tools is 350 pages long – 100 of those pages cover these kinds of workflow topic examples.  Each copy includes a complete (edited!) set of the GDAL/OGR command line documentation as well as the following topics/examples:

Workflow Table of Contents

  1. Report Raster Information – gdalinfo 23
  2. Web Services – Retrieving Rasters (WMS) 29
  3. Report Vector Information – ogrinfo 35
  4. Web Services – Retrieving Vectors (WFS) 45
  5. Translate Rasters – gdal_translate 49
  6. Translate Vectors – ogr2ogr 63
  7. Transform Rasters – gdalwarp 71
  8. Create Raster Overviews – gdaladdo 75
  9. Create Tile Map Structure – gdal2tiles 79
  10. MapServer Raster Tileindex – gdaltindex 85
  11. MapServer Vector Tileindex – ogrtindex 89
  12. Virtual Raster Format – gdalbuildvrt 93
  13. Raster Mosaics – gdal_merge 97

by Tyler Mitchell at October 25, 2014 08:24 AM

October 24, 2014

GeoServer Team

GeoServer 2.5.3 released

The GeoServer team is happy to announce the release of GeoServer 2.5.3. Download bundles are provided (zipwardmg and exe)  along with documentation and extensions.

GeoServer 2.5.3 is the next the stable release of GeoServer and is recommended for production deployment. Thanks to everyone taking part, submitting fixes and new functionality:

  • A new process, PagedUnique, to efficiently grab large amounts of unique values from a layer column
  • Legend preview functionality in the style editor
  • A long awaited fix for poor font rendering when creating transparent map
  • Some fixes in WFS 2.0 joins
  • GeoJSON CRS syntax has been updated to the current valid one (we were using a old legacy one)
  • Some GetFeatureInfo further fixes for complex styles
  • Fix scale computation when the CRS unit of measure is not meters
  • Some WMS 1.3 rendering fixes with image mosaics
  • Avoid invalid reports of leaked connections when using SHAPE-ZIP output format against SQL views whose SQL is no more valid
  • Check the release notes for more details
  • This release is made in conjunction with GeoTools 11.3

About GeoServer 2.5

Articles and resources for GeoServer 2.5 series:


by Andrea Aime at October 24, 2014 01:16 PM

GeoTools Team

GeoTools 11.3 released

The GeoTools community is happy to announce the latest  GeoTools 11.3 download:
This release is also available from our maven repository. This release is made in conjunction with GeoServer 2.5.3.

This is a release of the GeoTools 11 Stable series recommended for production systems. The release schedule now offers 6 months of stable releases followed by six months of maintenance releases.

A few highlights from the GeoTools 11.3-Release Notes:
  • Rendering fixes related to cut geometries/labels at map tile borders
  • Several improvements/fixes to the NetCDF readers
  • Table hints for SQL Server can be specified at the store level, and it's now possible to force SQL Server to use spatial indexes
  • A good set of JDBC related fixes, for joins, multi-geometry tables, spurious error reports against invalid sql views
  • Make sure SortedSimpleFeatureCollection makes full use of the merge-sort sorter and respects the system wide in memory limits (was going straight and fully to disk before)
Thanks to Andrea for this release (GeoSolutions).

About GeoTools 11

Summary of the new features for the GeoTools 11 series:
  • The DataStore API has a new removeSchema method to drop feature types. This new optional feature is currently implemented by the JDBCDataStore family (all spatial database backed stores), other stores will likely throw an UnsupportedOperationException
  • JDBCDataStore now exposes facilities to list, create and destroy indexes on database columns.
  • Ability to create and drop databases from the PostgisNGFactory
  • PostGis data store will now call ST_Simplify when the GEOMETRY_SIMPLIFICATION hint is provided, significantly speeding up loading of complex geometries  (the renderer can perform scale based simplification already, but doing it before sending the data speeds up data retrieval significantly)
  • ImageMosaic can now manage vector footprints for its granules, allowing to filter out no-data or corrupted sections of the imagery
  • All properties in a SLD style can now have a local unit of measure, as opposed to specifying the unit of measure per symbolizer. For example, if you need to have a line width to be 10 meters, its value can now be "10m"
  • Improved handling of data with 3D coordinates in JDBC data stores
  • A number of small improvements to the rendering engine, such as improved raster icon placement resulting in cleaner, less blurry output, improved label grouping, better handling of icons at the border of the map and in general much improved estimation of the buffer area needed to include all symbols in a map (for features that sit outside the map, but whose symbols are big enough to enter it).

by Andrea Aime (noreply@blogger.com) at October 24, 2014 12:48 PM

OSGeo News

OGC honored Jacobs University Professor Peter Baumann with Kenneth D. Gardels Award

by aghisla at October 24, 2014 12:01 PM

GeoSpatial Camptocamp

FOSS4G 2014 : nos présentations et workshops

Cette année, près de 900 personnes étaient réunies pour échanger sur les nouvelles technologies Open Source en Geospatial à FOSS4G.

Présentations et workshops

Camptocamp a donné plusieurs présentations et workshops autour de nos projets. Éric Lemoine a présenté « OpenLayers 3 : a unique mapping library » ainsi que co-présenté deux workshops, l’un sur pgRouting (avec Daniel Kastl) et l’autre sur OpenLayers 3 (avec Tim Schaub et Andreas Hocevar). Jesse Eichar a également exposé son travail sur la version 3 de Mapfish Print.

Vous trouverez ci-dessous, les présentations et les vidéos en ligne :

Ainsi que les workshops :

L’ensemble de ces présentations et workshops ont fait salle comble et nous avons pu remarquer beaucoup d’intérêt autour de ces projets.


Camptocamp a participé à différentes sessions dont celle sur WebGL. Les interactions et les échanges que nous avons eus nous rendent enthousiastes sur les évolutions de cette technologie et son intégration au sein de projets comme OpenLayers 3, sur lequel Camptocamp prévoit de travailler dans les tous prochains mois. Cette intégration va permettre de meilleures performances et des fonctionnalités améliorées. Le prototype que nous avions développé il y a plusieurs mois a permis d’avancer dans cette direction. Nous vous tiendrons au courant de ces évolutions très prochainement.

Nous avons également pu échanger avec les utilisateurs de GeoNetwork sur la nouvelle version de l’interface de l’outil de catalogage. Celle-ci est une refonte complète de l’ancienne version avec Angular, Bootstrap et OpenLayers 3. Cette nouvelle version est grandement appréciée par les utilisateurs : plus intuitive, plus propre, elle apparaîtra par défaut dans la prochaine version de GeoNetwork (version 3).


Chaque année, nous sommes très enthousiasmés par la dynamique autour des FOSS4G auxquels Camptocamp est toujours ravi de participer, via ses projets et ses contributions.

Rendez-vous donc à Séoul pour FOSS4G 2015 du 14 au 19 septembre 2015 !

Cet article FOSS4G 2014 : nos présentations et workshops est apparu en premier sur Camptocamp.

by Yves Jacolin at October 24, 2014 08:51 AM

gvSIG Team

1as Jornadas gvSIG Perú


Mañana, día 25 de octubre de 2014, tendrán lugar las 1as Jornadas gvSIG Perú. Jornadas impulsadas por la Comunidad gvSIG Perú y que en el décimo aniversario de gvSIG se suman a las ya realizadas por otros países de Latinoamérica y Caribe.

En estos diez años se han realizado Jornadas gvSIG, muchas de ellas con periodicidad anual o bianual, en Argentina, Brasil, Chile, México, Paraguay, Uruguay y Venezuela. Ahí ya otras comunidades trabajando en futuras jornadas en países como Ecuador o Bolivia. A todo esto debemos sumar las Jornadas de Latinoamérica y Caribe, que con carácter itinerante representan a la gran comunidad latinoamericana de gvSIG.

Volviendo a las 1as Jornadas gvSIG Perú, la Comunidad ha preparado un interesante programa que incluye un conjunto de ponencias que muestran la aplicabilidad de gvSIG a distintas temática y talleres de formación que permitirán al asistente comenzar su formación en gvSIG.

Y, como todas las jornadas gvSIG, son gratuitas y de libre acceso.

Lo dicho, si vives en Perú…no tienes excusa: Mañana hay jornadas gvSIG

Filed under: community, events, spanish Tagged: Perú

by Alvaro at October 24, 2014 07:54 AM

October 23, 2014

Boundless Blog

Partner Profile: Geospatial Enabling Technologies (GET)

Boundless partners are an important part of spreading the depth and breadth of our software around the world. In this ongoing series, we will be featuring some of our partners and the ways they are expanding the reach of our Spatial IT solutions.

GETGeospatial Enabling Technologies (GET) was established in 2006 with the vision of becoming one of the leaders for Spatial IT solutions and services in Greece as well as more broadly in Europe and Africa. Specializing in the field of geoinformatics, GET provides robust solutions for both the public and private sector.

Since 2010, GET has deployed and supported OpenGeo Suite as part of their projects. From the very beginning, GET held a strong belief that Boundless was the premier provider for commercial open source spatial software. Through its partnership with Boundless and the use of OpenGeo Suite, GET has been able to implement projects for private companies as well as public authorities and government agencies in Greece including the Hellenic Regulatory Authority of Energy and the Greek Ministry of Agriculture. GET has also offered technical support, via the GET SDI Portal, to many public agencies like the Environmental Protection Agency of Athens and the Military Geographic Institute of Ecuador.

Hellenic Regulatory Authority for Energy (RAE)

“With the goal to provide advanced geospatial solutions based on open source, we consider Boundless an essential, valuable partner with whom we could design and implement projects effectively,” said Gabriel Mavrellis of GET.

This successful partnership derives from a relationship where each organization greatly benefits by sharing knowledge, expertise, opportunities, and vision. The developers and project managers at GET deploy projects based on OpenGeo Suite and share their knowledge and expertise with Boundless through the implementation and maintenance of solutions in Greece and abroad.

GET has successfully organized training seminars on OpenGeo Suite to provide Greek engineers and developers with a greater familiarity of the platform and its functions. GET is also a proud contributor to QGIS, providing training and translating a large part of the QGIS user interface into Greek.

If you’d like your company to be considered for our international network of partners, please contact us!

The post Partner Profile: Geospatial Enabling Technologies (GET) appeared first on Boundless.

by Camille Acey at October 23, 2014 03:11 PM


Вышел Revolution R Open

15 октября вышел Revolution R Open — версия языка R от Revolution Analytics, многие годы выпускающих коммерческую версию R, имеющую «встроенную» многопоточночть. Revolution R Open обладает улучшенной производительностью по сравнению со стандартной версией R за счёт использования Intel Math Kernel Libraries (MKL) вместо стандартного R BLAS/LAPACK (при этом не требуется каких-либо дополнительных модификаций вашего кода); полностью совместим с приложениями, пакетами и скриптами, работающими с R 3.1.1; распространяется под лицензией GPLv2.

Revolution R Open доступен для скачивания для следующих платформ:

  • Ubuntu 12.04, 14.04
  • CentOS / Red Hat Enterprise Linux 5.8, 6.5, 7.0
  • OS X Mavericks (10.9)
  • Windows® 7.0 (SP 1), 8.0, 8.1, Windows Server® 2008 R2 (SP1) and 2012

  • Так же имеется экспериментальная поддержка для:

  • OpenSUSE 13.1 (обновлённая сборка Revolution R Open для OpenSUSE от 18 октября у меня работает хорошо)
  • OS X Yosemite (10.10)

  • Здесь можно посмотреть сравнительные тесты (с воспроизводимым кодом) стандартного R и R от Revolution Analytics.

    В частности, у меня такие результаты теста умножения матриц для Revolution R Open:

    > set.seed (1)
    > m <- 10000 > n <-  5000 > A <- matrix (runif (m*n),m,n) > system.time (B <- crossprod(A))
       user  system elapsed 
     14.690   0.141   3.856

    Весьма неплохо! Однако не следует ожидать существенного прироста производительности сторонних пакетов. Я, например, тестировал spatstat: как использовалось только одно ядро, так и используется. Может с другими пакетами повезёт больше )))

    by SS_Rebelious at October 23, 2014 11:28 AM

    gvSIG Team

    Disponibles vídeos webinars del aniversario de gvSIG: fauna y espacios naturales, criminología, modelador de geoprocesos y curso de gestão de bacias

    webinar2Durante este mes de octubre ha habido cuatro seminarios on-line organizados por MundoGEO y realizados por diferentes colaboradores de la Asociación gvSIG. Tres de ellos en español y uno en portugués.

    Ya están disponibles las grabaciones de estos webinars. Para todos aquellos que no pudieron ver los seminarios en directo, aquí tenéis los vídeos:

    Esperamos que este tipo de iniciativas sean de interés para que la comunidad siga formándose en gvSIG. Y, por supuesto, esperamos seguir ofreciéndoos más seminarios en los próximos meses.

    Filed under: events, gvSIG Desktop, portuguese, spanish, training Tagged: bacias, crime, fauna, geoprocesos, modelador, webinar

    by Alvaro at October 23, 2014 10:02 AM

    gvSIG Team

    The second Release Candidate of the gvSIG 2.1 version is now available

    The second gvSIG 2.1 Release Candidate (gvSIG 2.1 RC2) has been released [1].

    During the stabilization process from the first release candidate a lot of errors have been fixed, and some new functionalities have been included in gvSIG 2.1 too, like a new layout with TOC (table of contents), new grid functionalities, memory management at the Preferences menu or the possibility to add layers to the view dragging the file from the file browser directly.

    We encourage you to test this version and send us any errors and suggestions in the users mailing list in English [2] or Spanish [3] or directly in the bugtracker (see interesting links for testers [4]).

    The complete list of the main new features of gvSIG 2.1 can be consulted on [5].

    Thanks for your collaboration.

    [1] http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-2.1/downloads
    [2] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
    [3] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_usuarios
    [4] http://www.gvsig.org/web/docusr/doctesting/interesting-links-for-testers/view?set_language=en
    [5] http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-2.1/notas-de-version/new-features

    Filed under: development, english, gvSIG Desktop, testing

    by Mario at October 23, 2014 07:47 AM

    October 22, 2014

    Even Rouault

    Blending metadata into vector formats

    This post explores a few ideas, and the resulting experiments, I've had recently to put metadata (or arbitrary information) into vector GIS formats that have no provision for them. One typical such format is the good-old Shapefile format. A shapefile generally consists in 3 files, a .shp file that contains the geometries, a .shx that is an index from the shape number to the offset in the .shp file where the geometry is located (to allow fast retrieval by shape ID) and a .dbf file that contains the attributes of each shape.
    Of course, the most simple way of adding metadata would be to but an additional file besides the 3 mentionned ones, but that would not be very challenging (plus the risk of losing it during copy).
    Most implementations require at least those 3 files to be present. Some allow .dbf to be missing (e.g. GDAL/OGR). Some allow .shx to be missing, like OpenJUMP which doesn't read it even if it is available, which is both a feature and a drawback in situations when there are "holes" in the .shp due to editing.

    A basic solution is to add our metadata at the end of one of those 3 files. I've done tests with GDAL/OGR (based on Shapelib), GeoTools 12.0, OpenJUMP 1.7.1 (whose shapefile reader is a forked version of the GeoTools one with changes), proprietary software code-named "GM" and proprietary software "AG"
    .dbf : all 5 implementations are happy with extra content at the end of the file
    .shp : all implementations happy, except OpenJUMP that opens the file, but throws a warning because it tries to interprete the additional bytes as shape.
    .shx : all 5 implementations are happy
    So we have at least 2 possibilities that are rather portable.
    It should be checked how they react in editing use cases, like adding new features to the shapefile. Regarding GDAL/OGR, I can say that it would overwrite the extra content at the end of the .dbf and the .shx. It would let the extra content at the end of the .shp to write the new geometry afterwards.

    What if we want to "link" the metadata per feature in a way where it is preserved if shapes are added ? And for the sake of exploring more possibilities, we will exclude using the data-at-end-of-file track. Interleaving data and metadata is not possible in .dbf since the records are placed consecutively. Same for .shx. In .shp, we can try reserving some space between all geometry records and make sure that the .shx index takes the holes into account. Due to the fact that size and offsets in shapefile are expressed in term of 16 bit words, that extra space must be a multiple of 16 bit too. That works fine for all implementations, except OpenJUMP for the same reason as above. Hum, and what if we incorporate the metadata, not between the encoded geometries, but inside them ? Each geometry record is indeed structured like this :

    Shape Id: 4 bytes
    Record length (number of 16 bit words after that field): 4 bytes
    Record content: (2 * record length) bytes
        Shape Type: 4 bytes
        Variable payload according to shape type

    We can try adding extra payload at the end of record content while still updating record length to take into account. We could have thought that implementations strictly checks that the declared record length is consistant with the shape type, but experimentations (and code inspection on the 3 Open Source implementations) show that, when they check, they check that the record length is at least greater or equal to the minimum expected record length. So this works for the 5 implementations ! At least on a layer with 2D polygons. That should also work for other 2D geometry type. 3D shapes consist in the 2D information, followed by the Z information, and optionaly by the M(eausre) information. M information is sometimes omitted when it is not present (this is the case of the OGR writer). So if we would want to add metadata for 3D shapes, we would have to write dummy M information (writting not-a-number double values is commonly done to indicate that M information is invalid).

    To go back to .dbf file a bit, sometimes the width of fields of string type is larger than strictly needed. The values are left aligned in the field and remaining space is padded with space characters. I've tried to insert a nul character just at the end of the string, and put the extra information afterwards. This works fine for the 3 C/C++ based shapefile readers (GDAL/OGR, G.M., A.G) since nul character is conventionnaly used to terminate a string in C/C++. Unfortunately that does not work with the 2 Java based implementations that do not use that convention : the extra content is displayed after the field content.

    As we have started exploring modifying the data itself, let's return to .shp file. One thing to consider is that coordinates in shapefiles are stored as double precision floating point numbers, stored on 64 bits using the IEEE-754 binary representation. Such numbers are decomposed like the following : 1 bit for the sign of the value, 11 bits for the exponent and its sign and 52 bits for the mantissa. The mantissa is where the significand precision of the number is stored. How big is that ? Let's go back to geography a bit. The Earth has rougly a circonference of 40 000 km. If we want to map features with a precision of 1 cm, we need 40 000 000 / 0.01 = 4 billion distinct numbers. 4 billion fits conveniently on a 32 bit integer (and OpenStreetMap .pbf optimized format store coordinates on 32 bit integers based on that observation). So 52 bits allow 2^(52-32)=2^20, roughly 1 million more numbers, i.e. a precision of 10^-8 meters = 10 nanometers ! We could almost map every molecule located on the Earth surface !
    It is consequently reasonable to borrow the 16 least significant bits from the mantissa for other use. Said differently for every 2D point/vertex, we can get back 4 bytes without any noticeable loss of precision. Depending on the shape complexity, this might be not big enough to store per-feature metadata. But on a typical shapefile, if we spead the metadata over the features, we can certainly store useful content. And the really great news is that this metadata would be preserved naturally in most format conversions (at least with GDAL/OGR whose internal geometry representation also uses 64-bit floating point numbers, and probably most other geometry engines), and for formats like Spatialite or GeoPackage that also use 64-bit floating point numbers. However, one must be aware than any other operation like rescaling or reprojection would completely change the least significant bits and erase our metadata.

    Admitedly this is not a new idea. People have explored similar ideas for digital watermarking and more generally steganography, typically used to embed copyright information or source tracking (i.e. you generate a slightly different dataset for each customer, hence if a copy is then available for download, you can identify the origin of the leak), generally in a not noticeable way. Using least significant bits is the very basic technique, that can be circumvented easily by just zeroing them or adding noise. More advanced technique operate in the spectral domain, like DCT (Discrete Cosine Transform), DFT (Discrete Fourier Transform) or DWT (Discrete Wavelet Tranform). Some techniques have been specifically designed for GIS data, using topological properties for example. The common target of those techniques is to have robustness against attempts of removing the watermark from the signal, at the expense of a reduced bandwith for the inserted information. But for regular metadata, we do not need such guarantee and the use of least-significant bits might be good enough and easily implemented.

    Any other ideas ? Sure...

    For polygons, the shapefile specification states that the vertices of the outer ring must be listed in clockwise order. But it does not specify which vertex of the outline must be the first one. Let's consider that the top-most vertex of the polygon is numbered 0 (if there are several vertices with the same y coordinate, let's take the one of them with the minimum x), the following vertex in clockwise order is 1, etc... If our polygon has 16 vertices, and we serialize it starting at vertex 11, we have coded the 11 number. Combined with information of following polygons, we can build a longer message. This idea could only work in practice for shapefiles of complex/dense enough polygons. If every polygon has 256 vertex, we can encode log2(256)=8 bits per polygon. More generally, for a polygon with N vertex, we could encode log2(N) bits (rounded to inferior integer). So we need also at least hundreds or thousands of polygons of that complexity to be able to encode something useful. The advantage of this technique is that it is robust to rescaling, and probably most reprojections (at least the one that globally preserve the appearance of shapes), provided that the shapes are rewritten in the same order as in the original data.
    That technique could also be adapted for lines. Let's consider a line made of (V1,V2,....Vn). We can for example simply build a multi-polyline of 2 parts (V1,...Vi) and (Vi,....,VN) that will visually looks like the original line and will encode for the i value. The increase in binary encoding would be modest (4+8+8=20 extra bytes).

    Another technique might be to use repeated vertices. Let's consider a line or a polygon: if while listing consecutive vertices, they are repeated, this would encode a 1 value. Otherwise 0. For example, if a line is made of the sequence of vertices (V1,V1,V2,V3,V4,V4,V5,V5,V6), it would be equivalent to binary number 100110. So we could encode as many bits as vertices in the geometry. If needed, we can also use more repetitions to encode more bits. For one bit per vertex, on average such a technique would increase shapefile size by 50% (because on average, half of bits in a message are 1). It would preserve metadata perfectly for all coordinate transformations (geometry engines generally operate on vertices separately). But not to operations that would remove duplicated vertices.

    Finally, here's another idea, conceptually close to the one based on the starting vertex. Excluding implementations that don't rely on the .shx (I've no prejudice against such one ! Keep on good work folks !), we could use the order of shapes in the .shp to encode information. Traditionnaly, feature 1 appears first in the .shp, followed by feature 2, etc... But we could re-order the shapes as we wish, provided we make the .shx point to the right offset in the .shp. If we have N shapes, there are N! (factorial(N) = N*(N-1)*(N-2)*...2*1) ways of ordering them. So for N shapes, we can encode log2(N!) bits. In practice for 10 shapes, that is 21 bits. For 100 shapes, 524 bits. For 1000 shapes, 8529 bits. And for 10000, 118458. Advantages: works for all geometry types, no increase in file size. Inconvenients: possibly less performant sequential reading because of apparently random seeking within the .shp, doesn't resist to file conversion.

    I've not mentionned it, but for nearly all mentionned techniques, especially the last ones, we would need to reserve a few bits to insert a CRC or any other integrity mechanism, so as to make sure that we think is metadata really is. And all them could be potentially combined !

    by Even Rouault (noreply@blogger.com) at October 22, 2014 09:50 PM

    gvSIG Team

    Open Planet Especial nº1: 10 años gvSIG “gvSIG: no sólo ciencia. Recopilatorio de escritos”

    Estamos de aniversario. Una década en la que el proyecto gvSIG ha ido construyendo su camino.  Esta efemérides está siendo celebrada de muchas maneras por la Comunidad. A todos esos eventos y actividades queremos unir una recopilación de escritos que durante estos 10 años han aparecido aquí y allá. Escritos que son un reflejo de cómo hemos ido avanzando en el pensamiento de gvSIG, en la interpretación de la realidad desde un proyecto de geomática libre.

    Textos que en ocasiones, como decía Bertolt Brecht, en estos tiempos han de defender lo evidente: que el conocimiento debe ser patrimonio de la humanidad y no de corporaciones, que la colaboración y la solidaridad son valores fundamentales sobre los que construir los modelos de negocio.

    En gran parte somos recuerdos y recordar lo que hemos defendido y argumentado en cada momento nos permite también definir lo que somos a hoy día. Esta recopilación nos permite afirmar que detrás nuestro no solo queda un camino recorrido. Las bases de lo que seremos también están ahí.

    Os dejo con la introducción del recopilatorio que espero que os anime a todos a descargarlo e ir buceando en su lectura:

    gvSIG es algo más que ciencia. Economía Ciencia y Política son disciplinas que consideramos relacionadas entre sí y no logramos entenderlas plenamente si no atendemos a la existencia de estas relaciones. Esta idea es recurrente en gvSIG; siempre que podemos la proclamamos.
    Quizás, de todas las componentes de gvSIG la que menos se conozca sea la que explique como se ha construido la organización gvSIG, su pensamiento. Este recopilatorio pretende ayudar a explicar este proceso.
    El presente documento es un recopilatorio de algunos escritos que han ido ayudando a crear gvSIG. Escritos de blogs, jornadas o escritos internos. Muchos de ellos van acompañados de un párrafo que ayude a explicar el porqué y los objetivos de cada uno de los escritos. No se trata de un trabajo exhaustivo, pero sí que pensamos que le puede resultar interesante a quien desee conocer los aspectos no técnicos de gvSIG.
    Se presentan ordenados por años, añadiendo al final un anexo con otros documentos.
    Esperando que os resulte de interés y que puedan servir como una herramienta para la transformación de un futuro que está por escribir.

    Atreveros a soñar y carpe diem

    Descarga: http://downloads.gvsig.org/download/documents/books/Recopilatorio_10.pdf

    Filed under: gvSIG Association, opinion, spanish

    by Alvaro at October 22, 2014 11:46 AM

    GeoSpatial Camptocamp

    Journée ASIT VD : rencontrez les acteurs de la géoinformation !

    Le 28 octobre, Camptocamp vous donne rendez-vous à la journée de l’ASIT VD, l’Association pour le Système d’Information du Territoire Vaudois, qui aura lieu au Swiss Tech Convention Center à Lausanne.

    Depuis 20 ans, l’ASIT VD facilite l’accès aux géodonnées sur le territoire vaudois et regroupe près de 300 membres autour d’un partenariat public-privé original. A cette occasion, sociétés de services, administrations publiques, écoles et associations, vous présentent leurs produits, activités et nouveautés. Le programme est disponible ici.

    L’équipe Geospatial Solutions de Camptocamp vous accueillera sur son stand et vous présentera démos, formations, et nouveautés. Que vous soyez architecte, municipal, ingénieur ou technicien, venez discuter avec nous de vos projets SIG !

    Cet article Journée ASIT VD : rencontrez les acteurs de la géoinformation ! est apparu en premier sur Camptocamp.

    by camptocamp at October 22, 2014 09:26 AM

    October 21, 2014

    Boundless Blog

    QGIS Compared: Visualization

    Gretchen PetersonAny GIS professional who’s been paying attention to the professional chatter in recent years will be wondering about QGIS and whether or not it might meet some or all of their needs. QGIS is open source, similar to proprietary GIS software, runs on a variety of operating systems, and has been steadily improving since its debut in 2002. With easy-to-install packages, OpenGeo Suite integration, and reliable support offerings, we obviously see QGIS as a viable alternative to proprietary desktop GIS software such as Esri’s ArcGIS for Desktop.

    But will it work for you? The short answer is: most likely yes for visualization of most formats of spatial data, probably for analysis of raster and vector data, probably for geographic data editing, and probably for cartographic publishing.  Those are all very subjective assertions based on my personal experience using QGIS for the past seven months but I have been using proprietary GIS for over fourteen years as an analyst and cartographer and have written a couple of books on the subject.

    By all means give QGIS a try: download and install it, drag-and-drop some data into it, and give it a spin. This is definitely a good time to evaluate it and consider adopting it across your organization.

    Visualizing spatial data in QGIS

    In this first post, I’m going to focus on visualizing spatial data in QGIS. These basic functions are straightforward and easy to do in QGIS:

    1. adding datasets

    2. moving datasets up and down in the layer hierarchy

    3. zooming around the map

    4. selecting features based on simple point-and-click

    5. selecting features based on complex selection criteria

    6. viewing attributes

    7. creating graduated color schemes


    Strength: Versatile and efficient format support

    In fact, QGIS is an effective means of viewing and exploring spatial data of almost any type. If you have complex data, you might be interested to hear that the newest release of QGIS boasts very fast, multi-threaded, rendering of spatial data that may even make it faster than leading competitors. When I began creating the map shown above, I accidentally added all of the Natural Earth 1:10m Cultural Vectors in triplicate to the project, causing some minor heart-palpitations as I realized it was going to try to render close to 100 vector layers all at once. However, my fears were unfounded as it took only a few seconds for them to render once they were all added. In the realm of visualization, it does most of the other tasks that a GIS professional would expect as well, including support for custom symbol sets (in SVG format). Adding GeoJSON data is simple, just drag a geojson file onto the Layers list. Here, we show a portion of James Fee’s GeoJSON repository of baseball stadiums:


    Mixed results: Raster visualization

    That said, raster visualization can yield unexpected results depending on what is desired. Some raster datasets have tables that associate bands with RGB values such that specific cell-types are rendered certain colors. Often, landcover datasets will have this kind of structure so that, for example, the raster is rendered with blue for water, green for grass, white for ice, and so on. Unfortunately, QGIS doesn’t yet support rendering based on associated table files for rasters. Another slight irritation is the continuing use of binary ARC/INFO GRID formats by some agencies who distribute raster data to the public. If you have one of these datasets, QGIS can open it but you must point to the w001001.adf file using the raster data import button.

    Mixed results: On-the-fly reprojection

    One of the most important ways to make GIS user-friendly is to support on-the-fly projection. I still remember when projecting on-the-fly became a part of the software that I used to use. It was the end of 1999, and life was so much easier when multiple datasets from multiple agencies in multiple projections could all be jammed together into a single project, producing a map where all the data layers were in the correct projected space. This was because reprojecting not only added extra steps requiring you to reproject everything into a common coordinate system even if all you wanted to do was visualize the data, it also meant maintaining multiple copies of the same dataset, which contributed to folder clutter and using up of valuable disk space. QGIS supports reprojection on-the-fly but it is an option that must be set in the project properties dialog. Some glitches with projections still seem to occur from time to time. Zooming in, for example, sometimes causes the map to zoom to a different place than expected. However, this unexpected behavior is inconsistent, not a showstopper, and may be fixed soon.


    Hidden gem: Context

    The other important aspect of visualizing data is having enough underlying context for the data. Country boundaries, city labels, roads, oceans, and other standard map data are crucial. Proprietary GIS software generally contains basemap layers that can easily be turned on and off to support visualization in this manner. QGIS also has this capability, in the form of the OpenLayers plugin, which serves up Google, OpenStreetMap, Bing, and Yahoo basemaps at the click of a button. The OpenLayers plugin is free and installs just like any other QGIS plugin—you search for it in the Plugins menu, press “install,” and make your basemap choice in the Web menu.



    While QGIS may need a small amount of improvement when it comes to raster visualization and on-the-fly projection, these aren’t hindrances to a typical visualization workflow and are only mentioned here out of respect for a fair and balanced assessment. By and large, my testing has convinced me that the robust visualization capabilities that QGIS offers provide more than enough impetus for many organizations to make the switch to QGIS. In later posts, I’ll discuss how QGIS performs with respect to analysis, editing, and cartography.

    The post QGIS Compared: Visualization appeared first on Boundless.

    by Gretchen Peterson at October 21, 2014 03:22 PM

    October 20, 2014

    Peter Batty

    Reaction to Apple Maps announcement

    What they announced As predicted by the entire world, Apple announced their new maps application today as part of iOS 6. You can see the keynote presentation of the video here, and Apple's summary information about the Maps app here. Overall my predictions from last week were pretty spot on :) ... they announced that it would have turn by turn directions with voice guidance, real time

    by Peter Batty (noreply@blogger.com) at October 20, 2014 05:16 PM

    GeoTools Team

    GeoTools 12.0 Released

    The GeoTools team is happy to announce the release of version 12.0.
    GeoTools now requires Java 7 and this is the first release tested with OpenJDK! Please ensure you are using JDK 1.7 or newer for GeoTools 12. Both Oracle Java 7 and OpenJDK 7 are supported, tested, release targets.

    There are a number of new features in this release:
    • circular strings are now supported in Oracle data stores, thanks to GeoSolutions.it for the work.
    • The content datastore tutorial was updated by Jody and tested out by the FOSS4G workshop participants.
    • GeoTools Filter interfaces have been simplified (cleaning up technical debt from GeoTools 2.3)
    • The new wfs-ng datastore is now available as a drop in replacement for the old WFS datastore, The new store provides much better support for axis orders with servers that don't know what they are doing. In order to make wfs-ng a drop-in replacement (and respond to the same connection parameters) you are limited to only using one implementation of gt-wfs-ng or gt-wfs plugins in your application at a time.
    • New advanced raster reprojection, a lot of work has been put into improving the raster reprojection story for glitches around the date line and polar regions. To enable these options use the following rendering hints:
      rendererParams.put(StreamingRenderer.ADVANCED_PROJECTION_HANDLING_KEY, true);
      rendererParams.put(StreamingRenderer.CONTINUOUS_MAP_WRAPPING, true);
    This release is made in conjunction with GeoServer 2.6.0 and is available from the OSGeo maven repository.

    About GeoTools 12

    by Ian Turton (noreply@blogger.com) at October 20, 2014 01:46 PM

    Margherita Di Leo

    Call For papers Geospatial devroom @FOSDEM

    Please forward!

    FOSDEM is a free open source event bringing together about 5000 developers in Brussels, Belgium. The goal is to provide open source software developers and communities a place to meet at. The next edition will take place the weekend 31/1 -> 1/2/2015. This year for the first time there will be a geospatial devroom on Sunday 1/2/2015!

    Geospatial technology becomes more and more part of mainstream IT. The idea is to bring together people with different backgrounds to better explain and understand the opportunities Geospatial can offer. This devroom will host topics explaining the state of the art of geospatial technology, and how it can be used amongst other projects.

    The geospatial devroom is the place to talk about open, geo-related data and software and their ecosystem. This includes standards and tools, e.g. for spatial databases, and online mapping, geospatial services, used for collecting, storing, delivering, analysing, and visualizing puposes. Typical topics that will be covered are:

    • Web and desktop GIS applications
    • Interoperable geospatial web services and specifications
    • Collection of data using sensors/drones/satellites
    • Open hardware for geospatial applications
    • Geo-analytic algorithms/libraries
    • Geospatial extensions for classical databases (indexes, operations)
    • Dedicated databases


    Are you thrilled to present your work to other open source developers? Would you like to run a discussion? Any other ideas? Please submit your proposal at the Pentabarf event planning tool at:

    When submitting your talk in Pentabarf, make sure to select the 'Geospatial devroom' as  'Track'. Please specify in the notes if you prefer for your presentation a short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes presentation + discussion).

    The DEADLINE for submissions is **1st December 2014**

    Should you have any questions, please do not hesitate to get in touch with the organisers of the devroom at fosdem-geospatial@gisky.be!

    Johan Van de Wauw
    Margherita Di Leo
    Astrid Emde
    Anne Ghisla
    Julien Fastré
    Martin Hammitzsch
    Andy Petrella 
    Dirk Frigne
    Gael Musquet

    by Margherita Di Leo (noreply@blogger.com) at October 20, 2014 12:21 PM

    Jackie Ng

    GovHack 2014 post-mortem

    UPDATE 20 October 2014: After a bungle on my Amazon EC2 instance, the demo URL on our hackerspace project page is no longer active. I've resurrected this site on my demo server on Rackspace here. Ignore the link on the hackerspace page until that page gets updated (if it will get updated, because I can't do it)

    Earlier this month, I attended the GovHack 2014 hackathon, along with thousands of other fellow hackers all across the country. This was my first GovHack, but not my first hackathon. My previous hackathon was RHoK and having no idea how GovHack would turn out, I entered the GovHack event with a RHoK-based mindset of how I would expect this hackathon to turn out.

    Bad idea.

    I learned very quickly there was a major difference between RHoK and GovHack. Going into RHoK, you have an idea about what solutions you will get to hack on over the weekend as problem owners are present to pitch their ideas to the audience of prospective hackers. With GovHack, you need an idea about what solution you want to hack on over the weekend, all they were going to provide was the various open data and APIs. What on earth are we going to build?

    So after losing nearly half the weekend to analysis paralysis, our team (named CreativeDrought, wonder why?) agreed with my suggestion of just building a MapGuide-based mashup of various open datasets, most notably, the VicRoads Crash Stats dataset and related transportation data. I obviously knew MapGuide inside-and-out and its capabilities to have a level of confidence that with the remaining weekend we should still be able to crank out some sort of workable solution. At the very least, we'd have a functional interactive map with some open data on it.

    And that's the story of our CrashTest solution in a nutshell. It's a Fusion application, packed to the gills with out-of-the-box functionality from its rich array of widgets (including Google StreetView integration). The main objective of this solution was to allow users to view and analyse crash data, sliced and diced along various age, gender, vehicle type and various socio-economic parameters.

    MapGuide's rich out-of-the-box capabilities, Maestro's rapid authoring functionality and GDAL/OGR's ubiquitous data support greatly helped us. I knew with this trio of tools, that we could assemble an application together in the remaining day and a bit left that we had to actually "hack" on something.

    Sadly, we only got as far as putting the data on the map for the most part. Our team spent more time frantically trying to massage various datasets via ogr2ogr/Excel/GoogleDocs into something more usable than actually writing lines of code! Seriously VicRoads? Pseudo-AMG? Thank goodness I found the necessary proj4 string for this cryptic coordinate system so that we could re-project a fair chunk of the VicRoads spatial data into a coordinate system that better reflects the world we want to mash this data up with!

    Still, our "solution" should hopefully still open up a lot of "what if" scenarios. Imagine looking at a cluster of accident events, not being able to ascertain any real patterns or correlation and so you then fire up the StreetView widget and lo-and-behold, Google StreetView providing additional insights that a birds-eye view could not. Also imagine the various reporting and number crunching possibilities that are available by tapping into the MapGuide API. Imagine what other useful information you could derive if we had more time to put up additional useful datasets. We didn't get very far on any of the above ideas, so just imagine such possibilities if you will :)

    So here's our entry page if you want to have a look. It includes a working demo URL to a Amazon EC2 hosted instance of MapGuide. Getting acquainted with Amazon Web Services and putting MapGuide up there was an interesting exercise and much easier than I thought it would be, though I didn't have enough time to use the AWS credits I redeemed over the weekend to momentarily lift this demo site out of the free usage tier range performance-wise. Still, the site seems to perform respectably well on the free usage tier.

    Also on that page is a link to a short video where we talk about the hack. Please excuse the sloppy editing, it was obviously recorded in haste in a race against time. Like the solution and/or the possibilities it can offer? Be sure to vote on our entry page.

    Despite the initial setbacks, I was happy with what we produced given the severely depleted time constraints imposed on us. I think we got some nice feedback demo-ing CrashTest in person at the post-mortem event several days later, which is always good to hear. Good job team!

    So what do I think could be improved with GovHack?
    • Have a list of hack ideas (by participants who actually have some ideas) up some time before the hackathon starts. This would facilitate team building, letting participants with the skills, but without ideas easily gravitate towards people/teams with the ideas.
    • The mandatory video requirement for each hack entry just doesn't work in its current form. Asking teams to produce their own videos puts lots of unnecessary stress on teams, who not only have to come up with the content for their video, but have to also deal with the logistics of producing said video. I would strongly prefer that teams who can/want to make their own video do so, while other teams can just do a <= 3 minute presentation and have that be recorded by the GovHack organisers. Presentations also lets teams find out how other teams fared over the weekend. While everyone else in the ThoughtWorks Melbourne office was counting down to the end of the hackathon, I was still frantically trying to record my lines and trying not to flub them! I raided the office fridge for whatever free booze that remained just to calm myself down afterwards. I don't want to be in that situation ever again!
    • Finally, the data itself. So many "spatial" datasets as CSV files! So many datasets with no coordinates, but have addresses, horribly formatted addresses, adding even more hoops to geocode them. KML/KMZ may be a decent consumer format, but it is a terrible data source format. If ogr2ogr can't convert your dataset, and requires a manual intervention of QGIS to fix it, then perhaps it's better to use a different spatial data format. Despite my loathing of its limitations, SHP files would've been heavily preferred for all of the above cases. I've made my thoughts known on the GovHack DataRater about the quality of some of these datasets we had to deal with and got plenty of imaginary ponies in the process.
    Despite the above points, the event as a whole was a lot of fun. Thanks to the team (Jackie and Felicity) for your data wrangling and video production efforts.

    Also thanks to Jordan Wilson-Otto and his flickr photostream where I was able to get some of these photos for this particular post.

    Would I be interested in attending the 2015 edition of GovHack? Given I am now armed with 20/20 hindsight, yes I would!

    by Jackie Ng (noreply@blogger.com) at October 20, 2014 10:51 AM

    Petr Pridal

    IIIF for images in culture heritage

    Online scans of culture heritage documents, such as old maps, books, photographs, etc. are being published by the galleries, libraries, archives and museums.  Until now there was no official standardisation activity in this area. This is now changing with the International Image Interoperability Framework IIIF (http://iiif.io/), which enables easy access to large raster images across institutions.

    We are happy to announce a new Open Source IIIF viewer, with several useful features: 

    - Rotation on client side  - pinch with fingers, Alt-Shift drag with the mouse
    - Drawing tools - polygons, lines, markers - used to annotate parts of the pictures
    - Color adjustments - saturation, lightness, etc

    The viewer is pure Java Script, mobile optimised with almost native feeling for zoom and powered by OpenLayers V3 open-source project, where we are co-developers (see blog post).

    Feel free to try at: http://klokantech.github.io/iiifviewer/

    Source codes are available on GitHub: https://github.com/klokantech/iiifviewer/

    This viewer is another important part of the mosaic of open source tools for publishing of large images and maps. Together with high-performance open-source JPEG2000 image server can be used to serve thousands of users in a very fast and efficient way.

    The mentioned server providing IIIF endpoint for the JPEG2000 images was developed and released by Klokan Technologies in cooperation with the National Library of Austria and their Google Books scanning project, the Austrian Books in 2013. The documentation is available at: https://github.com/klokantech/iiifserver/

    Server software runs under Linux, Mac OS X as well as Windows. There is even an easy to use installer.  It is powered by IIPImage server and our code has been recently refactored and merged back to the main IIPImage repository.

    Support and maintenance for installation of this open-source software can be provided by Klokan as well as the access to JPEG2000 Kakadu license.

    by Petr Pridal (noreply@blogger.com) at October 20, 2014 08:59 AM

    October 19, 2014

    Sean Gillies

    Unix style spatial ETL with fio cat, collect, and load

    Unix style spatial ETL with fio cat, collect, and load

    In Fiona 1.4.0 I added a fio-cat command to the CLI which works much UNIX cat. It opens one or more vector datastets, concatenating their features and printing them to stdout as a sequence of GeoJSON features.

    $ fio cat docs/data/test_uk.shp | head -n 2
    {"geometry": {"coordinates": [...], "type": "Polygon"}, "id": "0", "properties": {"AREA": 244820.0, "CAT": 232.0, "CNTRY_NAME": "United Kingdom", "FIPS_CNTRY": "UK", "POP_CNTRY": 60270708.0}, "type": "Feature"}
    {"geometry": {"coordinates": [...], "type": "Polygon"}, "id": "1", "properties": {"AREA": 244820.0, "CAT": 232.0, "CNTRY_NAME": "United Kingdom", "FIPS_CNTRY": "UK", "POP_CNTRY": 60270708.0}, "type": "Feature"}

    I’ve replaced most of the coordinates with ellipses to save space in the code block above, something I’ll continue to do in examples below.

    I said that fio-cat concatenates features of multiple files and you can see this by using wc -l.

    $ fio cat docs/data/test_uk.shp | wc -l
    $ fio cat docs/data/test_uk.shp docs/data/test_uk.shp | wc -l

    If you look closely at the output, you’ll see that every GeoJSON feature is a standalone text and each is preceded by an ASCII RS (0x1E) control character. These allow you to cat pretty-printed GeoJSON (using the --indent option) containing newlines that can still be understood as a sequence of texts by other programs. Software like Python’s json module and Node’s underscore-cli will trip over unstripped RS, so you can disable the RS control characters and emit LF delimited sequences of GeoJSON (with no option to pretty print, of course) using --x-json-seq-no-rs.

    To complement fio-cat I’ve written fio-load and fio-collect. They read features from a sequence (RS or LF delimited) and respectively write them to a formatted vector file (such as a Shapefile) or print them as a GeoJSON feature collection.

    Here’s an example of using fio-cat and load together. You should tell fio-load what coordinate reference system to use when writing the output file because that information isn’t carried in the GeoJSON features written by fio-cat.

    $ fio cat docs/data/test_uk.shp \
    | fio load --driver Shapefile --dst_crs EPSG:4326 /tmp/test_uk.shp
    $ ls -l /tmp/test_uk.*
    -rw-r--r--  1 seang  wheel     10 Oct  5 10:09 /tmp/test_uk.cpg
    -rw-r--r--  1 seang  wheel  11377 Oct  5 10:09 /tmp/test_uk.dbf
    -rw-r--r--  1 seang  wheel    143 Oct  5 10:09 /tmp/test_uk.prj
    -rw-r--r--  1 seang  wheel  65156 Oct  5 10:09 /tmp/test_uk.shp
    -rw-r--r--  1 seang  wheel    484 Oct  5 10:09 /tmp/test_uk.shx

    And here’s one of fio-cat and collect.

    $ fio cat docs/data/test_uk.shp | fio collect --indent 4 | head
        "features": [
                "geometry": {
                    "coordinates": [
    $ fio cat docs/data/test_uk.shp | fio collect --indent 4 | tail
                    "CAT": 232.0,
                    "CNTRY_NAME": "United Kingdom",
                    "FIPS_CNTRY": "UK",
                    "POP_CNTRY": 60270708.0
                "type": "Feature"
        "type": "FeatureCollection"

    Does it look like I’ve simply reinvented ogr2ogr? The difference is that with fio-cat and fio-load there’s space in between for programs that process features. The programs could be written in any language. They might use Shapely, they might use Turf. The only requirement is that they read and write sequences of GeoJSON features using stdin and stdout. A nice property of programs like these is that you can sometimes parallelize them cheaply using GNU parallel.

    The fio-buffer program (unreleased) in the example below uses Shapely to calculate a 100 km buffer around features (in Web Mercator, I know!). Parallel doesn’t help in this example because the sequence of features from fio-cat is fairly small, but I want to show you how to tell parallel to watch for RS as a record separator.

    $ fio cat docs/data/test_uk.shp --dst_crs EPSG:3857 \
    > | parallel --pipe --recstart '\x1E' fio buffer 1E+5 \
    > | fio collect --src_crs EPSG:3857 \
    > | geojsonio

    Here’s the result. Unix pipelines, still awesome at the age of 41!

    The other point of this post is that, with the JSON Text Sequence draft apparently going to publication, sequences of GeoJSON features not collected into a GeoJSON feature collection are very close to being a real thing that developers should be supporting.

    by Sean Gillies at October 19, 2014 02:46 PM

    Jackie Ng

    MapGuide tidbits: MapGuide Server daemon doesn't start after reboot

    This one will be short and sweet.

    If you have rebooted your Linux server, and for some reason you can no longer start the MapGuide Server as a daemon. You should check that the /var/lock/mgserver directory exists and create it if it doesn't.

    The mgserver process will try to create and lock a file in this directory and will bail out if it can't. This directory is cleared when the Linux server is restarted (at least in my observations). None of the wrapper scripts (mgserver.sh or mgserverd.sh) actually check if the directory exists, so they blindly proceed as though this directory existed.

    We'll patch the mgserverd.sh script to create this directory if it doesn't exist before running the mgserver daemon. In the meantime, you can edit the mgserverd.sh file in the MapGuide Linux installation yourself to create the /var/lock/mgserver directory before running the mgserver process.

    by Jackie Ng (noreply@blogger.com) at October 19, 2014 01:33 PM

    Bjorn Sandvik

    Creating 3D terrains with Cesium

    Previously, I’ve used three.js to create 3D terrain maps in the browser (1, 2, 3, 4, 5, 6). It worked great for smaller areas, but three.js doesn’t have built-in support for tiling and advanced LOD algorithms needed to render large terrains. So I decided to take Cesium for a spin.

    Cesium is a JavaScript library for creating 3D globes and 2D maps in the browser without a plugin. Like three.js, it uses WebGL for hardware-accelerated graphics. Cesium allows you to add your own terrain data, and this blog post will show you how.

    Compared to the dying Google Earth plugin, it's quite complicated to get started with Cesium. The source code is well documented and the live coding Sandcastle is great, but there is a lack of tutorials and my development slows down when I have to deal with a lot of math.

    That said, I was able to create an app streaming my own terrain and imagery with a few lines of code. There is also WebGL Earth, a wrapper around Cesium giving you an API similar to well-known Leaflet. I expect to see more functions or wrappers to make stuff like camera positioning easier in the future.

    How can you add your own terrain data to Cesium? 

    First, you need to check if you really need it. You have the option to stream high-resolution terrain data directly from the servers at AGI. It's free to use on public sites under the terms of use. If you want to host the terrain data on your own servers, AGI provides a commercial product - the STK Terrain Server. Give it a try, if you have a budget!

    I was looking for an open source solution, and found out that Cesium supports two terrain formats:
    1. heightmap
    2. quantized-mesh
    The tiled heightmap format is similar to the one I used for three.js. Each tile contains 65 x 65 height values, which overlap their neighbors at their edges to create a seamless terrain. Cesium translates the heightmap tiles into a uniform triangle mesh, as I did in three.js. The downside of this format is the uniform grid, you use the same amount of data to represent both flat and hilly terrain.

    The regular terrain mesh made from heightmap tiles. 

    The quantized-mesh format follows the same tile structure as heightmap tiles, but each tile is better optimised for large-scale terrain rendering. Instead of creating a dense, uniform triangle mesh in the browser, an irregular triangle mesh is pre-rendered for each tile. It's a better representation of the landscape, having less detail in flat areas while increasing the density in steep terrain. The mesh terrain is also more memory efficient and renders faster.

    The irregular terrain mesh from quantized-mesh tiles. Larger triangles have less height variation. 

    Unfortunately, I haven't found any open source tools to create tiles in the quantized-mesh format - please notify me if you know how to do it!

    You can generate heightmap tiles with Cesium Terrain Builder, a great command-line utility by Homme Zwaagstra at the GeoData Institute, University of Southampton.

    I'm using the same elevation data as I did for my three.js maps, but this time in full 10 meter resolution. I'm just clipping the data to my focus area (Jotunheimen) using EPSG:4326, the World Geodetic System (WGS 84).

    gdalwarp -t_srs EPSG:4326 -te 7.2 60.9 9.0 61.7 -co compress=lzw -r bilinear jotunheimen.vrt jotunheimen.tif

    I went for the easy option, and installed Cesium Terrain Builder using the Docker image. First I installed Docker via Homebrew.  I was not able to mount my hard drive with this method, so I downloaded the elevation data from my public Dropbox folder:

    wget https://dl.dropboxusercontent.com/u/1234567/jotunheimen.tif

    I used the ctb-tile command to generate the tileset:

    ctb-tile --output-dir ./tiles jotunheimen.tif

    The command returned 65 000 tiles down to zoom level 15. I compressed the tiles into one file:

    tar cvzf tiles.tar.gz tiles

    and used the Dropbox uploader to get the tiles back to my hard drive:

    ./dropbox_uploader.sh upload tiles.tar.gz tiles.tar.gz

    So I got 65 000 terrain tiles on my server, how can I see the beauty in Cesium? It required some extra work:
    1. First I had to add a missing top level tile that Cesium was expecting. 
    2. Cesium was also looking for a layer.json file which I had to create:

        "tilejson": "2.1.0",
        "format": "heightmap-1.0",
        "version": "1.0.0",
        "scheme": "tms",
        "tiles": ["{z}/{x}/{y}.terrain?v={version}"]

    3. Lastly, I added a .htaccess file to support CORS and gzipped terrain tiles: 

    Then I was ready to go!

    Beautiful terrain rendered with 10 m elevation data from the Norwegian Mapping Authority. Those who know Jotunheimen, will notice Skogadalsbøen by the river and Stølsnostind and Falketind surrounded by glaciers in the background.

    The terrain is a bit blocky (see the mount Falketind to the left), but I'm not sure if this is happening in Cesium Terrain Builder or Cesium itself. The quantized-mesh tiles from AGI gives a better result. 

    I'm not able so show an interactive version, as I'm using detailed aerial imagery from "Norge i bilder", which are not publicly available.

    by Bjørn Sandvik (noreply@blogger.com) at October 19, 2014 10:01 AM

    October 18, 2014

    Gary Sherman

    PyQGIS Resources

    Here is a short list of resources available when writing Python code in QGIS. If you know of others, please leave a comment.


    In alphabetical order:


    Example Code

    • Existing plugins can be a great learning tool
    • Code Snippets in the PyQGIS Cookbook


    • Script Runner: Run scripts to automate QGIS tasks
    • Plugin Builder: Create a starter plugin that you can customize to complete your own plugin
    • pb_tool: Tool to compile and deploy your plugins


    October 18, 2014 06:18 PM

    Antonio Santiago

    7 reasons to use Yeoman’s angular-fullstack generator

    For my next project and, after looking for candidates and reading some hundreds of lines of documentation, I finally choose to work with the so called MEAN stack: mongodb, express, angular and node.

    As with any other technology ecosystem, the great number of frameworks, libraries and tools can make our choice a challenge, and JavaScript is not an exception. But for JavaScript projects we have lot of help and I decide to use the awesome Yeoman tool. Yeoman combines the power of grunt, bower, npm and adds its own salt: the generators.

    Yeoman generators are tasks responsible to build the initial project scaffolding.

    Yeoman offers an extensive set of official generators oriented to create: webapps, backbone app, chrome extension, etc but we can also found a myriad of non oficial generators (yes, because anyone can create a new generator to satisfy his/her needs).

    Within all the generators I chose angular-fullstack to create my MEAN project structure and next are my reasons:

    1. Easy to install

    You require to have node and npm installed on your system. Once you have them installYeoman and the angular-fullstack is as easy as:

    $ npm install -g yo
    $ npm install -g generator-angular-fullstack

    Once installed the generator you simply need to create a new folder and initialise your project:

    $ mkdir my-new-project && cd $_
    $ yo angular-fullstack [app-name]

    2. Creates both client and server scaffoldings

    The generator generates the full stack of your project, both the client and server code. Your project will start well organised and prepared to create an awesome RIA application.

    3. Introduces good practices in the generated code

    Because the generated is made by experienced developers, they applies good practices in code organisation and style programming (like the environment configuration on the server side using node).

    For me, this is one of the most important reasons to use this generator. Anybody knows starting with a new technology is always hard, but it is nothing when you start with four new technologies :)

    4. Server side API prepared to use authentication

    Following best practices the code is prepared so you can easily add security to you API via a node middleware so each request requires authentication of the client side.

    5. Support HTML or jade templating on client side

    You can use any template engine for client side but by default the generator works with HTML and Jade. I don’t really like Jade too much so I always try to use EJS or similar (Warning this last sentence is the author’s opinion).

    6. Support for different CSS preprocessors

    For different opinions there are different alternatives. This way angular-fullstack has support for plain CSS, Stylus, Sass or LESS pre-processors. Choose your preferred.

    7. Commands to scaffold anything

    With theangular-fullstack you can create new end points for the server side or client side components (like routes, controllers, services, filters, directives, …) with a sentences. So, next command:

    yo angular-fullstack:endpoint message
    [?] What will the url of your endpoint to be? /api/messages

    will produce:

    server/api/message/message.model.js  (optional)
    server/api/message/message.socket.js (optional)


    In my opnion, angular-fullstack is a really powerful tool that simplifies our day to day work.

    As always it is not the panacea, it is simply a generic tool to automatize many common tasks. Because of this we can found situations it lacks some feature.

    by asantiago at October 18, 2014 10:17 AM

    October 17, 2014


    Call For papers Geospatial devroom @FOSDEM

    Please forward!

    FOSDEM is a free open source event bringing together about 5000 developers in Brussels, Belgium. The goal is to provide open source software developers and communities a place to meet at. The next edition will take place the weekend 31/1 -> 1/2/2015. This year for the first time there will be a geospatial devroom on Sunday 1/2/2015!

    Geospatial technology becomes more and more part of mainstream IT. The idea is to bring together people with different backgrounds to better explain and understand the opportunities Geospatial can offer. This devroom will host topics explaining the state of the art of geospatial technology, and how it can be used amongst other projects.

    The geospatial devroom is the place to talk about open, geo-related data and software and their ecosystem. This includes standards and tools, e.g. for spatial databases, and online mapping, geospatial services, used for collecting, storing, delivering, analysing, and visualizing puposes. Typical topics that will be covered are:

    • Web and desktop GIS applications
    • Interoperable geospatial web services and specifications
    • Collection of data using sensors/drones/satellites
    • Open hardware for geospatial applications
    • Geo-analytic algorithms/libraries
    • Geospatial extensions for classical databases (indexes, operations)
    • Dedicated databases

    Are you thrilled to present your work to other open source developers? Would you like to run a discussion? Any other ideas? Please submit your proposal at the Pentabarf event planning tool at:


    When submitting your talk in Pentabarf, make sure to select the 'Geospatial devroom' as  'Track'. Please specify in the notes if you prefer for your presentation a short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes presentation + discussion).

    The DEADLINE for submissions is **1st December 2014**

    Should you have any questions, please do not hesitate to get in touch with the organisers of the devroom at fosdem-geospatial@gisky.be!

    Johan Van de Wauw
    Margherita Di Leo
    Astrid Emde
    Anne Ghisla
    Julien Fastré
    Martin Hammitzsch
    Andy Petrella 
    Dirk Frigne
    Gael Musquet

    A final note for everyone still hesitating to come: have a look at the accepted devrooms and other tracks for this year, I'm sure you will find other interesting topics that will make your trip to FOSDEM worthwile!

    by Johan Van de Wauw (noreply@blogger.com) at October 17, 2014 07:36 AM

    Just van den Broecke

    Into the Weather – Part 1 – Exploring weewx


    WMS Time Example with GeoServer in Heron

    Tagging this post as “Part 1″  is ambitious. Beware: there is hardly any “geo” for now. In the coming time I hope to share some technical experiences with weather stations, weather software and ultimately exposing weather data via some open geospatial standards like OGC WMS(-Time) as in example image right, WFS and in particular SOS (Sensor Observation Service). The context is an exciting project with Geonovum in the Netherlands: to transform and expose (via web services and reporting) open/raw Air Quality data from RIVM , the  Dutch National Institute for Public Health and the Environment. The main link to this project is sensors.geonovum.nl. All software is developed as FOSS via a GitHub project. There are already some results there. I may post on these later.


    Within a sub-project the aim is to expose measurements from a physical weather station via standardized OGC web services like WMS, WFS and SOS.  As a first step I dived into the world of weather hardware and software, in particular their vivid open source/open data communities. A whole new world expanded to me. To no surprise: Location and The Weather are part of everyday life since the beginnings of humanity. OpenWeatherMap and Weather Underground are just two of the many communities around open weather data. In addition there’s an abundance of FOSS weather software. Personal weather stations are measuring not just temperature but also pressure, humidity, rainfall, wind, up to UV radiation and are built homebrew or bought for as cheap as $50,-. 

    Weather Hacking

    Weather Hacking

    Being a noob in weather soft/hardware technology I had to start somewhere and then go step-by-step. The overall “architecture” can be even depicted in text:

    weather station --> soft/middleware --> web services + reporting
    Davis Vantage Pro2 Weather Station

    Davis Vantage Pro2 Weather Station

    Being more of a software person, I decided to start with the weather soft/middleware. Also, since Geonovum already owns a Davis Vantage Pro2 Weather Station and the Raspberry Pi B+ I plan to use is still underway…

    From what I gathered, weewx is the most widely used engine/framework within the weather FOSS community. Also the fact that it is written in Python with a very extensible architecture immediately settled my choice. Explaining weewx is a subject by itself but very well documented. I’ll try in a few sentences what weewx does:

    • collect current and archive weather station measurement data (drivers)
    • storing weather data (archive and statistics) in a database (SQLite or MySQL)
    • submitting data to weather community services like Weather Underground
    • creating formatted/templated reports for your local or remote website

    Any of these functionalities is highly extensible through a configurable plugin architecture. The drivers support most common weather stations. Installing is a breeze, either in a local directory or via Linux package managers. Also note that weather data  have quite some different local units (Fahrenheit/Celsius, knots/meters etc). weewx will all take care of this.

    So, not yet having access to a weather station, what could I do? One of the weather station drivers is the Simulator which intelligently generates weather data for testing.

    openweathermapTrying to have some real-world data I set out on what appeared to be a two-hour hack: create a weather station driver that obtains its data from an open weather API. There are many off course. I choose the OpenWeatherMap API to get data in the area of our cabin in the woods near the place of Otterlo in the Netherlands. Writing this hard-coded driver took just a few line of Python. The source code can be found here.  To not overask the API, I’ve set the time interval to 2 minutes within the weewx configuration file. Also it would not be fair to report these values to any of the weather communities. If the weewx community is interested I can donate this software, with some generalization (e.g. URLvia config).

    But all in all my first driver is still running fine in weewx. The main challenge was converting all the values between different metric systems. weewx allows and even encourages you to store all data in US metrics. All the reporting and conversion utilities will always allow you to show your local metric units.

    otterlo-weewx-reportAs a Linux daemon now runs fine in our test system. It is time to show some results. weewx reporting is basically a website generated via Cheetah templates. The default template is basic white on black. I found a nice template called Byteweather. You can find my continuous weather report  here at sensors.geonovum.nl/weather. Measurements are now building up thanks to the weewx archive database. Values are mostly matching Dutch weather station data. Expect for the rainfall…Surely we have lots of rain but not that much…

    Next posting I hope to tell more about deploying the Raspberry Pi and connecting to the Geonovum Davis Weather station. Then there will be also more “geo” in the post, I promise!


    by Just van den Broecke at October 17, 2014 01:21 AM

    October 16, 2014

    Boundless Blog

    Partner Profiles: Agrisoft

    Boundless partners are an important part of spreading the depth and breadth of our software around the world. In this ongoing series, we will be featuring some of our partners and the ways they are expanding the reach of our Spatial IT solutions.

    AgrisoftEstablished in 2002, Agrisoft is an Indonesian consulting firm specializing in integrated spatial solutions using open source software. Agrisoft offers consultancy, integration and training services, product development, and knowledge of clients’ business processes.

    With a population of 250 million people and a booming business community, Indonesia has proved itself to be a growing market for Agrisoft and Boundless. While the market for spatial solutions is still young, Agrisoft encourages the use of spatial software for business by promoting its value and establishing it as a viable solution. OpenGeo Suite provides a complete set of tools for Agrisoft’s clients to build spatially-enabled applications and GeoServer, OpenLayers, and PostGIS have become the preferred solutions among Agrisoft’s clients.

    SIH3: Sistem Informasi Hidrologi Hidrometeorologi & Hidrogeologi

    Tools and expertise from Boundless have enabled Agrisoft to expand and improve on some of their largest projects and they count among their customers the Indonesian Geospatial Information Agency and the Republic of Indonesia Ministry of Agriculture. In a current project for the Republic of Indonesia Agency for Meteorology, Climatology and Geophysics, Agrisoft is working on the SIH3 Portal, an information system for hydrology, hydrometeorology and hydrogeology. This project makes use of applications built on OpenGeo Suite to browse and explore maps showing different information and Agrisoft is redesigning the graphical user interface using OpenLayers 3.

    Agrisoft continually encourages the use of open source spatial software and looks to Boundless for industry best practices and guidance for their current and prospective customers.

    If you’d like your company to be considered for our international network of partners, please contact us!

    The post Partner Profiles: Agrisoft appeared first on Boundless.

    by Camille Acey at October 16, 2014 02:29 PM

    gvSIG Team

    “Introduction to gvSIG 2.1″ workshop in English

    A workshop about the new gvSIG 2.1 version was given in April at the 1st Mexican gvSIG Conference, and now it has been translated to English thanks to Elena Sánchez and
    Francisco Solís.

    This workshop shows the main gvSIG functionalities, and it includes the new
    features that have been included in gvSIG 2.1.

    You can download the workshop in pdf format, and the cartography, from [1].

    We hope it’s useful for you!

    [1] http://www.gvsig.org/plone/docusr/learning/gvsig-courses/gvsig_des_2.1_u_en/pub/documentation/

    Filed under: community, english, events, gvSIG Desktop, training

    by Mario at October 16, 2014 01:49 PM

    Even Rouault

    Warping, overviews and... warped overviews

    The development version of GDAL has lately received a few long awaited improvements in the area of warping and overview computation.

    For those non familiar with GDAL, warping is mainly used for reprojecting datasets from one source coordinate system to a target one, or to create a "north-up" image from a rotated image or an image that has ground control points. Overviews in GDAL are also called pyramids in other GIS software and are sub-sampled (i.e. with coarser resolution) versions of full-resolution datasets, that are mainly used for fast display in zooming out operations. Depending on the utility (warper or overview computation), different resampling methods are available : bilinear, cubic, cubicspline, lanczos, average, etc..

    Cubic resampling

    Up to now, the bi-cubic resampling algorithm used when computing warped images and overviews was a 4x4 convolution kernel. This was appropriate for warping, when the dimensions of the target dataset are of the same order as the source dataset. However if the target dataset was downsized (which is the nominal case of overview computation), the result was sub-optimal, not to say plainly bad, because not enough source pixels were captured, leading to a result close to what nearest neighbour would give. Now, the convolution kernel dynamically uses the subsampling ratio to take into account all source pixels that have an influence on each target pixel, so e.g 8x8 pixels if subsampling by a factor of 2.
    Of course, this involves more computation and could be slower. Fortunately, for 64 bit builds, Intel SSE2 intrinsics are at the rescue to compute convolutions in a very efficient way.

    For example in GDAL 2.0dev, computing 5 overview levels on a 10474x4951 RGB raster with cubic resampling takes 2.4 seconds on a Core i5-750, to be compared with 3.8s with GDAL 1.11

    $ gdaladdo -ro -r cubic world_4326.tif 2 4 8 16 32

    To compare both results, we can select the 5th overview level with the fresh new open option OVERVIEW_LEVEL=4 (index are 0 based)

    $ gdal_translate world_4326.tif out.tif -oo OVERVIEW_LEVEL=4

    5th overview generated by GDAL 2.0dev

    5th overview generated by GDAL 1.11.1

    So yes, faster (a bit) and better (a lot) !

    Similar result can also be obtained with :

    $ gdalwarp -r cubic world_4326.tif out.tif -ts 328 155

    The "-oo OVERVIEW_LEVEL=xxx" option can be used with gdalinfo, gdal_translate and gdalwarp, or with the new GDALOpenEx() API.

    Related work could involve adding resampling method selection in the RasterIO() API that currently only does nearest neighbour sampling. If that might interest you, please contact me.

    Overviews in warping

    Related to the OVERVIEW_LEVEL open option, another long due improvement was the selection of the appropriate overview level when warping. A typical use case is to start with a WMS or tiled dataset, e.g the OpenStreetMap tiles, and wanting to reproject full or partial extent to an image with reasonably small dimensions. Up to now, GDAL would alway use the most precision dataset (typically zoom level 18 for OpenStreetMap), which would make the operation terribly slow and unpractical.

    Now, the following will run in just a few seconds :

    $ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
      -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000

    With the -ovr flag, you can modify the overview selection strategy, and for example specify you want to use the overview if the level immediately before the one that would have been automatically selected (i.e. with bigger dimensions, more precise)

    $ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
      -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000 -ovr AUTO-1

    You can also specify a precise overview level to control the level of details, which is particuarly relevant in the case of OSM since the rendering depends on the scale :

    $ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
      -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000 -ovr 9

    (Note: -ovr 9 is equivalent to OSM zoom level 8, since GDAL_overview_level = OSM_max_zoom_level - 1 - OSM_level, 9 = 18 - 1 - 8. )

    With -ovr 9 (zoom level 8)

    With -ovr 10 (zoom level 7)

    With -ovr 11 (zoom level 6) or without any -ovr parameter

    With -ovr 12 (zoom level 5)
    (All above images are © OpenStreetMap contributors)

    Overviews in warped VRT

    GDAL advanced users will perhaps know the Virtual Raster (.vrt) format. There are several flavors of VRT files, one of them is the so-called "warped VRT", which can be produced by "gdalwarp -of VRT". This is an XML file that captures the name of the source dataset being warped and the parameters of the warping: output resolution, extent, dimensions, transformer used, etc... This can be convenient to do on-the-fly reprojection without needing to store the result of the reprojection. Similarly to regular warping, warped VRT can now make use of overviews of the source dataset to expose "implicit" overviews in the warped VRT dataset. Which make it possible to use warped VRT in a GIS viewer ith decent performance when zooming out. Among others, this will be  beneficial to QGIS that use the "auto-warped-VRT" mechanism when opening a raster that is not a "north-up" dataset.

    Still playing with our OpenStreetMap dataset, let's create a warped VRT around western Europe :

    $ gdalwarp frmt_wms_openstreetmap_tms.xml out.vrt -t_srs EPSG:4326 \
      -r cubic -te -10 35 10 55 -overwrite -of VRT

    We can see that the VRT now advertizes overviews :

    $ gdalinfo out.vrt
    Size is 4767192, 4767192
    Band 1 Block=512x128 Type=Byte, ColorInterp=Red
      Overviews: 2383596x2383596, 1191798x1191798, 595899x595899,
                 297950x297950, 148975x148975, 74487x74487,
                 37244x37244, 18622x18622, 9311x9311, 4655x4655,
                 2328x2328, 1164x1164, 582x582, 291x291, 145x145,
                 73x73, 36x36, 18x18

    I'd like to thank Koordinates and Land Information New Zealand for funding those improvements.

    by Even Rouault (noreply@blogger.com) at October 16, 2014 01:19 PM

    Slashgeo (FOSS Articles)

    Versio: Distributed Version Control for Spatial Data, and GeoGig News (formerly GeoGit)

    Spatial data versioning is important to lots of geospatial applications. We mentioned GeoGit (now named GeoGig) quite a few times since 2012. This week Boundless announced a private beta (you can request an invitation) of Versio, a website for distributed version control of spatial data.

    First, you may want to see how GeoGig (formerly GeoGit) has matured, it’s open source and essentially “[w]ith GeoGig, users are able to import spatial data into a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories.”

    Regarding Versio itself, “With Versio, we want to support as many editing workflows as possible, both online and offline. So we’ve made the platform client-agnostic to support traditional desktop GIS software as well as web, mobile, or custom applications built on the Versio API”.

    The post Versio: Distributed Version Control for Spatial Data, and GeoGig News (formerly GeoGit) appeared first on Slashgeo.org.

    by Alex at October 16, 2014 12:34 PM

    Petr Pridal

    Amazon S3 as a WMTS cloud hosting for maps

    The current version of MapTiler (0.5.5) supports direct upload of map tiles to Amazon S3 or Google Cloud Storage. Such hosting is a robust and affordable way to publish your maps online.

    Maps rendered with MapTiler or available as MBTiles file are after upload available in various viewers, such as Leaflet, OpenLayers, WebGL Earth, Google Maps API, MapBox.js, etc.

    Thanks to the OGC WMTS standard the maps can be also directly opened in QGIS or ArcGIS for Desktop. Compared to the standard S3 utilities, uploading of map tiles is a way faster, especially for larger maps.

    The workflow is as simple as few clicks. Watch our video tutorial:

    by Hynek Přidal (noreply@blogger.com) at October 16, 2014 08:20 AM

    gvSIG Team

    Webinar sobre el modelizador de geoprocesos en gvSIG

    Este viernes 17 de octubre tendremos un nuevo e interesante seminario online organizado por MundoGEO y Asociación gvSIG. En este caso aprenderemos sobre uno de los temas más desconocidos de gvSIG y que aporta grandes posibilidades a los usuarios: el modelizador de geoprocesos.

    Este webinar forma parte de las (muchas y variadas) actividades que se están llevando a cabo en conmemoración de los 10 años de gvSIG.

    Con inscripción gratuita, este evento online está dirigido a todas aquellas personas con conocimientos básicos de geoprocesamiento vectorial y raster.

    El ponente será Gustavo Agüero Córdoba, profesor SIG de la EARTH University, la Universidad Técnica Nacional de Costa Rica, y profesor de los Cursos gvSIG y Geoprocesamiento Avanzado en la Asociación gvSIG.

    Para inscribirse sigue el siguiente enlace: https://www2.gotomeeting.com/register/285059474


    Filed under: events, gvSIG Desktop, spanish Tagged: geoprocesamiento, modelizador

    by Alvaro at October 16, 2014 06:49 AM

    October 15, 2014

    gvSIG Team

    Culminaron las 1as Jornadas de Tecnologías Libres de Información Geográfica y Datos Abiertos y 3as Jornadas de gvSIG Uruguay

    Los pasados 2 y 3 de octubre tuvieron lugar las 1as Jornadas de Tecnologías Libres de Información Geográfica y Datos Abiertos y 3as Jornadas de gvSIG Uruguay. Este gran desafío que significó llegar a las 3as Jornadas podemos decir que se superó con creces: más de 140 asistentes a las ponencias (primer día) y 4 talleres totalmente desbordados (segundo día). Y esto en un pequeño país con poco más de tres millones de habitantes y con un público objetivo muy limitado pero que los hechos demuestras que está ávido de aprender, informarse y compartir.

    _0002492 IMG_0417

    Gracias al esfuerzo voluntario, honorario y desinteresado de un grupo de entusiastas y defensores del proyecto gvSIG y de la geomática libre en general, más la colaboración de instituciones y empresas que apoyan este proyecto solidario y colaborativo, podemos decir que fueron las mejores Jornadas ya organizadas por la Comunidad gvSIG Uruguay: un programa equilibrado e interesante, una oferta de talleres muy atractiva, una concurrencia atenta y respetuosa y todos los detalles cuidados con mucho esmero y dedicación (transmisión en vivo y en directo, instalaciones y servicios de primer nivel, cafetería, materiales entregados, etc.) hacen que los organizadores veamos con optimismo un futuro con más y mejores Jornadas.

    Geoserver-_1070942 _1070914

    Decíamos que estas Jornadas tenían un sabor especial debido a 4 factores:

    1. la reciente aprobación de la Ley de Software Libre y Formatos Abiertos en el Estado
    2. la creciente importancia de los Datos Abiertos a nivel nacional y mundial (se cumplen 6 años de aprobada la Ley de Acceso a la Información Pública en Uruguay)
    3. la nueva etapa que comienza a recorrer la IDEuy (Infraestructura de Datos Espaciales de Uruguay http://ide.uy/) a partir del 1o de enero pasado (ver ponencia al respecto)
    4. la conmemoración del 10mo. aniversario del software gvSIG

    _1070918 _1070953

    Gracias a todas y todos los que hicieron posible este evento que seguramente marcará un hito en la difusión de las Tecnologías Libres de Información Geográfica y Datos -espaciales- Abiertos en general y de gvSIG en particular. ¡Hasta la próxima!

    Filed under: opinion

    by Sergio Acosta y Lara at October 15, 2014 12:35 PM

    Slashgeo (FOSS Articles)

    Slashgeo is a proud media partner of FOSS4G-Asia 2014

    We are happy to inform you that Slashgeo will be a proud media partner of the upcoming Free & Open Source Solutions for GIS (FOSS4G) – Asia conference held in Bangkok, Thailand, 2-5 December 2014!



    FOSS4G-Asia 2014 aims to bring together FOSS4G users and developers worldwide and foster closer interactions with and amongst Asian communities in order to share ideas for improving software and applications. The Bangkok conference will cover all aspects of FOSS4G, Open Data and Open Standards, with a particular focus on exchanging experiences between FOSS4G users and developers and providing first-hand information on FOSS4G for developing national/local spatial data infrastructures in Asian countries. FOSS4G-Asia 2014 also commemorates ten years since the FOSS-GRASS User Conference was held at Faculty of Engineering, Chulalongkorn University, Thailand between 12-14 September 2004.

    Workshops will also be offer on QGIS, ZOO project, MapMint, InaSafe, pgRouting, OpenStreetMap and OpenLayers 3.

    Slashgeo will publish articles during and after the conference on what has been highlighted in presentation, workshop and innovative ideas on the geospatial open source, open data & open standard  front in Asia and elsewhere.

    The post Slashgeo is a proud media partner of FOSS4G-Asia 2014 appeared first on Slashgeo.org.

    by gignacnic at October 15, 2014 01:41 AM

    October 14, 2014

    Boundless Blog

    Introducing Versio: Distributed Version Control for Spatial Data

    Boundless is pleased to introduce Versio, our new data management and collaboration platform built specifically for spatial data. We’ve been working on Versio for over a year, extending the power of the GeoGig approach into an online platform that will transform the way organizations collaborate on, control, and share their spatial data.

    Versio homepage

    Versio is now available in private beta with select customers and community members. We expect to release the full platform in early 2015, but if you would like to get an early look and help us improve the product, please request an invitation at http://vers.io/request-invite.

    The Problem

    Spatial data is dynamic, and anyone who works with it knows that keeping it updated is a challenge. The larger the organization, the worse this problem gets. Increasing team sizes, field-based data collection, and integrated workflows that depend on the publishing of timely, updated datasets increases the complexity of managing spatial data. Too often this challenge is met by emailing shapefiles around, resulting in a file naming nightmare, and a labor-intensive process to merge data together. Alternatively, if you have the money, an expensive versioning database can be used, but even that suffers from potential centralized outages, file locks, and complex system administration.

    The Solution

    To solve this problem, we looked for a new model of collaboration – one that has revolutionized software development – distributed version control systems.  Boundless first introduced the distributed versioning concept to Spatial IT with GeoGig, an open source tool that draws inspiration from Git but adapts its core concepts specifically for spatial data. As GeoGig has matured, we built Versio to broaden the audience by including a high-performance server and easy-to-use web interface.

    Versio’s distributed versioning model and repository data structure enables new approaches to collaboration and data management. On the collaboration side, data owners and GIS analysts determine specifically who they collaborate with, creating private data repositories and inviting others to join, or sharing a data repository for the
    crowd to update. Changes to a dataset can be stored in a different “branch” of the repository, and data owners have explicit control over what changes are merged back into the core repository.

    The repository data structure preserves the entire lineage of a dataset, allowing a user to track and visualize changes over time. Rather than relying on a central database, each individual’s working copy is a complete repository of the spatial data. Each “commit” to the repository is saved as a discrete version, yet also maintains its relationship to previous versions in the repository. This allows users to visualize the lineage of features across all versions, as well as the changes between different versions. Additionally, file sizes are minimized since only the changes between versions are stored (eliminating redundant data) and it is easy to rollback to a previous version of a dataset.

    With Versio, we want to support as many editing workflows as possible, both online and offline. So we’ve made the platform client-agnostic to support traditional desktop GIS software as well as web, mobile, or custom applications built on the Versio API.

    Request an invitation to the Versio private beta at http://vers.io/request-invite!

    The post Introducing Versio: Distributed Version Control for Spatial Data appeared first on Boundless.

    by Joshua Campbell at October 14, 2014 01:30 PM

    Jackie Ng

    Make that 3/3

    Thanks to this thread, I was finally able to crack the missing piece of the CZML output puzzle for mapguide-rest, and we can now output point, line and polygon features as CZML to Cesium.

    CZML is a representation of a Layer Definition in mapguide-rest, this means we will get pre-evaluated properties to play with such as:

    We currently use this information as follows

    Tooltips get written as the description property of each CZML packet, allowing such information to be displayed in the Cesium information window when the object is selected.

    Now as the above screenshot shows, there's no real visual way to know what object you selected. I'm still figuring out if there's a way in CZML or the Cesium APIs to specify how a selected object looks so it can stand out.

    If the Layer Definition has elevation/extrusion settings applied, that's when the fun stuff happens. We apply the extruded value in the CZML packet for each feature, giving us 2.5D features. This extrusion only applies for polygon features at the moment.

    Oh, and did you know Cesium works pretty well on any WebGL capable mobile browser?

    Pretty cool stuff. Now that we've nailed down the fundamentals, it's time to figure out how much visual fidelity we can preserve from MapGuide to CZML:

    • Can we transfer thematics?
    • Can we transfer labels?
    • Can we transfer patterns?
    • Others?
    Fun times ahead!

    by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

    Jackie Ng

    Making MBTiles databases with a little help from mapguide-rest

    So allow me to explain what this screenshot represents

    What you are looking at is tiles stored in a MBTiles database. The Android app in question is Locus Map, which supports MBTiles databases. MBTiles is an ideal format for delivering tiled maps to mobile devices. It's just a SQLite database that uses the same intuitive XYZ tiling scheme used by OpenStreetMap and friends.

    This post will show you how to make such MBTiles databases with a little help from the mapguide-rest extension.

    [NOTE: These instructions were used against the current master branch of mapguide-rest which supercedes the 0.8 release, and has several fixes for tile caching. These instructions may or may not work on the 0.8 release]

    First thing you need is to download and install Portable Basemap Server.

    In the directory where you installed Portable Basemap Server, edit the CustomOnlineMaps.xml and add a new map source to any XYZ tileset accessible from mapguide-rest

    <name>mapguide-rest Sheboygan</name>
    <url><![CDATA[http://localhost/mapguide/rest/library/Samples/Sheboygan/MapsTiled/SheboyganNoWatermark.MapDefinition/xyz/Base Layer Group/{$z}/{$x}/{$y}/tile.png]]></url>

    Note the {$x}, {$y} and {$z} placeholder tokens in the URL. These placeholders are required and Portable Basemap Server will be replacing them with actual X, Y and Z values when fetching tiles.

    Once you've edited and saved CustomOnlineMaps.xml, run the PortableBasemapServer.exe as an administrator.

    What is unique about Portable Basemap Server (and something I could not find in any other free/OSS packages), is that Portable Basemap Server includes a convenient function to create an MBTiles database from any online tiled map (that presumably follows a XYZ tiling scheme). This function is accessible from the Format Convert menu.

    In the Format Convert window, change the Data Source Type to the map source you registered in CustomOnlineMaps.xml. If your tiled map does not span the entire world, you may want to hone in to the specific region your tiled map is in with one of the existing map sources before switching over to your mapguide-rest map source.

    Now do the following:

    • Specify the path of the MBTiles database you want to create
    • Trace a box around the area you want to fetch the tiles for
    • Tick the Download Levels (aka. Zoom levels) you want to fetch tiles for. The map preview shows the current zoom level, so generally you want to tick that level and every level above that.
    • Tick Compact? to optimize storage of redundant tiles

    Once you are satisfied with the settings, click Start to initiate the tile seeding process. Portable Basemap Server will spit out lots of useful progress information while building the MBTiles database.

    Once the tile seeding process is complete, you can now transfer this MBTiles database file to your mobile device and load it into your MBTiles supported app.

    As a bonus, the actual process of building an MBTiles database also seeds the XYZ tile cache on the server-side. So this process can also serve as a XYZ tile cache seeder if you have no use for MBTiles.

    If you're interested in what platforms support MBTiles, check out the MBTiles wiki.

    by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

    Jackie Ng

    Announcing: mapguide-rest 0.9

    Here's a new release of mapguide-rest, packed with some new toys.

    PDF Support

    The existing URL routes for DWF plotting now also support PDF output.

    For example, a DWF plot URL like this:


    Can be turned into a PDF plot like this just by replacing the .dwf in the URL to .pdf:


    When plotting from a session-based runtime map, you also have the option of producing a layered PDF. To produce a layered PDF, simply append layeredpdf=1 to a PDF plot URL on a session-based runtime map. This takes longer to plot than a normal PDF, but the resulting PDF will have a toggle-able layer structure

    Queryable Layer Definitions

    The existing URL routes to query feature data from Feature Sources can now also be applied to Layer Definitions.

    For example, suppose you originally were querying Parcels from its Feature Source

    GET http://localhost/mapguide/rest/library/Samples/Sheboygan/Data/Parcels.FeatureSource/features.xml/SHP_Schema/Parcels?maxfeatures=500

    You can now also query the same data via a Layer Definition that points to it

    GET http://localhost/mapguide/rest/library/Samples/Sheboygan/Layers/Parcels.LayerDefinition/features.xml?maxfeatures=500

    You'll notice that querying via Layer Definitions means you don't have to include the fully-qualified FDO class name in the URL as that will be inferred from the Layer Definition document. Also when querying via Layer Definitions, it will also include evaluated tooltip and hyperlink expressions for each feature (as MG_TOOLTIP and MG_HYPERLINK properties)

    The Layer Definition query route supports the same parameters as the Feature Source one and supports GeoJSON output as well.

    New Samples

    We've added a new OpenLayers 3 example, demonstrating how to consume dynamic GeoJSON vector layers from the REST API

    And a new Cesium example, also consuming GeoJSON from the REST API

    Other Changes

    • GeoJSON features now include id attributes containing the identity property value. Previously the identity property value was written out as a regular feature property.
    • Improved XYZ tile cache resiliency
    • Feature query routes (ie. selecting features) no longer require an authentication challenge and can be done anonymously.
    • Feature query responses are no longer internally buffered, reducing response wait times.


    by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

    Jackie Ng


    After lots of trial and error, I am finally able to output features from MapGuide as CZML to Cesium via mapguide-rest

    However, only 2 out of the 3 geometry types are working (points and polygons). I'm still trying to figure out:
    • How to properly output CZML for line features
    • How best to apply Z extrusion where it is defined in the Layer Definition
    • What parts of a Layer Definition are transferable/translatable to CZML? Doesn't have to be 1:1. KML-level visual/information fidelity would suffice here.
    If only there were more comprehensive CZML examples I could refer to that would make implementing this stuff much easier! All the examples I could find try to demonstrate every bell and whistle when all I want to know is where do I stick the lat/lon/elevation coordinates from my source geometries? Their CZML documentation could do with some improvement, a single-page document is terribly hard to navigate and without reference examples it's amazing I was even able to get this far!

    But in the end, all this pain and struggle will be worth it because Cesium is just plain awesome! I truly believe that Cesium will be to 3D maps what OpenLayers is to 2D maps: A powerful web-based map viewing platform that is rich in features and support for many different vector and raster data sources.

    by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

    Jackie Ng

    Announcing: mapguide-rest 0.10

    Nope, this isn't a 1.0 release. Not only are we not using decimal release numbers, but there's still plenty of things to explore and refine before we can put the 1.0 stamp on this thing. Here's what's new and changed in this release.

    (Experimental) Cesium CZML support

    We now have support for outputting feature data as CZML for consumption inside the Cesium 3D web viewer. Support for CZML is made available as a representation of a given Layer Definition.

    For example, the following route will return data from the trees layer as CZML:


    We've included a CZML example in this release that demonstrates the level of support that has been implemented for this release.

    When selecting an object, its tooltip data will be shown in Cesium's information window if available.

    Note the object itself has no selection indicator unless the object is a point. Still trying to figure out if we can apply a different style for selected lines and polygons.

    If your Layer Definition has elevation settings applied, they be extruded if they're polygons

    Now if the (experimental) tag didn't stand out, here's the current limitations with this implementation:
    • The following properties are preserved when converted to CZML, anything not listed can be assumed lost in translation:
      • Point styles: Point color is preserved. The point size in CZML is the average of the height/width of the point as defined in the Layer Definition.
      • Line styles: Line color
      • Area/Polygon styles: Fill color. Outline color
    • If a Layer Definition has multiple scale ranges defined, mapguide-rest will only consider the first scale range when outputting CZML
    • If a given point/area/line style is themed, the default rule (the one without a filter) is ignored
    Data publishing improvements

    The restcfg.json now lets you specify a Layer Definition as the data source instead of a Feature Source and Feature Class name.

    Also, when using a Layer Definition as a data source, you'll get tooltip, hyperlink and elevation FDO expression pre-evaluated, allowing you to use such computed properties within your templates.

    You can find a new example that uses the building footprints from the Melbourne dataset.

    File download support

    Most GET routes can now prompt for downloads by appending download=1 to the query string of the URL.

    XYZ tile improvements

    Vector tiles can now be for a base layer group or for a layer within the base layer group.

    Just to recap, this URL route fetches a vector tile for a given base layer group in a Map Definition


    If you want vector tiles for a specific layer within that group, you can use this new URL route


    You can find a new Leaflet example that uses the single-layer vector tiles.

    Other changes

    • Fixed bad download links in the resource data list HTML representation
    • Fixed invalid chunked file transfer behavior under certain conditions
    • Samples updated to use OpenLayers 3 final and Cesium 1.1

    by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM