well instead of posting entirely happy about the fact that for nearly all countries (exception for now Spain, Portugal, Sweden, Norway) that I offered contourlines for – now have them integrated,  I have to say that at least the Alps and Germany the upload crashed – so please don't post further [...]]]> Hello to all,

well instead of posting entirely happy about the fact that for nearly all countries (exception for now Spain, Portugal, Sweden, Norway) that I offered contourlines for – now have them integrated,  I have to say that at least the Alps and Germany the upload crashed – so please don't post further comments and emails about the countries currently not downloadable.
 

After last week I spent a lot of time of fixing my website server, I didn't found time to get in the updates timely enough for checking that they are okay before going on holidays. I'm in Dubai on stopover on my way to China with my girlfriend and even though everything is really modern here, well working internet seems to be big trouble (tried 3 internet cafes besides my hotel so far and at all places internet really trickles in). Means I currently don't manage to get a stable/quick enough connection to log into my server to schedule the uploads to be done again. I hope I can do so tomorrow evening, else I'll try from Beijing (hope that i get through the big internet wall without problems…

For the future I'll try to setup a folder syncing between the server I generate the maps on, and my website server from which on the maps are mirrored to GWDG cause upload breakups got a bit unstable lately.

Also I'll try to generate contourlines for the Europe Map and some more country maps. The new contourlines are of higher quality than the ones before because due to phyghtmap being released I was able to take the 1" files from viewfinderpanoramas instead of the 3" files, meaning 300% better resolution for the alps – hence higher quality. Also now there are no more cutting artefacts – so the contourlines are a bit cleaner (wasn't a big problem though). At some (very very few) places due to data holes in the DEM data there are still artefacts – but e.g. for the alps this are 3 places where this problem exists. The contourlines are definitely of higher quality than in the latest Garmin maps of Austria/Germany, but not so good of course than in printed 1:25k topo maps that still bought the contourlines from the national map survey agencies.

So far so good, I'll just edit this post once the problems are solved.

EDIT: Tuesday 13:00 GMT: All countries should be correctly uploaded now. Europe full Velomap/Openmtbmap Premium downloads should be working again by 15:00 GMT.

First of all I decided to add besides the easy layout, a special hiking layout. I introduced it because I felt that the easy layout is still showing too much information related to cycling or mtbiking than what one [...]]]> Hiking Layout

Well for this time the changes  are more visually than on other map changes.

First of all I decided to add besides the easy layout, a special hiking layout. I introduced it because I felt that the easy layout is still showing too much information related to cycling or mtbiking than what one needs as a hiker. The new layout therefore omits all bicycle/mtb related information. So instead of mtbiking, cycling and hiking routes, only hiking routes are shown. Also POI like bikeshops disappear earlier when zooming out. On the other hand hiking routes are shown longer than in the other layouts. There is also no separation on oneway arrows depending on whether you are allowed to cycle against the direction of traffic flow or not and many other little important bits.

Going with this change I show all streets/ways/paths that are part of a hiking route also in zoom resolution 21 – just like before for cycling/mtbiking routes. Effectively this is quite a good step forward also for mtbiking/cycling as the rather important ways are shown when zooming out longer, while footways/paths in cities usually are not affected and disappear much earlier. This also gives a more consistent network of important ways for mtbiking/cycling.

Oneway Arrows

When I introduced oneway arrows difference based on the information whether you are allowed to cycle against the traffic flow or not I invented a different arrow design to show the change. However I think the arrow design I used was more prominent than the arrow design for roads that you are not allowed to cycle against traffic flow. On one hand this was nice -as those roads are often the ones that you really want to omit and never cycle along. On the other hand it wasn't so logical why roads with less stringent oneway behaviour would be more prominent. Therefore I took up the task and changed them all around.

Other changes

An important change is that I found a bug that blocked tracktype being considered for "unpaved" road avoidance. I fixed it after I thought that the new Basecamp v 3.3 beta didn't work as expected (more on that later).

Besides I got a bit annoyed that the fixme=continue arrow showed up sometimes too prominent – and it is more and more used on ways that no tourist/cyclinst/mtbiker ever takes anyhow. Therefore I moved it to resolution 24. As especially Europe gets more and more complete on ways, I think the importance is less urgent than it once was (with the aim to encourage people to record new ways for OSM).

