Here the email I just sent to Scout/Skobbler:
I’ve had a look at Scout Signs. I agree that this is a comfortable way to collect maxspeed data. What I’ve compared in my region leads me to the following conclusions:
I would welcome if discussions regarding this plugin would happen in
the public, but regrettably there is neither a page for the plugin in
the OSM Wiki nor is it mentioned there nor is there the possibility to
discuss it at the place where you introduce the plugin.
Additionally it would be very useful to provide a link with the plugin
to be able to learn just something about it. Scout Signs is one of only
some plugins not providing any additional informations on plugin list:
(I sent a second email with this content):
PS: the following would enhance the workflow and usability, too:
¹ Examples where I could measure the offset:
Comment from RobJN on 3 January 2015 at 17:38
There is a page on the wiki for it here:
But don’t forget that it’s only beta code at the moment so hasn’t been officially released :-)
Comment from Skippern on 4 January 2015 at 14:52
This triggered my curiosity, but I am disappointed that I would need another iPhone app, and that it will not consolidate datas from other sources. It would be a nice addition if it could analyse Mapillary data, and extract speed signs (and other road signs for that matter) from that source. I am already preparing to gather even more Mapillary data as I find that very useful addition to MapBox satellite or even Bing for getting correct information on the map. If I need to have 4 or 5 iPhones to gather all the information useful for the project, than it will result in few or little data being collected.
Skobbler should have the data capacity to scan Mapillary for roadsigns on a regular basis. Which will leave me in peace to gather Mapillary, and other similar projects derive from there.
I had to check the skobbler blogpost about ScoutSigns to figure out how it works.
Comment from dekarl on 4 January 2015 at 15:11
There is also a database of georeferenced photos related to bicycle infrastructure at http://www.cyclestreets.net/api/v2/photomap.location/
Comment from RM87 on 7 January 2015 at 22:43
You can split the forest relations along the roads, railways, cutlines and power lines.
For example this area in Estonia had several big forest areas imported from corine: http://www.openstreetmap.org/#map=16/59.3301/24.2921 . Some of them have been split along the roads, railways and power lines to make the relations a little bit more editable.
If the forest is not fully coniferous and you do have either nrg imagery available or a lot of time for outdoor mapping, then you can split the forests further by separating coniferous, mixed and decidous forests.
Comment from RM87 on 7 January 2015 at 22:46
Sorry, posted the abowe text under wrong diary entry.
Comment from malenki on 8 January 2015 at 16:41
RM87, no problem. The funny thing is after reading the first six words I knew where you wanted to post this answer. :)
Comment from mvexel on 8 January 2015 at 21:33
Martijn here from Telenav. I am not developing the plugin but working closely with Bea who does!
First off thanks for taking the time to beta test. Because it is still beta, we hadn’t gotten around to creating a proper wiki page yet, but I have at least created a stub now. Feel free to use the talk tab there to provide feedback and suggestions as well. There should also be a link to this page in the JOSM description shortly.
I really like the suggestion for (optionally) hiding the signs where maxspeed is already present on the way - or perhaps only when OSM and the sign agree. We will look into this after we get the initial version out.
The CV algorithm processing the signs into speed limits is definitely not fail-safe - there is no such thing, unfortunately :) We did not see a lot of mistakes so far, but it’s definitely possible. (This is one of the reasons it’s a JOSM plugin and not some sort of automagical data processing / importing machine).
The offset from the actual sign position is perhaps confusing initially but expected if you reckon that the camera position is recorded at the time the picture is taken, and not the sign position (which is unknown). I don’t think it’s a huge deal, but if it turns out to be an issue we can look at ways to mitigate.
As Skippern mentions, a collaboration with Mapillary would make sense, and we have that in the works, so expect to see that sometime soon.
Feel free to drop me a line (or ask on IRC) if you have any other questions or feedback. Excited for this plugin to go live!
Comment from malenki on 10 January 2015 at 17:18
thanks for the reply. Bea and I exchanged some more emails and sorted everything out so far I think.
What bothers me with the offset of the scout signs placements to reality is that I assume there will be some mappers who “correct” the data in OSM to the scout signs. Since there is already an offset of 20+m at 30km/h (where I know the location of the sings and could measure) I’d assume a quite bigger offset on higher speeds.
Comment from mvexel on 7 July 2015 at 20:36
malenki - this is something that we plan to address in a future release. As always ‘armchair’ mappers should be careful with any information that is not based on own survey, just like with Bing imagery etc. So it’s not really plugin specific - otherwise I would consider adding a notice.
In the mean time, we added Mapillary support in the latest release - let me know what you think.