This post is the initial post of a serie that will lead me to a GeoSummit presentation ("Die nächste Web-Generation mit Vektordaten" FR abstract) in june 2012.

Currently, performant web mapping applications are presenting data as raster tiles (maps.google.ch, www.openstreetmap.org, map.geo.admin.ch etc, etc...). But the majority of original data are vectors (streets network, buildings, addresses etc). So why this rasterisation ? In very short: because HTML supports images well (or because browser's have difficulty to render vectors and because internet bandwidth is limited).

Nevertheless, browsers have some capacity in vector rendering (SVG, VML, Canvas, WebGL). Until now, mainly SVG and VML were used and their performances allowed to represent only a limited amount of vector data.

In this initial post, I'll provide links that discuss and present ways to use vector data in web mapping:

- Using GeoJSON with OpenLayers
- Using GeoJSON with Polymaps
- Using GeoJSON with Tile5 (try the animation !)
- Using GeoJSON with Leaflet
- Simple maps using GeoJSON and Tile5 / Node.js + Express + Leaflet +  PostGIS = Awesome maps / Serving-up GeoJSON while having a REST on the GeoCouch
- OpenLayers and WebGL renderer
- openlayers-webgl
- Generates vector tiles from OGR datasources in GeoJSON usable in Polymaps
- Tile Feature Strategy in OpenLayers / Vector behaviour in OpenLayers
- OpenLayers UTFGrid Demo / UTFGrids with OpenLayers and Tilestache
- Veknik is a JS library that render features from CartoDB using HTML5 on top of Modestmaps

We can observe a lot of activities around vector data in web in the last two years. Cu soon here to analyze if it will be the future ;-)

Here are some KML files présented in map.geo.admin.ch

• Réseau de mesure automatique de Météosuisse
• Réseau des observations visuelles de Météosuisse
• Réseau pluviométrique de Météosuisse
• Patrouille des Glaciers
• Brevet des Alpes
• Tour de la Broye
• Haute Route
• Sentier du Tri - Yvonand
  

If you like Python, JavaScript, Maps and Cloud Computing, you would probably appreciate to work for map.geo.admin.ch.
One open position as Web Mapping Developer and Architect is available in my team (FR - DE)

Les technologies de l'information ont été utilisées pleinement par le PLR lors de la campagne cantonale 2012. Retrouvez ici un article montrant la diversité des moyens mis en oeuvre.

The Swiss Federal Spatial Data Infrastructure is growing continuously. In order to deliver its services to the 30'000 to 50'000 daily users, we are looking for two GIS specialists (job description DE and FR) and one trainee (job description DE and FR).
If you feel comfortable with Open Source technologies, if you would like to discover cloud computing, if you appreciate to manage data, these positions are probably for you ;-)
More info about the team.

My blog initiated an interesting debate around the 13 points I mentionned. You can read it in the GeoWebForum.ch. I of course disagree with some answers, but I think it's important to discuss these aspects.
Thanks to Stefan Keller,  Mark Wick, Ralph Strauman and Stephan Heuel

I tried the predictions exercise last year, let's try again ;-)

First 2012 geo prediction: WebGL for 3D portals (or the end of 2d web portals)
Always more 3D data are available. It's now time to publish them and I believe that it's possible to make web portals that combine 2D and 3D. And of course, all this will be supported by HTML5 technologies.

Second 2012 geo prediction: 4D
The world is 4D, GIS data, too.

Third 2012 geo prediction: OpenStreetMap will have a QA process
Data quality is very important and OSM will, hopefully, defines strong processes in order to deliver data with a known quality.

Fourth 2012 geo prediction: all applications in the cloud
Always more applications will be available in the cloud or will have pricing models based on cloud pricing models. And let's hope that public cloud will be used.

Fifth 2012 geo prediction: big geo data & linked geo data
The amount of geo data is always bigger. Location based services or sensors generate huge datasets. The traditional storage, treatments and analysis processes will have to evolve. Linked geo data are very important in order to make the web "geo aware".

