Recent diary entries
You may have noticed that the 0.9 Vespucci release (see http://code.google.com/p/osmeditor4android/downloads/list and on the google Play Store rsn) has an experimental geo-referenced photograph overlay:
this is already very helpful, you can walk around surveying then sit down in peace and quite, enter the information that you have collected and upload right there. Vespucci does not support taking photographs directly (yet?) so I'm doing this with osmtracker. Now and then it isn't really clear in which direction the photograph was taken and it would be helpful to have that information available too.
Most mobile phones today can measure magnetic fileds and have what used to be called a compass :-), however there don't seem to be any (or at least none that are well known) apps that add this information to the picture EXIF information (there are a couple of Android "features" that need to worked around to be able to do this). In any case I hacked together a modified version of osmtracker that actually does this today and made the necessary changes to be able to read the information in Vespucci and this is the result: the rotated camera icon is pointing due east in the direction I took the photograph (of some grass so I'm not showing -that- here :-)).
There is still some work to do to make the actual photographing more robust, for example rotating the mobile phone into landscape mode will mess the compass reading up in the current modified osmtracker version, but the concept seems to have some merit.
We've moved the translation mangement to transifex (the same platform used for iD): https://www.transifex.com/projects/p/vespucci/ .... the sooner we hve at least the major languages complete the faster we can release.
We are nearly ready for a release of Vespucci 0.9, the translations have to be updated and, more important, some more testing needs to be done. Head over to Vespucci Home for the current beta build.
Here's a short video showing the new features.
Maybe some can remember that I produced some statistics on per country address counts end of March this year. I've rerun the scripts twice since then see http://qa.poole.ch/addresses/ .
What is naturally interesting is not so much the absolute number of addresses we have in the database (we know that we are just at the beginning of collecting addresses), but how fast are we adding them.
The full numbers can be seen on the website linked above, but for a quick comparison here are the overall numbers, Germany and the USA (which has had some address imports lately).
2013-03-27 2013-05-03 2013-07-13 Increase since March Total 20'168'470 21'072'447 22'939'124 13.74% Germany 3'659'043 3'836'410 4'144'198 13.26% USA 2'090'893 2'122'662 2'277'269 8.91%
While obviously the numbers are still quite small (the number for Germany is roughly 10% of all addresses there) I believe it is encouraging that we are adding substantial amounts even without large scale imports and do not depend solely on addresses becoming available as open data (which will not happen everywhere).
I suspect that nearly everybody has heard that google has acquired waze for a substantial amount of money.
While waze has historically made noise about generating their own map and have occupied a substantial part of the mind share in the crowd source data space, the effort seems to have never really beared much fruit and inspection of the maps has mainly uncovered third party sources. Still, in the heads of potential consumers and contributors to OSM, waze has continued to be present as a OSM competitor.
The acquisition by google will remove waze from the equation leaving the well known players and OSM as only visible and viable players at a global level.
Very often, if not always, in such high visibility corporate acquisitions, the resulting construct is less than the sum of the individual undertakings and it is not unheard of the net result in the long run ending up smaller than the size of the larger player in the beginning. Now that is unlikely in this case, but on the other hand, just from a numbers point of view, waze is just a pimple on googles user base. Naturally the constructors of such deals are not stupid and it is more likely, regardless of what google say in public, that this was not about acquiring additional market share and technology but more denying that a competitor.
Waze has had in the past had an enthusiastic and loyal community that in the end is mainly responsible for its success, I believe it will be very difficult for google to maintain that community in its context and given the complete integration of waze that will happen regardless of any statements now, it is likely to fall apart in a short time.
Any way I look at it, the google-waze deal opens up opportunities for companies and organisations in OSM-space to provide similar crowd based traffic reporting and avoidance services and to fill the void left by waze.
This is really good news for OSM.
I've added support for adding turn restrictions in the branch of vespucci I've been working on, nothing fancy and rather straight forward.
Select the "from" way
Select "Add restriction" from the drop down menu
Add the "via" and the "to" elements:
Then set the restriction type and you are finished:
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