Organisation terrestris GmbH & Co kg

Additional Presenters
Name	Manuel Grizonnet
Organisation	CNES (DCT/SI/AP)
Email	[e-mail]
Name	Julien Malik
Organisation	CS SI
Email	[e-mail]

ID Number

13

Name	Andreas Neumann
Organisation	City of Uster, Switzerland
Email	[e-mail]

Paper Title	The QGEP waste-water management project
I can give a practical demo	yes

Paper Abstract (short)

A waste-water management application based on QGIS will be presented along with improvements in QGISÊcore for facilitating the development of QGISÊapplication modules based on complex data models.

Paper Abstract (long)

The QGEP project [2] has the goal to develop a QGIS based application module for the management of waste-water management and GEP (general sewer system planning). The presentation reports on the current state of application development, the problems the project is facing and solutions taken. QGEP will be one of the first bigger QGIS application modules using on a complex data structure involving many hundred tables and relations. Therefore the project has to deal with a lot of problems regarding database relations that are and will be solved in QGIS core so that other projects or applications can benefit from these improvements. The QGIS project [1] is enjoying increased popularity among local governments and smaller and medium-sized companies. However, there are still very few complex application modules in domains such as infrastructure documentation (gaz, water, electricity, telcommunication, heating and waste-water), cadastral data management and urban planning. At the end of the year 2011 a group of several waste-water engineers and municipalities met with the goal to establish a group to develop this waste-water application module, as a successive project to an older operational project "GEPView" which was based on ArcView 3, which was discontinued by ESRI. The project implements the data structure (VSA-DSS), regulations and guidelines defined and published by the Swiss waste-water association. Many commercial GIS vendors do not implement these regulatons sufficiently. The project is kind of pioneer in the area of developing more complex application modules based on QGIS. Theses applications, until now, are only available in commercial GIS, like ArcGIS, Geomedia, Autocad Map3d or Smallworld. Database relations (1:n, n:m) have to be supported along with many improvements regarding forms, nested forms based on the databse relations, improved filtering, input validation, mass attribute manipulation, DXF import/export improvements, network following, etc. These are all core requirements of more complex application modules that will be contributed by QGEP for other projects to re-use. In addition there are waste-water specific additions developed in Python and applicable only for the waste-water application. The data model is based on the DSS model [3] from the Swiss waste-water association. The table names, column names and comments have been translated to english to facilitate exchange between different language parts of Switzerland and potential other countries. A localisation to german and french language exists. Other languages can be added relatively easy. A Postgis database is the core of the project - triggers and rules help to ensure data consistency. We are using Python plugins and we can publish the project to the Web, mobile clients and OGC geoservices using QGIS Server and QGIS web client. For the network following plugin, NetworkX (python library) [4] is used. d3.js [5] inside a webkit frame is used to interactively display a profile along sewer channels and manholes, showing structure dimensions, depth and the surface profile. The goal of the project is to first offer a productive version for the editing of the main waste-water documentation (geometric and attributive editing). Later, more analysis modules, export and import modules and interfaces to other software will be added. As an open source project, other are invited to participate with their knowledge, ideas, testing and financing. Links [1] http://www.qgis.org/ - QuantumGIS (QGIS) project homepage [2] https://github.com/qgep/QGEP Ð project homepage with code, wiki and issue tracker [3] http://dss.vsa.ch/ - data structure "SiedlungsentwŠsserung des VSA (Verband Schweizer Abwasser- und GewŠsserschutzfachleute)" [4] http://networkx.github.com/ - High-productivity software for complex networks [5] http://d3js.org/ - Data-Driven Documents.

Topic type		Target Type
Case Studies: Relate your experiences. Visualization: effective presentation of information. Development: new developments in products. Collaboration: data collection, data sharing, open standards.		Manager End User Technical / Developer

Additional Presenters
Name	Matthias Kuhn
Organisation	University of Zurich
Email	[e-mail]

ID Number

218

Name	Paolo Cavallini
Organisation	Faunalia
Email	[e-mail]

Paper Title	The Right Approach: how Toscana is migrating to GFOSS
I can give a practical demo	no

Paper Abstract (short)

The Tuscany Regional Administration is migrating his GIS infrastructure to Open Source software. In doing so, they took the right approach, working with the community, and contributing back substantial amounts of code, especially to PostGIS and QGIS projects.

Paper Abstract (long)

