Recent diary entries
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