heidi.sosm.ch moved

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 tech@sosm.ch

10’000 km of Ways added in 10 Months – New OSM Road Length Statistics for Switzerland

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.

Detailed Numbers

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_link 333 665  “
trunk 361 511  “
trunk_link 50 95  “
motorway + trunk 2’249 4’274
primary 4’798 includes _link
secondary 5’450
tertiary 10’919
unclassified 16’539
residential 23’576
service 6’590 service=alley and unspecified
driveway 720 service=driveway
parking aisle 782 service=parking_aisle
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
track total 52’883
path 19’183 neither foot or bicycle = designated
pedstrian 327
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
Total 152’373

 

Two Important Tagging Proposals Passed, but Nobody Knows.

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.

 

Experimental MapProxy Service

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:

We will consider further layers, we would however point out that in the current environment the capacity of the server is limited.