There were quite a lot of other small changes/optimizations that I not mention here..

Oh and last week I went over the website and tried to update most pages cause some of them had gotten a bit outdated.

Basecamp v 3.3.0.2 beta and Garmin introducing new routing algorythms

Well after me being the first map producer worldwide to really push mtbike and cycling autorouting since about 3 years, Garmin seems to have noticed that if they want to continue to sell maps, they have to improve their maps and functions. Basecamp 3.3 beta (look for it in the garmin forum). They now introduced many many activity profiles like mountainbiking, mountaineering, ATV, dirtbike, walking, hiking and so on. This change could be noticed pretty strongly since as of Basecamp 3.2 Garmin decided not to take restrictions like cycling forbidden, or foot forbidden, or taxi forbidden in their maps into consideration. One has to say that even though they had this functionality in their software and firmware since I can remember or trace back, never an official map sold by Garmin included this information. Either they coudn't get it, or they cheaped out on buying this information…. This lead to many people wondering why they were lead onto motorways while cycling or walking activated as means of transport in Mapsource/Basecamp or on the GPS.

Of course as we knew how to implement these switches, and OSM has this information to a rather good standard, I used it and it made up for more possibilities on restricting which way quality you could take or not. Now with Basecamp 3.3 the selection of means of transport changed to activity profiles, and they are not similar to the means of transport that existed in the maps all along. Instead the profiles now exclude the use of certain (however not yet known) road types or maybe additional information that we don't know how to encode. As of now the new modes don't work any better than before also for official Garmin maps, but the announcement lead to believe that Garmin will in future on new maps make extensive use of the activity profiles. Not only by different autorouting, but also by telling that in future based on the activity mode the map layout will change.

As soon as I find out more on how this affects autorouting, and more GPS (currently only the new etrex x0 series is already affected) switch to the new way of working, I will adapt (if possible) the openmtbmap autorouting modes to suit it. Currently however http://openmtbmap.org/about-2/autorouting/ has to be taken as a bit outdated when it comes to Basecamp 3.3 beta…

I don't really know what implications this will have to Openmtbmap/Velomap and also OSM. The point is, that the information that Garmin would need to actually really implement the ideas of their developpers on the software side, is not really available on the map data market – with the exception of Openstreetmap. I predict that shortly (2-3 month) after the license change in OSM, that will allow much more restrictive (like DRM and other) maps based on OSM map data, Garmin will bring out themselves not free but payable and not copyable maps based on OSM, maybe enriched with other data like higher quality DEM from laserscans (even though recently Garmin maps showed worse and worse DEM and contourlines – probably to save money) and maybe other data goodies in order to have a more competitive standpoint for people buying their maps. Also they will probably make sure that their maps show exclusive features that we will not be able to implement with mkgmap cause we don't know the newest map format specifications.

I see this process as part of a natural way things behave. I (and others who followed by making maps with autorouting for outdoor purposes) shaped the way to force the industry to react cause their offerings are of lower quality (IMHO in Austria/Germany/Switzerland OSM is on ways/highways in general now far ahead of the official map data providers, but of course still way behind on topographic features) and they have to follow. Giove was the first GPS PNA producer to have autorouting for outdoor purposes officially supported but in my eyes failed completely because their map data was neither consistent nor of good enough quality (except in some parts of Italy). Falk, Brydon and others tried to jump on the train, but so far don't offer competitive products. All of them suffer mainly from the fact that there isn't good enough map data available. If they want to achieve what I started with Openmtbmap 3 years ago, namely maps that are really suited and made for outdoor sports like cycling and mountainbiking, they have to make use of Openstreetmap data (google currently doesn't seem to have got it and goes mainly inline with traditional automotive focused design – also with their otherwise excellent map maker which in reality is by now the biggest competitor to OSM). So what once started as an idea to have maps for mountainbiking the first time, now is going more and more commercial.

I do know that this process will go along and that focusing on Garmin devices as best mean for getting good maps for mountainbiking will be over in 2-3 years time. I am and will however try to stay on top of the game and work hard that good maps for mountainbiking stay free as in free beer to everyone (and not only you are free to give your data to OSM or google database and let big uninnovate companies that just react instead of act dominate the scene. I have many more ideas on what can be done, and will give my best to do so.
Just note that in order to continue pushing forward and developing I need your support too. Tell people about Openmtbmap, blog about it, and please also donate to openmtbmap to give me the possibilities to continue this work.

So I would really appreciate if you donate some money for my Christmas presents here: http://openmtbmap.org/support/membership/

For some it might be known, [...]]]> Over the last few weeks I spent a lot of time (about 130 hours total) on reworking the whole Points of Interest (POI — all points in the map) framework. I did this because I noticed that some points were not found on the newer garmin devices like before.