The Tuscany Regional Administration had a rather usual proprietary GIS infrastructure (ArcIMS, Oracle, ArcGIS). They started migrating to Open Source GIS with an integrated approach, both on the sever side (PostGIS, MapServer, Geonetworks) and on the client side (Quantum GIS, GRASS), providing also training to hundreds of their technicians. What makes this experience particularly interesting is the fact that they worked form the onset in very close contact with the community, requiring that the code developed for them was generalized, and pushed to main source code. This seemed more cumbersome at first, having to coordinate with several other developers, and not having functions closely fit to their specific needs, but the superiority of this approach become quickly evident, as several functions were further improved and maintained by third parties. Among the most notable achievements were much improved topology support in PostGIS, SLD support in QGIS, and much more. We advise other administrations and enterprises to avoid the temptation of working in isolation, and simply using FOSS4G, maybe tailoring it locally, without contributing back, as this approach is short-lived, and less successful in the long term.

Topic type		Target Type
Case Studies: Relate your experiences.		Manager

ID Number

142

Name	Marc Jansen
Organisation	terrestris GmbH & Co. KG
Email	[e-mail]

Paper Title	The state and future of GeoExt 2
I can give a practical demo	yes

Paper Abstract (short)

The talk will showcase various aspects of the open-source JavaScript library GeoExt 2, a toolkit for rich web mapping applications based on OpenLayers & ExtJS, and outline the near future of the software.

Paper Abstract (long)