Sixth 2012 geo prediction: mobile, mobile, mobile
Applications and services need to be accessible on mobile plattforms. I predict that the "desktop first" paradigm will evolve towards a "mobile first" paradigm since the majority of users will be soon on mobile plattforms.

Seventh 2012 geo prediction: social geo
Facebook or Twitter have offered recently to geo tag the statuses. This is a first step towards a wider usage of geoinformation within social media. Let's call it GeoSoMe ;-)

For a summary of last year:

YES - Second 2011 geoprediction: always more cloud gis applications
YES - Third 2011 geoprediction: the start of the end of heavy clients
NO - Fourth 2011 geoprediction: clear separation between web mapping and web gis
YES - Fifth 2011 geoprediction: geoservices for all and everything
YES - Sixth 2011 geoprediction: REST, RESTFull and (Geo)JSON
YES - Seventh 2011 geoprediction: WebGL will allow fantastic 3D applications

A very well documented article "The Street Network Evolution of Crowdsourced Maps: OpenStreetMap in Germany 2007–2011" compares OSM and TomTom datasets.
Here is the conclusion of this article with aspects that I consider as particularly important in bold:

In this article, we outlined the development of Volunteered Geographic Information in Germany from 2007 to 2011, using the OpenStreetMap project as an example. Specifically, we considered the expansion of the total street network and the route network for car navigation. With a relative completeness comparison between the OSM database and TomTom‘s commercial dataset, we proved that OSM provides 27% more data within Germany with regard to the total street network and route information for pedestrians. On the contrary, OSM is still missing about 9% of data related to car navigation. According to our projection for the future, this discrepancy should disappear by the middle or end of 2012, and the OSM dataset for Germany should then feature a comparative route network for cars as provided by TomTom.
In addition to the route network comparisons, we conducted further analyses regarding topology errors and the completeness of street name information. The results showed that the OSM dataset is not flawless; however, the trend shows that the relative and absolute number of errors is decreasing. Thus, it can also be discerned that not only is new data being added to the project database but also quality assurance is becoming a major factor within the OSM community. Our findings with regard to turn restrictions within the OSM database, which are of critical importance to navigation, showed that based on the current development rate and activity, it will take more than five years for OSM to catch up with the information found in the proprietary dataset used in our analysis. This slower development in comparison to the regular street data collection can have several reasons. It can be based on the fact that turn restrictions cannot be seen in the regular OSM map and thus are less appealing for contributors to be added. Some members might also not be familiar with the importance of turn restrictions for the dataset or do not understand how to implement them correctly.
Overall, a certain trend can be distinguished from our studies, as well as in all other studies conducted to date for the countries that were examined. Preliminary statements and conclusions in the past were that OSM data is sufficient for use with map applications. Today we can say that, at least in countries in which the OSM project is well developed, the data is becoming comparable in quality to other geodata from commercial providers regarding the different factors analyzed in this paper such as temporal accuracy and geometric accuracy.
However, several questions remain and further research is still needed. One important factor that has not been addressed yet is the importance of whether users who contribute data to OSM should also maintain it. Also, it is unclear whether missing attribute information, such as street types or names, if added at a later date, could be analyzed and provided useful insights. So far it seems as if processing within the OSM project is closely related to visual factors, meaning that most data is collected in areas where there are white spots on the map, and thus no information is available. We will investigate specific questions regarding this user behavior in detail in the near future. It will be important to obtain further information on the project‘s participants and data contributors. These are some of the questions that need to be addressed: Are OSM mainly long-term contributors or are most of them so-called ―submarine users‖; that is, do they appear for a short period, add information, and then disappear again? Do members only add new data, or do they also edit existing information? Can an activity radius or area be determined for the participants of the project? Is the administrative area of an entire country completely covered by volunteers of the project or are data contributions by agencies playing a major role in certain areas ?
It will continue to be important to carry out studies about the quality assurance of VGI. Preliminary suggestions have been made on how consistency of compiled VGI data could be achieved by improving quality during production and providing quality metadata for the users [43].