The virtual machine (heidi.sosm.ch) running the SOSM web site, mail server and the mapproxy service has moved to a different host machine. If there are any issues please send mail to firstname.lastname@example.org
The last numbers on development of the OSM coverage in Switzerland were from early 2012. Since then we have had on the one hand the licence change process with a small corresponding loss of data, and on the other hand quite a lot of interest in the project as a whole. So I beleive an update is in order. While I didn’t use quite the same methodology as the previous numbers presented in the wiki here, they seem close enough to be comparable.
The statistics show an increase of a total of at least 10’000 km from 142’000 km at the beginning of the year to 152’000 km now. This without taking a further 8’000 km of “service” roads in to account that were not listed separately in previous statistics. As would be expected the length of all roads with higher classification does not show much movement, a clear indication that the major road network is very complete.
The low number for the length of combined footway/cycleway would seem to indicate that we are mistagging the most frequent occurring type of cycleway.in Switzerland. What is further slightly surprising is that we have mapped a combined length of 1500 km of driveways and parking aisles, this would seem to be an awful lot compared to roughly 1300 km of cycleways.
|OSM classification||length (km)||length (km)|
|motorway||1’505||50% of the length of one-way segments||3’003||one-way segments counted fully|
|motorway + trunk||2’249||4’274|
|service||6’590||service=alley and unspecified|
|track||12’254||tracktype unspecified, neither foot or bicycle = designated|
|track grade 1||9’461||neither foot or bicycle = designated|
|track grade 2||17’220||“|
|track grade 3||9’588||“|
|track grade 4||2’627||“|
|track grade 5||1’733||“|
|path||19’183||neither foot or bicycle = designated|
|footway||6’506||plus path and track with foot=designated|
|cycleway||1’078||plus path and track with bicyle=designated|
|combined cycleway / footway||250||track, path, cycleway and footway either with explicit or implicit designated values for foot and bicycle|
Browsing the German OSM forum today I noticed that the OSMAnd android routing app developers were asking the community for an opinion on which “lane” tagging proposal to implement. My first reaction was: well didn’t such a proposal pass just a while ago and why on earth don’t they know about it? But on reflecting a bit, I had to admit, that I probably really only happen to know that we have a fully functional lane tagging scheme by accident.
Our tagging proposal and voting procedure has often been belittled and is the target of many jokes. Myself being one of the larger offenders in that respect. It can be argued that for the typical “I need a value for tag X that doesn’t exist” situation it just leads to massive bike shedding instead of quick resolution. I have at times simply started documenting and using a tag completely ignoring the proposal process (see mofa).
However we have had two long ongoing disputes in areas that impact usability mainly for routing applications where a unilateral decision without community and developer buy in hasn’t worked: lane tagging and conditional restrictions.
While the effort to support the three or four different ways of tagging a cycleway in a style sheet is small, expecting all routing applications to implement the 3 or 4 different lane tagging proposal was and is just unrealistic.The usual tiebreaker that the more sucessful in day to day use proposal wins (the voting with the feet principle) doesn’t seem to work in such situations. As we all know adoption and widespread usage of a tag in OSM is mainly driven by either being able to see it directly on a map or by it having direct effect on applications. Particularly with lane tagging this has led to a classical “hen and egg” situation were lanes have not been tagged because the tagging was not being utilized at all.
We now have resolution, as far as we can ever have resolution in OSM, in two significant areas of tagging. The missing piece of the puzzle seems to be simply to make our contributors aware of the change. A long time mapper that doesn’t follow the tagging list and has never mapped lanes is not going to magically look up the lane tagging guidelines the next time he adds a street, he will just carry on with his established way of mapping.
OSM lacks a method for actively getting this kind of news out to contributors. The closest we get right now is tweeting, but that only reaches a small percentage of the community and in the past hasn’t been used for such mundane news. I’ve done some thinking about extending the OSM API to include access to the users “inbox” and some kind of system wide message system that could be used by editors to display such messages on start up. However until such a system is implemented and adopted by third party developers we will need to use Twitter and our blogs to get the message out.
We have a number of sources of aerial imagery available in Switzerland that are accessible by so called WMS servers. JOSM supports such servers directly, but P2 (the editor imbedded ob the OSM map page) users and users of a number of mobile apps cannot access such data.
Additionaly in some cases the imagery is not available in the “Spherical Mercator” projection that most OSM tools use as default.
We now have, on a test and experimental base, a MapProxy instance running that supports reading imagery from WMS servers and serving this as Google/OSM format tiles, reprojected if necessary.
Up to now we have added 2 layers:
- City of Uster 2008 10cm resolution aerial imagery
- the city map of Zürich, released yesterday during the opendata.ch 2012 event
We will consider further layers, we would however point out that in the current environment the capacity of the server is limited.