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.

The second project was a prototype of a geocoding and routing application based around the routing services and Leaflet Javascript Libraries. All questions placed on the Cloudmade developer support forums were left unanswered, as if there were nothing behind a good looking web site.

… See full entry

Conflicting methodologies

A recent discussion on the [osm-dev list] (http://gis.19327.n5.nabble.com/Renderer-issue-highway-service-and-service-driveway-tt5791858.html) 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:

• Highway
• Highway Tag Usage

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

1. 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.
2. 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:

… See full entry

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.

… See full entry

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

Update

I’ve put in a request to have the MobileFrontend framework installed on the wiki, (thanks aseerel4c26 ) and added to a similar forum request asking for suggestions on getting this project started

Update 2

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.

OSRM

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

… See full entry

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.

Roads

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.

Arroyos

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:

1. They are easily recognizable on imagery.
2. They are often named on maps, making them a good navigation aid
3. The beds are often as wide as riverbank mapped rivers.
4. They are important enough to require full-size rail and road bridges
5. Minor road crossings are often de-facto fords, with the same issues as approach angle etc.
6. They can seriously impede walkers and cyclists.
7. 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