For some it might be known, but most will not know that Garmin uses a rather complicated system to determine what point can be found at which place on the GPS/Mapsource and also determine the maximum resolution at which it is shown. This system is based on a rather random system of FFFFF points. Only a few of those are however usable and searchable. Hence it took me a long time to tryout to analyse and tryout about 2000 (hex) of them to find out which ones have which properties.

Already over the last two weeks I had started to update this system, for this Thursday's updates the rework is finished. I will write an article today that shows the structure about what you can find via the search function.

Do note that this also depends on other maps. There are some maps like Nop's Reit & Wanderkarte, but also others (all that use the poi search to find addresses) that will however completely havoc the POI search (also if map is deactivated). Also some maps could clutter certain search categories. On some devices like etrex 30 you can decide which map to choose for the POI search, but this doesn't really work – so best don't use to many maps on your GPS if you want to have reliable results (openmtbmap/velomap plus city navigator maps works very fine).

Due to the rework and using newer types, I managed to reduce the POI that are in the map also by about 10% (resulting in about 1% overall smaller maps) – which should mean a little speed boost (this is because I want to show different symbols for some POI that are found in the same category, due to the rework I could reduce the amount of POI which are twice in the map – with one entry for searching, and another one for displaying them).

For everyone using adapted .typ-files, you will of course need to update them (easiest simply copy over the whole poi section via text editor).

You can find the structure of the POI search on the new page I created here: http://openmtbmap.org/about-2/enpois-search-structure-depois-suchstruktur-espois-search-structure-espois-search-structure/

feel free to add comments if there is some stuff in OSM that would be needed for tourism/recreation cycling/mtbiking that is not yet findable or if you have ideas on what should be findable under categories like tides or currents.

Also because it sometimes happens: If you donate money via bank tranfer but do not indicate an email to me, please send me an email telling me your name/donation so that I can create an account for you. I have no chance to contact you without email….

With this work finished I will refocus on working on an online map which I hope to get online mid of December.

And last of all, I updated openmtbmap Europe yesterday and the Velomap Europe is right now rendered. Tomorrow I'll run normal map updates again.

First of all, as you may have noticed, Openmtbmap.org is now also available in Italian. Big thank [...]]]> Well over the last weeks I had quite a lot to do, so I never got around writing the changes to the maps. So here we go. I hope I remember at least 50% of the changes.

First of all, as you may have noticed, Openmtbmap.org is now also available in Italian. Big thank goes to User "Miellino" (you can find him on here, as well as on mtb-forum.it). It's a huge effort translating the whole site, so fat props to his efforts of not only the translation but also the work he does for OSM in Italy. If you meet him up, please buy him a couple of beers (I'll do if I get the chance…).

