Recent diary entries
We all know that while we have over a million, actually over 1.2 million now, user accounts, the number of actual contributors is quite a bit lower. Often you will see a number of 200'000 quoted, however that only considers the last editor of an object and not all the editors.
Analysing the mid May 2013 changeset dump gives a total of 335'000 unique user ids that have created a changeset. We can see this number increasing more or less linearly in recent years:
Over the last 12 months we have averaged roughly 7'000 new contributors per month, in total a good 80'000 per year:
The numbers only take half of May in to account so it is too early to see if the announcement of the iD editor will already have a noticeable effect. In the long run we hope for a clear increase in the number of account holders actually contributing.
May 2013 numbers now for the whole month, based on the early June changeset dump. Total number of contributors 340'311, new in May: 9357 While this isn't a new record it is a good 2nd place.
With Samsungs recent drive to increase screen size to enormous levels :-) a lot of OSM Android apps have run out of screen real estate that they can reasonably use. Luckily it is trivial to add support for Samsungs multi window facility (IMHO currently available on the Galaxy SIII, SIV, Note, Note II and Note 10.1) without impacting compatibility with other devices.
Adding support is so easy that it doesn't make a lot of sense to provide patches see http://www.modaco.com/page/news/_/android/developers-add-support-for-samsung-multi-window-to-your-apps-r823 and http://developer.samsung.com/s-pen-sdk/technical-docs-09.
OSMAnd has just added support, and I have patched OSMtracker and vespucci versions available.
Note: I have no affiliation with Samsung other than owning a couple of their devices.
The weather in Europe is currently less than great and I took the opportunity to spend some time this weekend adding support for relations to vespucci, the Android OSM editor.
This is currently only a minimal internal support implementation to stop vespucci from breaking relations when editing nodes and ways, however could easily be extended to allow creation and editing of relations in vespucci itself.
If you want an alpha level version for testing again the dev API please send mail to my OSM account.
The "no address" layer on qa.poole.ch now highlights landuse=residential layers that don't contain addresses. I originally intended to do this based on address density, but that doesn't seem to make a lot of sense at the current point in time.
Here an extreme example of how the new layer looks near Atlanta:
You can see bits of green on the above map from the new "has address" layer that highlight buildings and nodes with addresses. With the B&W backgroud you can get a good overview of where we actually have addresses:
More information can be found on the wiki.
One property that differentiates the noaddress layer on qa.poole.ch from other similar layers is that it checks for address information on nodes inside and on the building polygons. This is trivial, ST_Covers for example should return true if a node is in or on the polygon, but, a tiny bit suprising, didn't work with a standard (srid 900913) osm2psql imported database.
select St_Covers(p.way,n.way) from planet_osm_polygon p, planet_osm_point n where p.osm_id=26681434 and n.osm_id=1946037917;
returns false even though node 1946037917 is one of the nodes used to construct the building polygon 26681434.
On inspection of the data in the database the issue was glaringly obvious: the nodes in the planet_osm_point table had a lot more decimal places than the corresponding coordinates in the polygons. This is simply due to the polygons and ways being constructed from the node cache that scales the coordnate values so that they fit in a 32bit integer. In the process the decimal places get truncated (note that there is no loss of information since the main database schema stores the coordinates scaled as 32bit integers anyway, the extra decimal places are likely a result of reprojection for the import).
The fix is easy: simply scale the node coordinates the same way (and back) before inserting them into the database.
If you have a database imported in the standard spherical mercartor projection you can truncate the existing coordinates in planet_osm_point with the following SQL and don't need to reimport (you'll need to get the patched osm2pgsql version from the OSM svn too naturally):
update planet_osm_point set way = ST_SetSRID(ST_MakePoint(trunc(cast(St_X(way) as numeric),2),trunc(cast(St_Y(way) as numeric),2)),900913) ;
I've added a 2nd layer to qa.poole.ch that highlights building outlines for buildings that have neither addr:housenumber or addr:housename tagged and don't have a node with such tags inside or on the outline.
Minor buildings (hut, garage, garages, rood, terrace, greenhouse and shed) are currently rendered in orange, however I may suppress them completely in the future.
The check for a node in or on the building outline is computationally rather expensive leading to the layer not being as fast as the noname one. Zoom 0-12 are regularly re-rendered in batch mode.
Naturally in some areas it is common to not have building specific address information, we are currently missing tagging to suppress such false positives. I'm planning on adding support for addr:interpolation and some further addr tags that are not so common. If you have any susgestions please leave a comment.
Added support for addr:conscriptionnumber, addr:full and addr:interpolation. Note that this currently makes the layer substantially slower at lower zoom levels.
I've set up an experimental noname layer at http://qa.poole.ch/ .
It differs a bit from previous attempts in that it respects noname and unsigned tags (that have never become popular) and is generated directly from a synchronized database. Currently changes can be expected to show up in roughly 5 minutes.
- red: major and minor roads, service with service=alley without name or ref tag
- orange: unspecified service, unnamed roundabouts, motorway_link, trunk_link
- dashed red: unsigned=yes
- dashed orange: unsigned=yes and/or noname=yes
update 28th October 2012
- render motorway_link and trunk_link in orange. There is currently no clear way to tag such roads in the absence of explicit sign posting.
- reduce line widths at lower zooms
update 16th November 2012
- render *_link in orange.
- support validate:no_name=yes as synonym for noname=yes and validate:no_name=no_sign as synonym for unsigned=yes
- note: only zoom levels 0-9 will be automatically re-rendered
update 26th November 2012
- support name:left amd name:right as valid name tags
- note: only zoom levels 0-9 will be automatically re-rendered
I've added a short and somewhat incomplete review of the ContourGPS to my wiki user page: http://wiki.openstreetmap.org/wiki/User:SimonPoole#Video_Mapping_with_the_ContourGPS_Helmet_Camera