GeoExt 2 (http://geoext.org, https://github.com/geoext/geoext2) brings together the geospatial know how of OpenLayers (http://openlayers.org) with the user interface savvy of Ext JS (http://www.sencha.com/products/extjs) to help you build powerful desktop style GIS applications on the web with JavaScript. It is the successor of GeoExt 1.1. The talk will first highlight the current state of the software. Since a code-sprint in Spring 2012, GeoExt 2 is able to work with the newest versions of Ext JS 4.x. We will explore the possibilities of the various components in GeoExt and how these interact with the vast options that OpenLayers and ExtJS offer. I will both show code and running examples. We will explore the client-side MVC structure that ExtJS offers and GeoExt 2 fully supports. Also custom builds and the setup to generate these will be explained. Currently OpenLayers 2.x is used in GeoExt 2. As OpenLayers 3 gets nearer towards API stability, GeoExt will likely switch to using OpenLayers 3 in the near future. This is one upcoming task to be accomplished by the development-community. I will outline some other aspects of the future development of GeoExt 2 and upcoming versions.

Topic type		Target Type
Development: new developments in products.		Manager End User Technical / Developer

ID Number

110

Name	Javier çlvarez
Organisation	Vizzuality/CartoDB
Email	[e-mail]

Paper Title	The subtleties of the infowindow
I can give a practical demo	yes

Paper Abstract (short)

A nearly ubiquitous feature of online maps today is the infowindow, here we will discuss how to use them effectively to communicate and share data in maps online.

Paper Abstract (long)

A nearly ubiquitous feature of online maps today is the infowindow. Infowindows have some unique characteristics in an online map: infowindows represent a direct point of communication between a datapoint and the viewer; when active, infowindows often take up a large portion of the display area, and; infowindows serve as a platform for mixed media directly within an interactive map. Given their importance and unique role in interactive maps, little discussion is made about the design and implementation of infowindows as effective communication tools. Over the past 5 years of developing interactive maps, we have developed hundreds of unique infowindows, fine tuning the user interaction, information layout and presentation, and role in the mapping interface. More recently, as the core development team for CartoDB, we have been tasked with creating a reusable suit of infowindows useful for a broad range of user maps. From our work, we have learned an enormous amount about good practices for infowindow design, interaction, and content integration. Here we will discuss the lessons we have learned over the history of our work. We will discuss the good, the bad, and the beautiful in the often overlooked infowindow.

Topic type		Target Type
Case Studies: Relate your experiences. Visualization: effective presentation of information.		People new to open source geospatial Manager End User Technical / Developer

Additional Presenters
Name	Sergio Alvarez Leiva
Organisation	Vizzuality/CartoDB
Email	[e-mail]
Name	Javier de la Torre
Organisation	Vizzuality/CartoDB
Email	[e-mail]

ID Number

83

Name	Gemma BOIX XAMANI
Organisation	SIGTE-Universitat de Girona
Email	[e-mail]

Paper Title	Things to do with OpenStreetMap
I can give a practical demo	no

Paper Abstract (short)

OpenStreetMap is much more than a set of data. In this article we aim to present an overview showing a good portion of the possibilities it offers. We will see, first of all, what data one can download from OpenStreetMap and how it can be downloaded in a totally personalized way, employing completely customizable criteria. In addition to downloading we will look at other tools that add value to OSM: editors, importers to databases, geolocation services, image rendering, routing algorithms, etc.

Paper Abstract (long)

INTRODUCTION This study of the things we can do using OpenStreetMap arises from SIGTE's need, as a service within the University of Girona, to offer the university community new cartographic services based on free data and, more specifically, on OpenStreetMap, from the elaboration of paper maps to computer applications like the publication of maps, the rendering of custom layers, routing, etc. In this article we will examine the possibilities offered by OpenStreetMap and the main tools allowing one to operate with this data. AVAILABLE DATA AND DOWNLOADING There are three types of files ready to be downloaded. - planet.osm. This file, which takes up about 26 Gb in compressed format (pbf), contains all the OpenStreetMap mapping for the entire planet and is generated weekly. - history.osm. This file (39 Gb in compressed format) file is generated less frequently than the planet file and contains the entire history of the OSM database. - diff files. Due to the large volume of data handled in OpenStreetMap there are a number of differential (diff) files containing the database modifications carried out during a specific period (inserts, modifications, deletions). If one wishes to carry out more customized downloads (by country, region, city, etc.) he can download pregenerated extracts from the original database. These extracts can be downloaded from third-party sites that OSM makes available at its wiki (http://wiki.openstreetmap.org/wiki/Planet.osm). But if one wishes to customize his downloads even further (with more specific areas, or according to types of entities, such as main roads, parks, etc.), OSM also offers the possibility of using its APIs (Xpai, Overpass API) which, thanks to their REST interface, make it possible to download such data through the generation of URLs. DATA GENERATION AND EDITING The main way to participate in OSM is by editing the map, whether capturing the geographical data through GPS and mobile devices or using other open data sources. The workflow to generate OpenStreetMap data is as follows: 1. Data capture and acquisition 2. Data generation and editing 3. Data labelling 4. Map generation On the OSM wiki there is a complete list of editors (http://wiki.openstreetmap.org/wiki/Editing): PUBLICATION OF PERSONALIZED MAPS ON THE INTERNET The publication of maps on the Internet is one of the most common tasks carried out using OSM data. Thanks to free tools such as Leaflet and OpenLayers (to name two of the most widespread) one can, in just a few lines of code, generate maps for his webpages, blogs, etc. These tools are developed in Javascript code run on the client side, so these maps do not have any requirements on the server side and can be applied to any webpage. In the specific case of the Leaflet API, generating a map which shows the OSM mapping with the initial view one indicates (initial map coordinates and zoom level) is as simple as changing a couple of lines of code. IMPORTING OSM DATA TO DATABASES There are several tools to import data to databases in .osm format. The main ones are osm2pgsql, osmosis, imposm and nominatim. These tools are designed to organize data (within the databases) in accordance with schemes designed for some very specific uses. For example, osm2pgsql and imposm tools are designed to generate some highly efficient databases with a view to rendering. Other tools, such as nominatim, generate a scheme designed for geocoding, etc. Each tool, therefore, generates a scheme. The main features of these schemes are three: ¥ They are updatable. ¥ They contain predefined geometries. ¥ They contain all the attributes (comprehensive). RENDERING AND STYLES Rendering is the conversion of data into an image. During the rendering process the data to be included in the image is defined (on the basis of its attributes) and its style (colour, thickness, colour of the edge, symbols, the scale of the map at which an element is to appear, the scale of map at which it is to disappear, etc.). The complexity of rendering OSM data is mainly determined by three factors: the intricacy of each style, the great variety of different elements containing OSM and, thirdly, the fact that each level of zoom (up to 22) may have assigned a few unique styles for each element of the map. It is easy, thus, to imagine the effort required during the rendering. The tool used for this process is mapnik (available both for Windows and Linux systems). Mapnik, in addition to featuring a set of very versatile styles, gives one the possibility of partitioning the images generated into tiles to streamline their transmission on the Internet. In this way the transferred images are smaller and the map navigation gains enhanced fluidity. Mapnik recognizes many different input formats (PostGIS, shp, tiff; OGR, GDAL and raster formats, etc.) and makes it possible to generate output images in the formats png, jpg, pdf, svg, tiff, etc. Although the generation of styles is a very laborious process, there are tools like TileMill which speed up those processes through a user-friendly graphic interface. Tilemill includes mapnik in its installation as a rendering engine. Within TileMill one can upload the OSMBright project, which contains a set of pre-defined styles for OpenStreetMap. In this way one can customize his data, starting out from a previous definition and focusing only on those items which he wishes to highlight or customize. ROUTING One of the tools intermediate users will find easiest to use is osm2po, one developed in Java (multiplatform) which makes possible, via a few simple commands, the importation of .osm data and the creation of a Web service to process optimal route calculations in a web environment. Another tool, for slightly more advanced user profiles, is osm2pgrouting. Available on Linux systems, Osm2pgrouting allows one to import .osm data to a PostgreSQL/PostGIS database. It also generates the graph structure (as one more table) necessary for the calculation of optimal routes. With the graph one can modify the costs associated with the connections between nodes and, in this way, customize the routes according to his needs in each case. Osm2pgrouting requires, in addition to a PostGIS type database, pgRouting functions. pgRouting extends a PostgreSQL/PostGIS spatial database to include route calculation functionality.