Recent diary entries
Over the last couple of years, I've made use of a couple of OpenStreetMap based projects, both on a personal and professional level. While the projects themselves were very different, the supplier for the software was the same, Cloudmade Software
The first project is the Android based application, MapDroyd This application had all the makings of a superb offline mapping application, with stability, regular delivery of updated maps and a strong following. The benefits of offline mapping here in rural mountain states USA cannot be emphasized, with phone and data service being spotty and often non-existent, depending on the carrier, making Google Maps useless. Incidentally, Open Street Map holds a serious mapping quality lead in rural areas, Google still relying on unmodified years-old Tiger data in some places.
About 18 months ago, Cloudmade ceased updating the maps but left the application up on the play store with increasing numbers of complaints, leaving those of us attached to the product, and who had worked to improve local mapping quality lost.
A recent discussion with a committee member of "Denver Sister Cities about delivering technology to support the gift of a utility vehicle to Axum,Ethiopia had me thinking about the product again. With seriously spotty phone coverage, the problems of Africa are embarrassingly similar to those here in the rural areas of the USA. An offline map product available to cheap Android platforms should be a winner.
Ultimately, the question is: Does a commercial company hurt an Open Source projects standing by failing to deliver a promised value-added product based on that project. Personally evangelizing for open source solutions as an alternative to strictly commercial implementations can be damaging professionally when the delivery of the product fails to live up to the promise. To the layman, the fortunes of the underlying project and the value-added provider are inextricably linked, as in, "The OpenStreetMap data is good, but we can't rely on company xxx, so we're going with Google".
A recent discussion on the osm-dev list highlighted the difficulty in using the main Highway page as a basis for understanding how to map highways outside the core areas where most OSM mappers are found, i.e. Western Europe and the urban areas of other industrialized nations.
The focus of the discussion is primarily the setting up of the Highway Tag Africa page, and objections, based on the assertion that global standards should be defined in the main page, and applied world-wide.
Where theory and practice are incompatible
The problem, however, is that the standards that appear in the main pages are almost exclusively based on the road system in the United Kingdom, a country where every road is paved, well-signed and well-maintained. See for example:
Did you see an unpaved road on those pages? No, you didn't.
Now have a look at This Chart, Even the USA has only 68% paved roads, and for Australia, the number falls to only 38%
Consequences of the current methodology
- As the number of unmapped paved roads diminishes in countries with higher proportions of unpaved roads, and mappers turn to mapping smaller roads, confusion ensues when trying to associate the necessary level of highway with the physical state of the road. In the end, too many usable roads are mapped as tracks, making them unavailable for mapping/routing software.
- Numerous country-specific sub-pages are spawned, each attempting to shoehorn the standards set out on the main page into a countries road system. see:
- USA Road Tagging The Page is divided into sections that cover some of the states requirements, each discussed in a separate manner, and the talk page includes unresolved pleas for help going back to 2009
- International Equivalence In Canada and Brazil, indications are that urban areas follow the guidelines established on the Main Page, but rural areas follow the scheme broadly similar to the Highway Tag Africa proposal. The page itself has entries in numerous languages, making standards comparison impossible.
- In Australia Road Tagging, the road numbering scheme standard is defined in a government document, which is no longer available at the target URL
A Proposal for a series of standards
- The Highway Tag Africa definitions for roads are based on socio-political rather than road-surface/speed/width standards. These can be broadly applied to roads in all Nations. This should be the basis for the Highway page.
- The existing Highway page should moved To a Highway_Tag_United_Kingdom and modified accordingly
- The numerous pages associated with road standards should be combined/cross-linked
- The International Equivalence should be translated to English, and mappers encouraged to provide full translations of the page
- A standardized country specific highway template should be designed.
- A consistent methodology of linking these pages should be designed, so for mappers who want to understand how to map roads:
- Go to the highway page to understand the core concepts of highway mapping
- A link to the international page allows the mapper to find the relevant Nation/Continent. Consistently translated pages allow the mapper to get the correct links
- A nation/continent page shows the mapper how to apply the global standards at a national level. The goal is to dissuade the mapper from defining standards at a micro/local level
- For areas with autonomous authorities, such as USA, the highway template can be reapplied at a state level
Mapping of roads is a key portion of a beginners' mapping skills, and an organized, consistent set of documentation is essential in order to avoid needless mistakes and conflicts in methodology. A revisit of the core documentation for this function seems appropriate in light of the ongoing conflicts identified in the opening paragraph of this posting.
In an Earlier Diary Entry I asked the question ''Given the focus of current mapping towards use on mobile devices, Why is there no proper mobile version?'', which drew the normal response from contributors to any Open Source project, i.e. 'If you don't like it, do something about it'. So, excepting the fact that I've never written a line of code in Ruby in my life, I'm trying my best here.
For a starting point, I'll introduce an issue on the main openstreetmap.org bugtracker 'No search on mobile style' , opened up over 7 months ago, and still unresolved. The issue reports that the search facility on the OpenStreetMap landing page is unavailable when loaded on a mobile device, i.e. a Smart Phone, not a tablet. What this issue really is, is that when a browser screen width is a bit smaller than an iPad or Kindle, the design of the main page at openstreetmap.org forces the sidebar on the left off the screen into invisibility and inaccessibility. This reduce the usability of the map page by 95%. As all of the search bar links are missing, the user of the device is pretty much stuck. Conversely, the edit link is available, which offers a number of options which don't work on phones. The overall effect of this is the user is presented with a pretty unsatisfactory experience.
The general thrust of the response to the questions raised is that the presentation of the landing page data is going to change in the near future (see SOTM 2013) so why the put the effort in. However, what value would be gained by making a Smart Phone level browser interface compatible with the main page? (tablet yes, but smartphone no). It may be counter-productive, a distraction to developers to try to add the compatibility required into the product. Who would want to edit data in a smartphone based browser anyway? Data accumulation can be done with apps, ready to 'bring home' and be edited with a full-size editor.
A visit to openstreetmap.org on a Smart Phone device has no need to be a rich, fully featured experience. It just needs to be a teaser, a tempting look at what might be available. Unless the decision is made to compete with providers of maps, with its associated bandwidth requirements, a simple map, comparable to the existing landing-page but designed to fit within the size constraints of Smart Phone is all that is required. Links to mobile-device enabled versions of the websites like the Forum and Wiki would be useful, and possibly Social-Media links.
From another perspective, a reasonably well structured mobile site can give insights into what users are looking for when they arrive on the openstreetmap.org. Tracking their movements through the page clicks can help show where the focus of 'marketing' could be.
I've put together a prototype of a simple openstreetmap.org mobile website. Specifically designed to be used on phone-sized devices, but tested only on my personal phone, a Samsung Galaxy S3, it's just designed to show the concepts, not be an answer to issues I've described here, but It's also a reminder that by use of a few frameworks that we could do better right now, without waiting for changes to the 'big picture'.
I've been mapping for 8 months now and I never realized that the android app osm tracker existed. It took a night of insomnia away from home trolling through pages deep in the wiki to find it. It needs to be on the front page. The front page, incidentally is a nightmare to read on a phone sized screen. Why is there no mobile version? The focus of use for the data is very mobile oriented so the project should present at least a basic mobile interface
Posting the question on the forum led to a suggestion that it be posted on the dev mailing list. A discussion on that list evolved into a review of a video upcoming product development at at State Of The Map 2013 of which I remain skeptical, but also a request to obtain some server log analysis from openstreetmap.org. As an old-school IT professional, I've always felt that whilst unfettered, imaginative, proactive R&D should never be restrained, good money and business relationships can always be made by giving the customer what they already want.Some logfile analysis to find out how and why people land on openstreetmap.org when using mobile devices should give some insight about how a mobile interface should do. I'm letting this diary entry go dormant for a few weeks while logfile data accumulates.
The Open Source Routing Machine is a great way to check consistency of tagging along a long stretches of continuous road. Mistakes in the tagging such as typos in names and refs appear as changes in the route, and it will also show where the tag change appears.
The 'ref' tag
OSRM uses the ref tag by preference to display the English language description of a route, e.g. "turn left onto CO 50", so it makes a lot of sense to get the correct information here.
A 'real world' example
Passes & Canyons is a Colorado motorcycling website/blog. It offers information on day trips on both paved and unpaved roads. One of these is Cuchara, Colorado to Aguilar via Gulnare. Here is how the web site describes the route:
(Huerfano/USFS(San Isabel) #415,#416/Las Animas #48.0,#46.0,#43.7) Cuchara to Aguilar AKA Apishapa River Road, Cordova Pass – approximately 33 miles.
From Cuchara take CO 12 South past the ski area to the top of Cuchara Pass. Turn east on the dirt road (USFS 415, but may also have a Huerfano county number). This road changes number several times but if you stay on the main road at all intersections you should arrive in Aguilar.
Note how vague the description of the road numbers are.
By using OSRM to check the consistency of tags, here's how the section of the route from Cucahara to Gulnare is described: A link to the route is Here
Distance: 51.2 km Duration: 1 h 3 min [Generate Link] [GPX File]
Head northeast onto 5th Avenue 24 m
Turn left onto City Avenue 53 m
Turn left onto CO 12 9.54 km
Turn left onto FR 415 / CR 364 9.99 km
Continue onto FR 415 / CR 46 8.63 km
Continue onto CR 46 18.9 km
Turn slight right onto (46) 4.13 km
As shown, using the 'ref tag' allows OSRM to offer a consistent naming scheme. The Forest Road number (415) stays the same, but the County Road number changes as the road crosses the County line from Huerfano to Las Animas County, then the FR number disappears as the road leaves the San Isabel National Forest. The (46) on the last section indicates an error that I have not yet corrected in the 'ref' tag for that section.
Incidentally, Google Maps can't even map this route. It only offers the paved routes via La Veta or Trinidad
Firstly, it's not an insult, I'm a European myself and had no concept of what the landscape looked like before I arrived here. As I've spent the last few weeks mapping rural Colorado, I've really noticed a few things that right now I am having real problems with. I'm going to try to list them out here, maybe expand these diary entries out as I work these out.
Is it 60% of Colorado roads that are unpaved? something like that. I've a lot more to say, but gotta go to work, back later
Rural route numbers
I've been ref tagging County Roads as "CR 123" but it seems some are tagged as (123). Some routes also have Forest Service numbers which are important and I think these should be ref tagged as "USFS 123". These could be extremely useful navigation aids.
An important part of the Colorado landscape. I've mapped them out as intermittent streams (which is what they are in some sensed), but I've experimented with using riverbanks to tag them. (see Ludlow, Colorado). I think they are important because:
- They are easily recognizable on imagery.
- They are often named on maps, making them a good navigation aid
- The beds are often as wide as riverbank mapped rivers.
- They are important enough to require full-size rail and road bridges
- Minor road crossings are often de-facto fords, with the same issues as approach angle etc.
- They can seriously impede walkers and cyclists.
- They are extremely dangerous in flash-flood season.
Mapping them out as rivers seems wrong, but there seems no alternative
As part of the East Peak fire area update, I've been drifting off into rural Colorado, firstly, Archeluta, and then Branson. After completing Branson and checking with G***le to see how good theirs is, seems they are using the unmodified Tiger data for their maps, and that there is a way that OSM can be better in rural areas. When are they going to send there Priuses down dirt tracks to map out these places?
I'm now working on the East Peak Fire, trying to help with the wiki page
Been Helping Mapping Buildings and access roads
Got the Belleview station road access sorted. Google now a few months out of date