Recent diary entries
today i ,made a bar and mapped 2 houses as well as make a bank and other things. this was really fun but i'm tired of it so i'm writing in this diary entry. it is super fun to type, more funner than making maps. YYAYY! we are taking a group picture, i'm so ready to rock it. the lady is so AWESOME shes going to the white house and she may meet Barack Obama! im so excited.
Hi there, I just wanted to point out that for the next step in providing high quality data to OSM, we at Mapillary are preparing to close the feedback loop for the algorithms not only on the mapillary site with blurring etc, but for potentially all other objects like street signs (more to come). You can soon tag things as points and rectangles in MapillaryJS, thus providing feedback on things that are good or bad, and even tag things yourself that you need in your own data, all in the 3D visual environment of MapillaryJS.
There also is a pull request pending for getting MapilaryJS to show up in iD for better visuals than the existing static images to start with so stay tuned!
A set of turns bypassing a roundabout I reconfigured recently was disliked by OSRM, instead sending the cars via the actual roundabout:
Daniel Patterson @ OSRM #2421 directed me towards a debug OSRM map showing that the roundabout links without ''maxspeed'' tag were categorized with default speeds of ~25 km/h (~16 mph) while the roundabout tagged with 20 mph (32 km/h) provided a faster way.
So, take a look at http://map.project-osrm.org/debug/ if OSRM seems to ignore a better route.
I can see a lot of places on the map in the cities, where there are one way roads, but no sidewalks set. That leads to incorrect pedestrian and bicycle routing in http://openrouteservice.org, osrm, and other navigational software. So please, don't hesitate drawing ways marked as highway=footway + footway=sidewalk along streets (of course where sidewalks actually exist). I already started doing it in russian cities Moscow and Tula.
Together we'll create the best map!
Missing Maps is currently engaged in motorcycle mapping of the entire border regions between Sierra Leone, Liberia, and Guinea. Here is an excerpt from my trip report from the first recruiting and training mission to Sierra Leone. Trip Report - Phase One
MISSING MAPS – FREETOWN, SIERRA LEONE, 29th APRIL – 8th MAY 2016
FIELD MAPPING COORDINATION by Rupert Allan
Training of Field Team Leaders in preparation for recruiting Volunnteer enumerators and performing Sierra Leone Mapping Project
Aims and Objectives:
As MSF consultant, deployed for the training of pre-recruited Field Team Leaders for the Missing Maps Border Project this training was designed to prepare FTLs for Volunteer Recruitment, to initiate the survey project, and to establish possible links and contacts by which to implement the phase two return visit. Prior to the trip, an important part of the project became the establishment of definitions of admin levels which could bring data-sets usefully in-line with those gathered in the Liberia and Guinea. Using FTL feedback,necessary adjustments were made in the field in order to leave a workable community survey prototype survey form as a guide for recruiting and training.
Day 1 (Wednesday, 4th May)
Red Cross Introductions (Abridged due to time constraints) Hand-over to Rupert Presentation: Missing Maps Introduction (the global picture) Descriptions and locations using and evaluating map-reading skills ('Where am I from?') Introductions to Smart Phones, Presentation two and Introduction to ODK Introduction to OSMAND and tracking Study Of Maps, Home Address and Admin Levels, and FTL Introduction to their 'Territory' Subsequent Discussion of Area Coverage for each FTL, and Personal Field Survey Boundaries to be completed as homework Discussion of Missing Sections in Survey and Listings, to be completed as homework
Day 2 (Thursday, 5th May)
Group Presentation of Survey areas, and work plan concept. ODK forms, and initial data-collection of Red Cross Moto, Locations and Guesthouse forms Demonstration of form after modification, and tweaking Recruiting Volunteers, Refresher on ODK – Group Work, evaluation, and commentary Connectivity, Uploading and Servers Demonstration with Edison ODK Aggregate Local Community visits – into 'Slum' Area (counter-productive to some extent because of orchestration of community meeting, but valuable nevertheless) Ad-hoc surveys taken on return from 'Slum' Surveys – much more useful as an exercise. Round-up and Close
Day 3 (Friday, 6th May)
Review forms and techniques Head out to rural area (This was too far away, and took up valuable classroom time. We finally did our first survey at 1230hrs, having called candidates for 0730hrs!) Demo Interview with Community Head Split off into groups around community Re-convene, evaluation, good feedback on 'close-down/termination of interview' work-arounds. Road/Travel barrier survey on return (Photo Option Used) Travel Back, and Debrief More Practise Sessions and Q&A about field Prep Red Cross Briefing on Branch Officer/Local Protocols Random Tutorials (e.g. Phone Tethering, Wireless Hotspots, Tech Hardware Interface) Course Feedback End
Course feedback was very good, which was satisfying. The prep-time allowed me by the delays proved to have been well-used, and I was extremely encouraged by the week's progress. I have high hopes for the FTLs, who are already demonstrating initiative, creativity, dedication and commitment. The WhatsApp group I have set up is well-used, and serves as a Log of Activity, as well as a meeting point across cultures and job-roles. Overall, it was soon realised that ability and capacity amongst FTLs was probably better that those recruited in both Guinea and Liberia. FTL selection was probably easy, as it was clearly done on the basis of Red Cross members who had been in Community Outreach (Mobilisation) and Logging (Data-Collection) during the Ebola Outbreak period. FTLs had used Android-based apps before for the implementation of the 'Safe and Dignified Burial' Program, and were familiar with ODK-style interface, due to some familiarity with 'Magpie'.
Motivation and project ownership were seen as important for the development of good practice, and I attempted to engage the candidates in some advanced activities such as Data Submission, Device Optimisation, and Form-Building Admin/Div discussion.
As a result of this, I am confident that the current prototype form deals with admin levels effectively, as I was able to adjust and trial the questions with the FTLs during field trainings, adjusting in the evenings. I saw this as a great achievement of our training week, a week which was punctuated with stark reminders of what the FTLs and their communities had been through in their battle against the terrifying Ebola disaster.
The Public holiday issue was worked-around. Generator: Sometimes and issue, as always, in class. MSF overnight charging and internet was an issue. (Generator in MSF House off between 0000hrs and 0600hrs.) Projectors were used in tandem – one for presentation, the other for phone demonstration. The method of linking it with my Sony Experia Z1 was very very useful for teaching. I benefitted from my own personal investment of two Experias. (we couldn't figure out the Blu Phone interface, but only because we were rushing) I bought some cheap USB 12v - 5v chargers from the 'Pound Shop' in London, which I gave to the FTLs in their packs to trial on the motorbike batteries. I am awaiting feedback. Each FTL was given a pack of stationery, a set of maps (waterproof ink on plain paper, for annotation-capacity), and a waterproof Map-Tube. I also gave them each a backup USB with all classroom and form versions on, after careful consideration of their technical abilities. I will use their responsible use of these to evaluate further delegations of equipment, tools and skills during phase two.
In conjunction with agreed initial Red Cross terms of reference, I am recommending that we maintain our initial plan to reconvene with our Field Team Leaders on 30th May for a de-briefing day or two.
Subject to adjustments from the Hub and/or American Red Cross, we then meet with all of the volunteers gathered, and enter the selection process of shortlisting and Field Training during the week leading up to Friday June 3rd.
It was agreed that volunteers recruited by the FTLs would number approximately twice the number needed (i.e. sixty). These volunteers will need to be brought to the capital, housed, and those not selected compensated and returned. The remaining selected will then need to be housed and provided-for for the rest of the week.
On Saturday 4th June, all those participating will need to be transported back to trainings in regional areas, in which MSF trainers Pete Masters, Nick Allen, and Rupert Allan will provide field-support across the districts, individually based in Kenema and Kambia MSF facilities. It should be noted that extra support will almost certainly need to be given to the Bombali District, where it feels as if we are short-staffed. FTLs Mohamed and Sulaiman are attempting to combine coverage of this area between themselves. It may be that requests are made for extra volunteers.
Here is some video footage of Red Cross reportage on Sierra Leone's Northern Border in Kambia District: [Kambia Border Challenges][https://www.youtube.com/watch?v=6BAdHR37bHI&feature=youtu.be]
Finally, the project for importing the municipalities limits is finished. It took longer than expected considering some of the issues that arose during the project. First I would like to thank all the members of the team, and also to the volunteers who helped the team when doubts and issues arose.
Importing official data to OSM seems like a simple task at first, and it is up to certain extent,but when the amount of data is not that big, however when we talk about all the municipal limits of the whole country like in this case, problems might arise.
First problem, data availability. Before we started with this project (previous to 2014), the geographic data from the Mexican Government weren't open. there was the possibility to get them for academic or personal use but using them in a project like OpenStreetMap required overcoming a series of legal gray areas which no team would be willing to deal unless they had the resources to tackle it. The best example of this case is Google, the team from Google Maps has used Mexico's official geographic data (that means the databases from the INEGI) throughout the years, nevertheless before this data was declared open data by the Mexican Government, you needed a series of legal and licensing agreements that required analysis by a legal team, hence it was a considerable amount of expenses just to create a project of cooperation with the government, that's the kind of deal only a big corporation like google could afford to fund so, as good as the information from INEGI might be , no individual or team from the OSM community would have the means to afford the expenses required in a licensing deal just to import data to OpenStreetMap, in fact that was one of the reasons we initially thought about creating a NGO to push the geographic open data agenda within the MExican Government.
However, and in a kind of surprising way, the government took the decision to release a lot of their data as open data, including the geographical data. The way in which this happened and the factors that allowed this to happen would need another post, but if you're interested a bit of the history woul could watch the conference given by  from the INEGI when he was invited to give a conference in the State of the Map LatAM in 2014 in Chile.
Once the data was declared open data by the government, it ceased to exist the need of an entity whose agenda was to push for the opening of the government's geographic data. It was then that we better focused on the following objective which was taking advantage of the richness of the INEGI data in OSM and it's up to certain point a perfect example of why the governments should release their data as open data, if not for the fact that the government's initiative to open their data came to fruition, our efforts would have been spent on lobbying and political activism instead of starting to work with the data and use them for the benefit of the citizens (which at the end is one of the objectives of the work the INEGI does), besides the fact that there was no certainty that all that lobbying work would really push our agenda until its final objective of opening the data, so it's a really fortunate fact that this had happened in an organic way within that institution itself and within the mexican government. Governments and institutions who manage geographic data in other countries could take note of this.
Second issue, data conversion and conservation. Uploading data within an import is not that simple, you must follow a series of procedures in order to preserve the previous information, even regardless of previous data validity, in order to avoid destroying valuable data previously contributed by osm users, it’s really complicated to validate automatically which information is valid and which isn't’ for a whole country unless there’s a very clear and specific reason such as data going against the OSM tagging rules which is the only guide to determine what data should be kept, however that’s not enough and you should make a backup previous to the import.
For starters, the data for boundaries doesn’t come ready to be uploaded to OSM out of the shapefile, it’s on a INEGI specific projection, and it’s not topologically ready to be converted from shapefile format to osm format, it needs to be reprojected, transformed, and properly split at the common boundaries, this is an important step to avoid way duplicity and we found out it will be a real challenge for more granular boundaries like the colonias boundaries.
Just an example, once converted to OSM compatible format, the limits file had more than 1,700,000 elements, which can't just be uploaded in a single changeset, it was necessary to split this huge file into several changesets in order for the OSM API to allow the data to be updated and also to validate errors in a state by state basis, which meant an enormous amount of time spent doing manual work, such as the verification of the admin_centre and the separation of non boundary data merged to boundary ways, since by replacing this limits with the addition of the backed up data we could be incurring in uploading errors from the restored data which would end up being a disservice for the osm map. The detection of such errors was done with the help of some scripts, but the evaluation of whether it was an error or not ended up most of the time being judged by the team, based on the editing guidelines of OSM, which took a considerable amount of time compared to a 100% script based validation and was of course exposed to human error.
In the case of Mexico’s municipal limits, we’re talking about 2,457 limits for which there were some previously limits present in selected states, where it was clear that they were imported from the INEGI but never documented and hence were invalid, in this case we replaced the limit with the updated INEGI data including the data identifier from the source at INEGI in order to facilitate future updates of these limits whenever the source updates them and also the other way around, for the INEGI to retrieve this data from OSM to identify where it should update its mapping efforts on the field based on what the OSM community is updating.
Third problem, idiosyncrasies, since before we started with the import, we knew from reading of the experiences of other previous imports, that some people is never happy with the imports, either because they don't share they same objectives of the importing team or because they have their own interpretation of the philosophy of openstreetmap on which they consider themselves owners and guardians for the data they contributed, and assume that no one else should touch or modify their contributed data. This notion that whomever trying to improve OSM through a big scale import is destroying or damaging OMS is well known within the community since the times of the TIGER import in the United States, but the reality is that OSM wouldn't be what it is today in part thanks to the importing efforts or it may be, only that it would take longer to improve without such efforts. Errors might be made, but if that's the cost for improving the map at a reasonable speed then I think that's a reasonable tradeoff as long as the errors are fixed.
Opinionated and polarizing views will always take place in open source communities, some folks will be satanized just because being part of a corporation or for having their own agenda, but in reality everyone has their own agenda, the point is whether those agendas contribute to the improvement of the project.
In order to keep this import current and to help out the INEGI to update the cartography of municipal limits, we set out to list every municipal boundary in Mexico’s OSM Wiki (Thanks Irk_Ley !) , this way the INEGI, and actually anyone, will be able to track which boundaries are being modified according to the local legislation which is possible for those users that have a legal backup to modify the boundaries from the ones that INEGI set.
Finally I would like to thank all from the import team noting it wasn’t only people from Telenav but we also received a great deal of technical support from the the HOT OSM team , local OSM mappers from Mexico and Puerto Rico and Europe. I don’t mention names because they’re all already listed in the import wiki ;)
I'm very new to the OSM community. I signed up a few days ago and have focused primarily on where I grew up (Klamath County, Oregon) and where I live now (Eugene, Oregon) and it is surprising how little is accounted for throughout Lane County and Eugene given the population base.
I have the privilege of working at the University of Oregon and in close proximity to the department of Geography. I asked a couple colleagues there about their opinions on OSM and some affiliated products like Mapbox. Their responses to me were--in short--not very positive.
Their response made me wonder why: Why is it that the map is so incomplete? Do people want to have a say about their areal knowledge? Do they even know this project exists? As someone who has a natural affinity toward cartography and accuracy within the field, I never knew how easy it was to impart that knowledge to the world until a couple days ago; so I answered my own question. It seems like the large, resource-rich companies like Google, Microsoft, Apple, and others produce a product that is good enough for most. Perhaps I'm more pedantic in cartographic precision--and as much as I like how Google and Bing Maps have progressed--I'm not fully satisfied; local knowledge of place is key to add and it is essential for making maps more meaningful to all involved in creation and consumption.
Upon logging on this evening, I came across marczoutendijk's post which grieved over the same sentiment. Accuracy and prominence of places within the project are still hazily defined if at all and this project is far from being user-friendly. Soon, I hope it can improve. It must improve.
I'm excited to continue to work on this project to the best of my ability and I wish to learn from the greater community about how to improve my skills specifically and the project more generally.
A few days ago, whilst about to create a new terrace in City Heights, Mapperley, I selected a node in a building rectangle inside JOSM. It turned blood-red, which was perfectly normal. Then the whole screen turned the same colour, whilst the only key that the computer responded to was the electricity supply on/off button; that was perfectly abnormal.
To cut the long, horrible story down to size, it was not due to JOSM, but was rather because one of the two 2GB memory sticks that were bought a few years ago from Crucial had gone bad. When memory touched ~411MB the whole system died, and the entire screen was left painted the same as the last pixel used. (Added later: a phone call to Crucial and collect a Freepost address + RMA number to return & they will send two new replacements; that's what a “Lifetime Guarantee” means, even though they were bought in 2011.)
Using memtest86+ caused the same shutdown. Removing the 2 sticks (leaving the original 1GB memory in place) removed the problem. Bum.
Fixing the problem is the easy part (a new Lenovo H30 from PC-World - strip out the useless Windows10 & replace it with Debian Jessie 8.4 & we are away) (why on earth am I forced to pay for Windows?). Moving all my stuff from the old computer to the new is the difficult bit.
How To Install Debian on a modern AMD Desktop Computer:
Some truly geeky stuff for anyone else with similar equipment & problems, to try to help; first, my target system:-
- Lenovo H30 / Windows 10
(is discontinued on Lenovo site; thus very cheap on PC-World)
- AMD A8-6410 APU
- EFI boot
- “F1” to access BIOS
Fortunately, I obtained a brand-new Jessie (Debian 8.4) ISO file to install. That is necessary as the H30 has the BIOS within a hdd partition + boots from a EFI partition (I believe that this was introduced at Windows 8.1). Debian will handle all that transparently on install; just as well for me as I was ignorant of it until afterwards, and may otherwise have tried to use an ancient Wheezy Live-Boot USB Stick.
a) Debian Basics
- It has a user/superuser system
(the user always logs in under their user-name)
(the ‘root’ superuser is used only for administration)
- “Stable” is the first of 3 possible distributions
(currently called ‘Jessie’, it is the least buggy distro)
- “Testing” is the next distribution
(currently called ‘Stretch’, it will eventually become the “Stable” distro)
- “Unstable” is the final option
(always called ‘Sid’, it will eventually become the “Testing” distro)
The Debian links below often show ‘8.4.0’ in the URL. That is the current version of Jessie. As Jessie gets updated, those links will break (the version will become ‘8.5.0’, etc.).
b) Create an Install Stick
- 2GB USB Stick
(all contents will be wiped)
- Debian ISO file
- An Internet Connection via Ethernet
(anything other than Ethernet may need drivers installing, which may not come on the stick)
I downloaded debian-8.4.0-amd64-CD-1.iso (630 MB). With hindsight, because I was going to use the lightweight-XFCE4, I could have downloaded debian-8.4.0-amd64-xfce-CD-1.iso (646 MB). It did not actually matter, as I was asked what Desktop Manager I wanted to use during install, and chose ‘xfce’ at that point. The issue in all cases is that you only need CD1 (unless you do not have an internet connection for the machine).
The ISO needs to be printed upon the USB stick (or CD if you decide to go all old-school). Here is how to do it from a Linux terminal:
- Check that the downloaded ISO has the correct md5
(also download MD5SUMS file)
- Put USB stick in computer & check it's device name
- Use dd to transfer to the USB stick
So, the first thing is to check the md5 for the downloaded file (this guarantes that the entire file has downloaded intact):
alex@home:~$ cat Downloads/MD5SUMS | fgrep debian-8.4.0-amd64-CD-1.iso c58a9df992d6e119121babbac9bb5a13 debian-8.4.0-amd64-CD-1.iso alex@home:~$ md5sum Downloads/debian-8.4.0-amd64-CD-1.iso c58a9df992d6e119121babbac9bb5a13 Downloads/debian-8.4.0-amd64-CD-1.iso
md5 is correct, so now check the newly-inserted usb-stick:
alex@home:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 923.6G 0 part / └─sda3 8:3 0 7.4G 0 part [SWAP] sdc 8:32 1 1.9G 0 disk └─sdc1 8:33 1 1.9G 0 part sr0 11:0 1 1024M 0 rom
The stick is auto-mounted in /media if formatted. dd needs to be used on an unmounted device:
alex@home:~$ sudo umount /dev/sdc1 [sudo] password for alex: umount: /dev/sdc1: not mounted
(the stick is not formatted)
alex@home:~$ sudo dd if=Downloads/debian-8.4.0-amd64-CD-1.iso of=/dev/sdc bs=1M 630+0 records in 630+0 records out 660602880 bytes (661 MB) copied, 408.09 s, 1.6 MB/s
That is a terrifying command to get wrong! As you are working as root ('sudo') it will allow you to shaft any part of the computer that you want. Note that 'if'=='in-file', 'of'=='out-file', 'bs'=='chunks of bytes to transfer at a time'. When the usb-stick stops flashing & the final 3 lines above are printed, the stick is ready to use.
Now to get the computer ready:
c) Install Debian into the H30
Warning! This deletes absolutely everything from the Hard Disk
(Possibly the Recovery partition is left, but I haven't tried to check)
(The BIOS untouched)
You may receive the following message on startup with the USB stick in the slot:
Secure Boot Violation
Invalid signature detected
Check secure boot policy in Setup
The H30 was shipped set to “Quiet Mode”, so no messages came up ordinarily at bootup. Even the telephone Customer Support was unsure of the command to get into Setup (it is 'F1') (no quotes) (you will need to be very quick as it is a very short bootup). You will find the Secure Boot Policy in there, which stops anything else other than the existing OS from booting. Set it to “Disabled”.
From that point, just follow the prompts to install Debian (very, very simple).
d) Final Setup
To perform any admin, at the moment, means switching to the root user. If you use the terminal a lot you will want to use 'sudo' (“superuser do”) instead. Here is how: (in a terminal):
alex@home:~$ su Password: root@home:/home/alex# adduser alex sudo
“su” is the “switch user” command (default: switch to root), which then needs the root password. The final line puts the user into the “sudo” group. From that point on, entering ‘sudo’ in front of a command (will require one's own password the first time) will perform the command as the root user.
The H30 has hardware that does not have Open Source drivers. It does have drivers for Linux (Debian), but those drivers come as pre-compiled binaries from the manufacturer, and the source-code is not available. For that reason, Debian refers to the sources as “non-free” (even though there is zero financial charge) (all that sort of stuff gets up my nose as well, but I put up with it since my Synaptic currently has 42,981 packages freely available, many of which are best of their class).
The main problem was that – for whatever reason – that Debian sets up the Update (“Repository”) system only with a ‘main’ repository which, as explained in the previous paragraph, means that the system will not have certain vital systems working. In my case that was Bluetooth, which is absolutely classic. It is easily fixed.
The easiest way to fix this is via Synaptic (graphical update utility) (use Menu: Settings|Repositories|Section(s)). However, being GUI means that I cannot show you here. So, using a terminal:-
alex@home:~$ sudo cat /etc/apt/sources.list deb http://ftp.uk.debian.org/debian/ jessie non-free contrib main deb-src http://ftp.uk.debian.org/debian/ jessie non-free contrib main deb http://security.debian.org/ jessie/updates main non-free deb-src http://security.debian.org/ jessie/updates main non-free # jessie-updates, previously known as 'volatile' deb http://ftp.uk.debian.org/debian/ jessie-updates main non-free deb-src http://ftp.uk.debian.org/debian/ jessie-updates main non-free
At the end of the lines that begin with “deb” or “deb-src” are the words “non-free contrib main”. As supplied, those lines contain only “main”, which means that the updates will only investigate that Repository. Add the other 2 words.
That change now means that Synaptic can find the manufacturer binaries. The easiest way is to find the error (or ‘fail’) message in the ‘dmesg’ dump, then to search within Synaptic with a snippet of that report. Here is a live example:
(‘dmesg’ only shows the current hardware report, so I'm using ‘kern.log’ to access historic logs)
May 17 13:36:57 ng3 kernel: [ 5.823268] ieee80211 phy0: Atheros AR9565 Rev:1 mem=0xffffc90011500000, irq=32 May 17 13:36:57 ng3 kernel: [ 5.847992] usbcore: registered new interface driver btusb May 17 13:36:57 ng3 kernel: [ 5.969014] usb 1-1.4: firmware: failed to load ar3k/AthrBT_0x31010000.dfu (-2) May 17 13:36:57 ng3 kernel: [ 5.969149] usb 1-1.4: Direct firmware load failed with error -2 May 17 13:36:57 ng3 kernel: [ 5.969155] usb 1-1.4: Falling back to user helper May 17 13:36:57 ng3 kernel: [ 5.971359] alg: No test for crc32 (crc32-pclmul) May 17 13:36:57 ng3 kernel: [ 5.989585] Bluetooth: Loading patch file failed May 17 13:36:57 ng3 kernel: [ 5.989657] ath3k: probe of 1-1.4:1.0 failed with error -12 May 17 13:36:57 ng3 kernel: [ 5.989716] usbcore: registered new interface driver ath3k
Synaptic first needs the “Reload” button pressing as to update from all the Repositories & find recent changes. Next, searching on “AthrBT_0x31010000.dfu” will land on the “firmware-atheros” package + show that the H30 has the ath3k Bluetooth chipset. Marking that package for install, then applying that command (and rebooting) removes the error + makes the adapter active.
A similar process was needed for (I believe) the Gigabit portion of the Ethernet adaptor:
May 17 13:36:58 ng3 kernel: [ 13.861538] r8169 0000:02:00.0: firmware: failed to load rtl_nic/rtl8105e-1.fw (-2) May 17 13:36:58 ng3 kernel: [ 13.861679] r8169 0000:02:00.0: Direct firmware load failed with error -2 May 17 13:36:58 ng3 kernel: [ 13.861685] r8169 0000:02:00.0: Falling back to user helper May 17 13:36:58 ng3 kernel: [ 13.863552] r8169 0000:02:00.0 eth0: unable to load firmware patch rtl_nic/rtl8105e-1.fw (-12) May 17 13:36:58 ng3 kernel: [ 13.991208] r8169 0000:02:00.0 eth0: link down May 17 13:36:58 ng3 kernel: [ 13.991233] r8169 0000:02:00.0 eth0: link down May 17 13:36:58 ng3 kernel: [ 13.991311] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready May 17 13:36:58 ng3 kernel: [ 14.008189] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready May 17 13:37:00 ng3 kernel: [ 15.647680] r8169 0000:02:00.0 eth0: link up May 17 13:37:00 ng3 kernel: [ 15.647695] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
The search string “rtl8105e-1.fw” found “firmware-realtek”. Marking & installing that fixed the last of the hardware issues.
Improving the OSM map - why don't we? (13)
Why so many people are not using OSM.
Do you recognize the renderer that was used for the above screenshot? I'm pretty sure you can't. Because it wasn't rendered but printed in the Times Comprehensive Atlas of the World.
Looking at this map, it is clear (at least to people who are familiar with "paper" maps ) what we see:
* A number of Islands that have a name as a group (Canary Islands) that are part of mainland Spain
* Each Island has its own name (printed in italics or bold italics)
* Each Island has a capital (printed in bold, but this is not true for all the Canary Islands)
* A number of towns is printed in normal type
Now let's see how OSM based maps and renderers show this to the world.
The same Islands, with three different ways of rendering (Humanitarian, Mapquest and Mapnik).
The most striking omission (to me) is, that none of the islands is shown with their name and Mapnik shows every Island as "España".
Even when zooming in, the names of the Islands never (and I mean NEVER) show up (I'm supposed to see Tenerife now somewhere on the map):
Now, what kind of a map is that?? Not showing what is most important!?!
Is there a road (top picture) running from Santa Cruz de Tenerife to España?
When I use a (printed) map or atlas, I can see at the large scale maps (1:500.000) what I need to find my way. At that scale I'm not interested if there is a paved/unpaved way ahead of me. And even less I do care about the traffic signs that I might see once I'm there.
I know that everything I'm looking for (and much, much more) is in the OSM database, but why is it shown to me at the wrong moments (if at all) and at the wrong zoom levels?
BTW, Google maps is not doing much better than OSM, showing (some) Island names at high zoom levels.
Do I use OSM myself? Yes!! All the time, and because I have learned to ignore all the crap it is giving me (like showing me the map in Chinese when viewing China, even if English is the language I have installed as my basic language), and because I know the strength it has with the right tools, to me it is the perfect map.
But to a lot of people who are used to a regular printed map or to Google, OSM is just a funny experiment that you can't even use decently on a mobile phone.
Of course, there are tools and apps that use the OSM data in a much more user-friendly way (especially on mobile devices), but why can't openstreetmap.org be a bit more user friendly?
One more example of the incompleteness of OSM.
In the part of the map I'm showing you here, we are supposed to see the capitals of the UK (London), France (Paris), Belgium (Brussels), Luxemburg (Luxemburg) and Holland (Amsterdam). Can you spot them?
Even worse, at this zoomlevel the only capitals shown on the map are London, Dublin and Budapest!!
Madrid, Paris, Brussels, Amsterdam, Luxemburg, Rome, Vienna, Berlin, Oslo, Kopenhagen, Stockholm? What?? Where?? Are they gone??
Friends I'm trying to move over to use OSM (by pointing them to my own openpoimap, I often tell, they call it a "slippy-map", but you better consider it a "shitty-map".
I hope that the developers who are working on the way the basic map is being presented to the users, read this and try to create a map that users recognize instead of being puzzled.
I have said it before, at this moment OSM is a map for mappers, not for users.
 Of course there are people who have never seen or used a printed map before, and for those OSM is maybe a great tool, but I doubt it.
I did it !!!! I finished tracing Carei town ! Please check out my upload !!
When it comes to visual map styles, there are always some people, who worship paper maps. In case of United States, it's about USGS topo maps, in the UK it's about Ordnance Survey, in case of Russia - about Soviet military topo map (slang name "Genshtab", which means "General Command"). These people always think, that symbology of these maps is something absolutely superior, because professional cartographers were working on it for many years to make it effective. Which is true, but barely relevant to digital cartography.
Here are several reasons why this extrapolation is wrong. (For some people it's an obvious thing, but I just like to have it here in written form to be able to refer to this diary entry in case of discussions and arguments instead of typing it every time I need it.)
Any professionally developed map style is always based on several factors: main use of specific map type, map scale (level of details), media (paper or screen).
Exactly by this reason, there are many different professionally developed standards for civilian topographic maps, hydrographic maps, military maps, aeronautical charts (and they are different, depending on altitude), marine nautical charts. In certain cases, for example - in case of nautical charts - IHO standards are universal (see IHO download page, especially - S-4 document), since it's considered safer to have uniform styles.
Map media played huge role in case of printed maps. It was too expensive and hard to use high-resolution full-color printing before. Low resolution full-color printing is completely unacceptable for maps, since large raster dots distort small objects easily. That's why paper maps were (and still are in some cases) printed with so called "spot colors" - inks of predefined colors (like black, brown, blue, green, orange, red, violet). And that's why paper map styles were developed having this and only this technology in mind. At certain grade, it was true for the first digital maps too, because transflective color LCD screens were far from ideal in color reproduction and their real usable color palette was limited by less than sixteen colors. Everybody who tried to make own styles or maps for those very first Garmin or Magellan GPS devices with color LCD screens should remember that perfectly.
But modern display screen is a high contrast full-color output device, which is at least two times better in terms of contrast than common printed matter. Therefore, it is easy to use more colors and shades for map style without compromising readability. There is no risk of bad color registration (when outlines of different colors are shifted relatively to each other due to bad printing machine setup), so we can use really thin lines, if we want to. Since high quality printing became more available, technical limits of printing process are also way wider now than it was back in fifties, when majority of paper map standards (which are still in use) were initially developed. You can check out Spesifikasjon for skjermkartografi - specification for Norwegian maps, issued by national mapping agency. It's perfect example of more or less full usage of color for different map features, which allows to put more information on map.
Purpose of any map style is the most important factor for its development. It is more obvious for people, when we comparing topographic and nautical charts, but somehow it's not that obvious when it comes to military and hiking maps. Army has own tasks we all know about. That's why Soviet military maps have different symbols for buildings made of wood and stone, because stone houses are fireproof. Same thing goes to roads - they are classified by several factors such as surface and width to give officers an idea, if particular road can be used by tanks and what will happen to it after they pass there. Is it enough for hiker or bicycle rider? Most likely, no. But it's acceptable in case if there is nothing better (like in case of Russia).
To get some idea about maps style, designed for outdoor use by pedestrian, anyone should check out International Specification for Orienteering Maps and some orienteering maps available online. Orienteering maps are perfectly readable, but in the same time, they giving you huge amount of information about landmarks, terrain, vegetation and other things in very dense "package". They even showing features like "wood, passable in one direction" (dense planted forest), "crossable and uncrossable pipelines" and many others. Is there anything like that on maps, intended for tanks? Obviously, no.
Sure, anyone is free to use whatever map one likes and to reproduce its style in MapCSS, SLD or QML, but let's avoid doing it blindly or based on limited knowledge.
I attended the CubaConf 2016 - the first international free software conference of Cuba, which took place in Havana. It was amazing to be part of this event and share knowledge about OpenStreetMap with Cuban people and with attendees that came from 17 countries around the world.
Our OpenStreetMap activities started two days before the CubaConf. On the Saturday, April 23, PB Echeverría, a experienced Cuban mapper and one of the organizers of CubaConf, gave a talk about OpenStreetMap in the FLISOL (a free software event that happens every year in a lot of cities in all Latin America).
In the following day, we had a Bike Mapathon. PB, Mauricio Miranda (OSM Argentina), Julio May (OSM Costa Rica), me and some other Cubans and Colombians took bicycles to ride around the El Vedado to map points of interest and make photos for Mapillary.
Monday was the first day of CubaConf, although we didn't have activities about OSM, I could meet Laura Barroso. She is the translator of WeeklyOSM to Spanish and is a software developer as well. I also could meet Orkut Murat, a Turkish OSM mapper. Orkut gave a talk about GNU Milion, a drupal extension he is developing to manage GIS data in Drupal.
In the second day of the conference, we had three talks about OSM. I started the session presenting an introduction to OpenStreetMap and showed some projects of the Latin America communities. Ivan Terceros showed the efforts to map Ecuador after the Earthquake. Finally, Julio May talked about how OSM is being used in Costa Rica to map areas that are in risk of flooding.
To finish our OSM activities, we had a Mapping Workshop in the last day. Due to the restrictions in the internet access in Cuba, we didn't have internet in the place of the Event, so it was an offline workshop, but it worked very well. I prepared a lot of screenshots showing how to map using Maps.Me and OsmAnd. I also had the source code of iD editor in my computer, so I could run it offline and show the begginers guide that is included in iD. Furthermore we showed how to start mapping using JOSM: the main shortkeys, how to load photos, GPX files, etc. And we talked about FieldPapers as well!
You can see more photos of CubaConf on flickr.
Digismartek provides you digitization Services like document management system, Electronic management system,document scanning services. We provide the best dezitization services.
I got involved with OSM back in January. Now its been 4 months and I think its the right time to make an introductory post.
I started looking for interesting projects, and iD caught my attention. The first bug that I fixed was pretty simple, It required me to fix a faulty regex. D3 was new to me, as I come from the fancy React/Angular land which obscures most of the internal working. My mentor Bryan was more than happy to help me out. After my first week I discussed with him about the possibility of an OSM GSoC on #dev channel. Which brought up a lot of heated conversation regarding the pros and cons of GSoC for the organization. The channel did admit that overall GSoC 2015 was a success. Which got me pumped up to spend my summer working on iD.
While this was happening I also started going through OSM wiki/diaries to learn mapping. I planned on mapping my college. My college and its surrounding had a spotty coverage. Since, I was a newbie I tried to map things I was most confident with. In India we call dormitories hostels, so I started marking my college buildings with hostel tags. When I showed my work to Bryan he was to quick to point out that might not be the case everywhere. He suggested me to tag all the buildings with
University Building tag.
This is what my college and surrounding area looks like now.
One of the best things that contributed to iD was the multiselect feature, which I implemented with the help of Bryan. This feature took a lot of days for me to implement and gave me a good understanding of how iD works.
Another exciting feature which helped me build confidence with the iD code was the imagery offset. The earlier implementation of imagery offset was unintuitive and required a fix. This feature request required me to fix the UI and to make it easy to use. Know more about this feature, click here.
I will continue with my investigation on the lane editor for GSoC. And learn more about D3 to fix some of the pending bugs of iD. I plan on writing about my progress weekly from now on, so that the community knows where I stand and give me inputs on how to improve upon my work.
For years I've been meaning to try out Mapillary properly, but my phone is broken and can't connect to wifi, so no upload.
But this was another thing I got to do while on holiday in Brazil. I persuaded my wife to install mapillary on her phone, and we mapillarised while we were driving around her home city of Guarulhos. She's pretty bored of all this mapping stuff, but likes to keep me entertained while we're in Brazil, and maybe she likes the idea of mapping her home town too. So we got lots of photos around these colourful Brazilian streets.
Also while going on a trip to the seaside, but sadly I don't think I got much of a seaside view in any mapillary photos. Some are quite nice and jungly though
And on the way there my wife wasn't amused when we got massively detoured in a drive around the city of Mogi das Cruzes. It was only semi-deliberate :-)
On the site you can see what proportion of streets have coverage (green) on a map display like this. I guess Mapillary coverage is expanding, but there's a long way to go. Hopelessly incomplete... but maybe if enough people join in, we'll have street-level photos of every street in the world. It feels like exploration. Conquering the territory, or laying the first tracks to form a skeleton that others will build upon. It feels like the early days of OpenStreetMap.
I was impressed by the ease of photo data gathering with the app. It's a very passive process but the app gives satisfying flashing counter as it gets photos. It detects when you stop moving and stops taking photos. The messages makes it nice and clear what's going on.
We were driving. I'm not sure how well it works with pedestrian tracing. By fortuitous coincidence, I was gathering up freebies at SmarterTravel Live conference, a few days before heading to Brazil, and one of the freebies (courtesy of dat mobility. Thanks!) was this simple windscreen mounting sucker thing. Perfect for mapillary tracing!
I was also impressed by the ease of upload. (Given a wifi connection) it's very simple to upload this quite hefty amount of data to the mapillary servers. There's then a delay while mapillary crunches the data before you see your green line on the map. I notice there's then a further delay before the images get stitched together with the animated zoomey effect. Understandably because it's a huge amount of processing, which no doubt gets queued up along with everyone else's collections of hundreds of photos.
But what about using Mapillary for contributing to OpenStreetMap? When pondering OpenStreetMap workflows, I see a sliding scale of more or less passive data collection. Mapillary is hugely passive, which is great news when it comes to quick effortless surveying, but the flip-side of that is, you leave a lot of work to do later on when you're back at the computer. I did a bit of this last night. Looking through the places we'd been driving around Guarulhos, clicking around with the mapillary JOSM plugin. Click next photo -> next photo -> next photo, which is essentially like driving along the road all over again, but this time I'm scrutinising the photos for anything I can add to the map. Probably a lot slower than the drive itself (depending on how much stuff you see which needs adding). In other words, after all that very simple passive surveying, I've left a lot of work to do later. A hopeless amount really
Being in Brazil my photos are all super-sharp in the harsh sunshine, however I found it pretty hard to identify Brazilian highstreet shops. In the more shabby areas the shops are not clearly branded or labelled (akin to the shabby north London shops all around me), and I often looked at translating a shop sign which turned out to be a billboard/product advert. Slow going, and I probably won't get around to examining all my Brazil mapillary traces for data to add to OSM.
But being shared with everybody, a mapillary trace is a resource which has the potential to be super-useful for other OpenStreetMappers. I've already used other people's mapillary traces in London on a few occasions e.g. puzzling over particular data problems from notes or other QA tools. But mostly I've found myself wishing there was more mapillary coverage. When we get to the point where we can back-up all of our data fixing with both aerial imagery and street-level photos, Mapillary will be quite something! ...might have to borrow my wife's phone!
Q: Who are you ?
I am Pete Masters (OSM: pedrito1414 - a hangover from my time living in Mexico). I live in Glasgow and work for MSF, running the Missing Maps project. I am a fairly rubbish climber, a regular footballer and get out to the lochs and mountains as much as possible.
Q: When and how did you discover OpenStreetMap ?
As a user. I have travelled extensively with my various jobs and OSM and associated apps are indispensable. I can never understand why someone heading abroad wouldn't have OsmAnd or similar on their phone!
Q: What do you map ? Is there any difference with your early days ?
As a contributor, I guess I am a relative newbie. My mapping started with HOT mapping and then Missing Maps of course. The biggest difference? My eyes. It continues to amaze me the level to which we can train our eyes to pick out detail in satellite imagery....
Q: How do you map ?
In the field for MSF, I use OpenDataKit, OsmAnd, field papers and occasionally OSM Tracker, OpenMapKit. I do a lot of tracing, too in JOSM. At home, I do a little bit of surveying - mostly alterations and corrections I notice while navigating or leisure mapping while on holiday....
Q: Where do you map ? Locally, HOT ?
A little bit locally, but mostly in the field.
Q: What is your biggest achievement as mapper ?
I have mapped in Congo (DRC), Central African Republic, Bangladesh, amongst others, but the experience of Bangladesh was pretty special. Working with Jorieke Vyncke and incredible OSM Bangladesh community was an absolute pleasure. We worked hard, we had a lot of fun and we did the job that MSF needed us to do. Very proud of that. Also, massively proud of the heights that OSM Bangladesh have since reached - I'm a big fan ;) With the uni of Lubumbashi guys in Congo
Q: Why do yo map ? What motivates you ?
I have worked for MSF for a long time now and love the organisation. That I can practically contribute to their mission is extremely satisfying and motivating. I also find helping responders through the HOT activations following disasters very rewarding. I guess this is also the first time I have been a part of such a talented, committed and interesting community of people, too. Remotely, through conferences and meetups, and through the London and Glasgow mapathons, I have met brilliant individuals and made some good friends....
Q: What is the most difficult part of mapping ?
For me, it's not the mapping - it's the organising. Trying to make sure that data quality stays consistently high, while at the same time bringing in new people to OSM and HOT is a huge challenge. We are getting better, but there is a long way to go and I welcome ideas that anyone might have....
Q: What are your mapping plans for the near future ?
Q: Do you have contact with other mappers ?
All the time! I go to at least a couple of mapping parties a month in various cities. And, I hope you don't mind, but I'd like to mention Nick Allen and Ralph Aytoun by name. They may be surprised, but I see them as my mentors in all of this - knowledgeable, incredibly generous with their time and always available and patient for my (never-ending, sometimes-foolish) questions ;)
Q: Do you use OpenStreetMap yourself ? How ?
As above... In the field, both for personal travel and work.
Q: Can you tell us a bit more about "Missing Maps" ?
The Missing Maps is a project made up of numerous organisations and thousands of individuals. Each one has different objectives, resources, skill sets and each brings something different to the table. The openness of that table is massively important and we try to make it as welcoming as possible to people who want to pull up a chair. We unite around a common humanitarian desire and that's the fuel in the fire.
The project was born out of a need. A lack of geo-data in the places where MSF teams work - places that rarely make the news. The volunteers who engage and contribute are helping to meet that need and directly supporting life-saving medical work in some of the most dangerous and vulnerable places in the world.
While the Missing Maps project wasn't my idea - I was there at the start. I named it ;)
Q: Do you do anything else than mapping that is related to OpenStreetMap ?
I still love to use paper Ordnance Survey maps while hiking.
Q: To conclude, is there anything else you want to mention ?
Just to say that this last couple of year's immersion in OSM and HOT has been an education, an experience and a pleasure. Long may it continue!
Thanks a lot Peter for taking the time for this interview.
The previous interviews can be found on the wiki
Another round of Ordnance Survey data has been released and processed by ITO! to produce a very useful comparison against OSM. Once again, their very usable web slippy map, and JOSM layer this has shown up a new building site I didn't know existed ready for survey.
As well as missing developments, the comparison also showed up a fat-fingered typo from one of my past surveys - quickly fixed!
As usual, don't assume OSM mappers are any better or worse than the professionals - OS data feeds from local authorities don't always match the 'ground truth' signage and so don't accept the OS Locator data has to be correct without a check particularly if OSM is marked source=survey.
If there's no signage out there to contradict or correct, then an attributed name from OS is better than none (source:name=OS Locator). If Locator is wrong, use the tag 'not:name=' to show the issue to comparison sites like ITO, and also to OS so they can check themselves.
So once again, raise a glass to OS Open data, ITO for the service, and the local groups of fellow mappers slowly increasing the comparison UK Percentage Complete beyond the current 97.60%.
Help turn all UK counties UK cyan on the overview map - a 100% match!
On many occasions in the past I've said "it's really easy to create your own Garmin maps" but I don't think I've ever documented the procedure. This is an attempt to do that.
You've got some sort of Garmin device with an SD card in it with some maps that you've downloaded from somewhere on it.
You want to replace those with a map you've created yourself.
You've got a PC with around enough memory in it. The one I used for the examples below had 4Gb; it's possible that less may be needed for a small file such as the one used in the examples below.
All the path examples below for for Windows (actually tested on Windows 7), but it should be relatively straightforward to adapt them to work on other operating systems.
What you need to do
The easiest way to create Garmin maps from OSM data is to use "mkgmap". That's available from:
The download page for the latest mkgmap is http://www.mkgmap.org.uk/download/mkgmap.html and the current version is "3676".
Unzip the zip file and move the folders intact to a known location. In my case I moved it so that "mkgmap.jar" file was in: C:\Utils\mkgmap-r3676
I didn't use a path with a space in it or a path that Windows recognises as "special" to avoid any possible confusion later.
"Splitter" is a separate program used to split a large OSM data file into portions small enough for mkgmap to work with (the resultant Garmin map can still route between portions).
The latest Splitter is here: http://www.mkgmap.org.uk/download/splitter.html and the current version is "437".
Unzip the zip file and move the folders intact to a known location. In my case I moved it so that splitter.jar was in: C:\Utils\splitter-r437
Next, we need to download an OSM extract to use to create maps from. As an example I'll use Romania, and extract for which can be downloaded from here:
That page currently says:
romania-latest.osm.pbf, suitable for Osmium, Osmosis, imposm, osm2pgsql, mkgmap, and others. This file was last modified 7 hours ago and contains all OSM data up to 2016-05-13T19:45:03Z. File size: 146 MB; MD5 sum: b0554ae9632cc6c2be1c1e3525b5dcb5.
After downloading, check that the file is intact:
md5sum romania-latest.osm.pbf b0554ae9632cc6c2be1c1e3525b5dcb5 *romania-latest.osm.pbf
(see links from https://en.wikipedia.org/wiki/Md5sum for where to get an "md5sum" program from if you don't already have one)
That matches so we can continue.
Create a directory to work in - in my case I created "D:\doc\gps\romania" and copied romania-latest.osm.pbf to it.
From a command prompt (on Windows), change the current directory to be where the downloaded .pbf file is.
d: cd \doc\gps\romania
See what version of "java" you have installed. Type "java -version" at the command prompt to find out. In my case that says:
java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
so Java is already installed. If you don't already have Java installed download and install from somewhere like: http://java.com/en/download/windows_xpi.jsp
Next, run splitter. The "-Xmx1200m" tells it how much memory to allocate; the "--max-nodes" how big to make each split piece. The examples for the parameters given here should "just work":
java -Xmx1200m -jar c:\utils\splitter-r437\splitter.jar romania-latest.osm.pbf --max-nodes=800000 --output=xml
That should create lots of ".osm.gz" files. Then run mkgmap. Here "--style" determines the style of map to create - "default" is actually a folder containing several files that make up that style. Unsurprisingly the style called "default" is the default mkgmap style - not particularly optimised for foot, bicycle or car use.
java -Xmx1200M -jar C:\Utils\mkgmap-r3676\mkgmap.jar --style-file=C:\Utils\mkgmap-r3676\examples\styles\default --route --gmapsupp *.osm.gz
When that finishes it should say something like "Total time taken: 621133ms" (i.e. about 10 minutes on a fairly slow PC for a country that is relatively small in OSM terms).
d:\doc\gps\romania: -rw-rw-rw- 1 A.Townsend None 123359232 05-14 13:31 gmapsupp.img -rw-rw-rw- 1 A.Townsend None 4270 05-14 13:31 osmmap.tdb -rw-rw-rw- 1 A.Townsend None 73728 05-14 13:31 osmmap.img
Create a subdirectory and move those files into there for safekeeping:
d:\doc\gps\romania\default: -rw-rw-rw- 1 A.Townsend None 123359232 05-14 13:31 gmapsupp.img -rw-rw-rw- 1 A.Townsend None 73728 05-14 13:31 osmmap.img -rw-rw-rw- 1 A.Townsend None 4270 05-14 13:31 osmmap.tdb
Copy those files to the GPS. The method to do this varies by device. I'd expect that people reading this will already do this with files they've downloaded from elsewhere; if not there are lots of examples on places such as http://help.openstreetmap.org.
When it's copied across, turn on the GPS and check that the new map is visible.
Next, how to change the style slightly?
In C:\Utils\mkgmap-r3676\examples\styles, take a copy of the "default" folder and call it something like "mystyle". We'll leave "default" as it was and make a simple change to "mystyle". As a test we're going to make tracks appear like unclassified roads.
Edit c:\Utils\mkgmap-r3676\examples\styles\mystyle\lines in a text editor. The "lines" file is the one that deals with linear items - things such as roads.
Here's the line in that file that deals with unclassified roads:
highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21]
It's pretty straightforward what is happening - the OSM feature at the left ("highway=unclassified") is to be transformed into the Garmin feature at the right ("0x06").
Here's the line that deals with tracks:
highway=track [0x0a road_class=0 road_speed=1 resolution 22]
change the latter line to:
highway=track [0x06 road_class=0 road_speed=3 resolution 21]
(i.e. so that "highway=track" is treated as if it was "highway=unclassified")
Rerun mkgmap with the new style:
java -Xmx1200M -jar C:\Utils\mkgmap-r3676\mkgmap.jar --style-file=C:\Utils\mkgmap-r3676\examples\styles\mystyle --route --gmapsupp *.osm.gz
Create somewhere safe to store the new files, and put them there:
d:\doc\gps\romania\mystyle: -rw-rw-rw- 1 A.Townsend None 123338752 05-14 14:23 gmapsupp.img -rw-rw-rw- 1 A.Townsend None 73728 05-14 14:23 osmmap.img -rw-rw-rw- 1 A.Townsend None 4270 05-14 14:23 osmmap.tdb
Copy to the GPS again, and check that tracks do indeed appear as roads.
... and that's it.
Obviously there are many more changes that can be made. There's quite a lot of information on the OSM wiki at places such as http://wiki.openstreetmap.org/wiki/Mkgmap/help .
The resulting example "default" files can be found at this link:
The resulting example "mystyle" files can be found at this link: