Hi. I often drop hints about what our project misses, and now want to talk some bit more about a part I'm interested in. Since I joined OpenStreetMap, I have been interested in geodata collecting methods. I quickly grasped walking papers, put my GPS and camera to use, and struggled with georeferencing audio recordings. OSM allows for many types of sources, and in past years a lot were invented. But alas, not much in last years.
Walking papers (or field papers) are still produced from tiles. Fieldpapers.org, the "modern" service for generating atlases, is more than two years old and is a slight update to older walking-papers.org, built in 2009. It stiches tiles and produces a PDF file. You have no control over map style, you can't even use your own tiles. "Toner" style, which is the best option, are updated infrequently: you might have to wait a week before traced buildings appear on it. And some of them still won't, since it's hard to grasp how it works and why it hides some features unpredictably. Finally, pages of an atlas will be oriented by cardinal directions, in a grid with 90° angles. Of course, not many towns have such proper road network, so you will have to choose smaller scale, with less effective area for mapping.
I think I can fix this. It is easy, really: most of building blocks for a proper solution are already invented. First, an interactive map, on which you place rectangles for pages. Arbitrarily, not neccessary in a grid. Maybe draw some lines, which would be "pie segments": instead of using MS Paint for making a pie, use some advanced technology. Maybe integrate it with MapCraft. So, a bunch of rectangles on a map. Not 90°-aligned: rotate them as you like. Align with road network, with streams etc, so areas for filling in take as much space as possible, and scale is biggest you can get. When done, just save your work and close the website. Go trace some buildings and tracks.
When a morning of a mapping party comes, open the website and press "Create atlas". It will display the progress, but the atlas will be made on a server asynchronously. First, it downloads an area from OSM API. Yes, not from a local postgis database, only fresh data. An added bonus (for local installation) is that you can use cached osm data, or just bring it from another computer, if an internet connection is weak. Then it applies a MapCSS style (which you can customize, even upload some of your own or josm's) and renders each page, rotating data as needed. Then it joins pages into an atlas and provides a download link. Later the atlas can be rebuild, using fresh data, maybe a different style or with more pages.
I don't believe in scanning pages for using them as a layer in JOSM (Bing/MapBox imagery make for a better reference layer), but georeferencing marks probably can be included. That won't be the greatest feature, because I have some other thoughts. You know the weakest point of the OpenStreetMap mapping in 2014? Updating data. It is quite easy to collect and map new roads, new POIs, new restrictions. But updating it is very, very hard, almost impossible for rich regions. There are no tools. My theoretical walking papers can fix that issue. Since we have full control over data, we can put POIs and relevant tags right on pages. We have a second side: for example, on the map there would be dots with coordinates (A4, D9), and on the reverse side — tags for each dot. And the same for ways and maybe relations (didn't think it all through, obviously). So you can have not only a base map for collecting new data, but also a check list for updating the already rich map.
This solution will make mapping easier not only in thrid-world countries (where internet is sparse and you can't rely on external web services, or spend days installing tile rendering stacks), but in densely mapped cities, where data has not been updated for years, because it already seems well-mapped, why go there again.
The next step would be an Android application for mapping. Why android? Because I again keep in mind mappers in third-world countries, who can get an android phone for $30, but not an iPhone for $300. So, let's take Vespucci. It is a powerful editor, getting better every months thanks to Simon. It can download an area and let you edit it. But can it work without internet and GPS? Not likely. Can it be used on a mapping party, when you are passing 10 points of interest a minute? You'll be exhausted in half an hour. The ideal mapping solution will have to separate data collection and data processing. Step 1: go out and record everything. Take photos, record audio, type a hundred house numbers, draw some crude lines on a touch-screen, like you do on walking papers. The interface should allow for quick mapping, e.g. in a car: you see a sign — you press a button and leave moving a mark to a correct place and tagging it for later. KeypadMapper and OSM Tracker are examples of this approach, but it should be made more streamlined and consistent. You cannot rely on GPS, for it has low precision, and not available on cheaper phones (off go those two apps). You cannot rely on the internet to provide you with tiles (off goes OSMPad). But you can assume you'll have a chance to download 100k of osm data back at home (or 10-20k on the road), to use as a base map for further mapping.
Step 2: Upload collected data somewhere (e.g. on your computer), process it and update the map. Data format can be universal, which means some central server for storing all the information. Audio notes can (and should) be converted to text, GPS trace joined from broken segments, data split between days and so on. Since most of points would be in tags or other non-textual representation, so anybody can use it for mapping, you would have an option of upload it to a server (right from your phone), so someone else could map it in their spare time. Or it could be you, download the data pack in JOSM. And then — map it. Recorded points shown as icons, with copypasteable tags; photos already georeferenced with subsecond precision, notes written on a map, crude drawings also georeferenced as underlying layers, between OSM data and imagery. It would be so much better then trying to remember what you meant by these waypoint titles, or having to read your handwriting on walking papers. And technical requirements would be as low as they get.
I am not a great programmer, or a designer. But I know what and how should be done to drastically improve mapping in OSM. No commercial company would make it, because they make profit not from mapping, but from using already mapped data. Hence loads of geocoders, routers, renderers, data converters, but nothing really good and innovative on editing front (sans iD, which was really lucky and sponsored by a grant). I really really want all I wrote above implemented. I want to push a button and get up-to-date walking papers with POIs for my street, to go out and find new amenities and update opening hours. After a long drive I want to run JOSM and add lane information, cafes, hotels and petrol stations, house numbers and surfaces I collected just hours ago to the map. I want to make OSM better, but I see no way these tools could be made. We all know the main principle of OpenStreetMap: "You want it — you make it". Maybe some wonderful person would start on that, but given my experience with mentoring "OpenSurveyor" on GSoC, it's not an easy task for students or even novices to OSM. Turned out having a 10-page design document means three months won't be enough.
All I know I can program, I know some of these technologies and will have little trouble learning the rest. Eventually I can finish all that. But as a spare-time job, between hosting an osm radio, writing news posts for shtosm, organizing mapping parties, disputing on osmf-talk and so on, progress would be very, excruciatingly slow. Not to mention I have other challenging ideas like writing a proper changeset reverting web service. So can you recommend me any way to make creating these tools my full-time occupation?
update: if some company (Stamen? Mapzen? Mapbox? Enaikoon?) decides to commit to one of these projects, I'd be happy to translate and update specifications.