Then many of you have noticed that the last map update went a bit wrong, and in some countries tiles were missing. That happened as soon as somewhere a double decimal (like 45.54.4) showed up in either elevation or population key. For right now I downgraded the mkgmap version until the bug gets sorted (it's faulty data, but of course mkgmap should not crash on this). Before mkgmap would simply not read in any values with decimal points, so they were dropped. After I identified the revision it popped up, and found out the cause I therefore decided to run a new map update.

The next good step mkgmap has done (rev 2046) is to more or less halve the amount of memory it needs in order to create the address search index, and also it became quicker in compiling as well as solving some more bugs. Besides now if mkgmap crashes on index creation, it does not produce a broken mdr.img file anymore. So the integration of contourlines got much easier now for Basecamp (remember in Mapsource you can show the map, but the contourlines will be mostly invisible). On top as I had to rewrite the "create mapsource installation files with mkgmap.bat" file anyhow, I added the option for everyone to input free RAM, so it should be much quicker and easier now to have maps with integrated contourlines on your PC in Basecamp. (you need about 75-80% of free memory vs the size of all 6*.img files combined — so in order to create a map of Germany with contourlines about 900MB RAM should be enough vs previously x64 and about 1800MB were needed).

Now for the changes to the maps I just post the summarised changelogs:

Make main roads layout more harmonic (tertiary roads have been a bit too bright yellow) — This makes the traditional layout in the Velomap as well as Openmtbmap a huge step forward in my eyes. I worked lotta hours on harmonizing all the road colors from motorways down to unclassified roads.

Add some more road is unpaved tags to Velomap (if real condition can only be guessed), plus add tourism=cabin (seems to be a Norwegian/Swedish speciality, but used quite often).

Update style to make it fit for mkgmap rev 2020 (address search being read from style-file from now on)…
Also do some more work on smoothness to tracktype mapping.

Set up a table to more intelligently guess how good a way is to ride if smoothness and tracktype contradict each other. In general for the Velomap the rule is to trust the value which is worse now (before smoothness had preference over tracktype as it is the key that has much higher importance on cycling road conditions/surface_conditions). For the Openmtbmap a more middle way approach has been taken.

Search Windows Server with 8GB RAM // Quadcore for use once weekly about 12-16hours..

I still search a server to create the maps on. So I just repeat from my last newsletter: The server I currently use to build my maps will be down in 1 month. Hence I need a new Windows Server to build my maps. I need at least 8GB RAM/Quadcore for about 12-16 hours for the weekly update (and about 50-100GB of hard disk space) and 10Mbit connection (in/out, but most servers are on 100Mbit anyhow so that shouldn't be a problem – traffic is about 5GB in/ 10GB out for each update) plus about 12 hours monthly for the Europe map updates. If someone could help me out here that would be great (and save me from paying about 50-60€ a month for this). Linux Machine won't work (even though all tools for creating the map run under linux OS too), as I don't like bash or perl and prefer to update the maps using dos batch scripts….

I would create the maps locally, but getting an internet connection with 4Mbit uplink or more (else it takes ages to upload the maps) in Vienna costs more than getting a shared windows server so I cannot create them locally. With 800kbit upload it is no fun, as upload blocks me from working for about 25 hours…

Yesterday/Today I did update the Europe Map however (actually I updated it on the 22. already, but there seems to be some memory leak, so it didn't run through [...]]]> Well for the map updates there was nothing special. I'm currently focussing more on getting an online map together and scouting for Android/Iphone apss cooperations.

Yesterday/Today I did update the Europe Map however (actually I updated it on the 22. already, but there seems to be some memory leak, so it didn't run through very successful – meaning the address index was broken). So from today the Europe maps are updated again. For the next map update I put a lot of work into better identifying what is meant if tracktype and smoothness contradict each other. For the velomap I rather put the emphasis on relying on the worse condition, while for the openmtbmap I rather rely on the good condition…

Also note that Basecamp and seemingly newer generation GPS don't regard the vehicle setting avoidances anymore. Garmin doesn't really accept it as a bug though (they never used avoidances for vehicles in any of their map, and now claim that their maps work (well they never included it until recently in some NT maps that are not reverse engineered and hence unreadable map format). Dunno if they did it on purpose following a motto of "let OSM map work on our GPS, but make sure they contain so many bugs people in the long run will buy our own maps…"

For next update I will try to give the address search an overhaul as well, trying to better match cities/regions to the adresses or POI.

Now however to a more serious problem. The server I currently use to build my maps will be down in 1-2 month. Hence I need a new Windows Server to build my maps. I need at least 8GB RAM/Quadcore for about 14-16 hours for the weekly update (and about 50-100GB of hard disk space) and 10Mbit connection (in/out, but most servers are on 100Mbit anyhow so that shouldn't be a problem – traffic is about 5GB in/ 10GB out for each update) plus about 12 hours monthly for the Europe map updates. If someone could help me out here that would be great (and save me from paying about 50-60€ a month for this). Linux Machine won't work (even though all tools for creating the map run under linux OS too), as I don't like bash or perl and prefer to update the maps using dos batch scripts….