In the license file it says “Map created with mkgmap-r2599”.
The Gemeinde prefix is fixed in mkgmap 2617, http://www.mkgmap.org.uk/news/
so you have to wait a while. Process destination I dont know, depends when Lambertus has updated his scripts.
ah ok sorry, i thought it uses the latest
May be this question has been asked before. I updated some incorrect data in openstreetmap yesterday and the changes were reflected when i was viewing them. I then proceeded to create a “Routable Bicycle (Openfietsmap Lite)” map. However, upon installing the resulting img file into my Garmin Edge this morning, i noticed the map is still showing the incorrect data, that is, the changes i made last night was not in the img file. When i am creating a map on garmin.openstreetmap.nl, doesn’t it grab the latest data from openstreetmap.org?
No, you can see underneath the map the date the map was generated: Map version: 21-05-2013
Ahh…Thanks!
Hi!
Cool! In the last build the City Search is correct working for “Gemeinde …” boundaries! Great! (even created with r2599? as written in license file)
One thing i saw is that many boundaries of villages are not mapped because they are not known, but they have a landuse=residential with an addr:city tag (ex: http://www.openstreetmap.org/browse/way/19867506) . Maybe it would be possible as a last instance to use this, because otherwise these villages are not found.
Another problem are the many villages in the rural area, which are only tagged as a place=village and so also not found. (They even have not really street names) (ex: http://www.openstreetmap.org/browse/node/174944002)
Search for housenumbers works mostly but has some strange behavior. While most addresses on residential roads are found housenumbers on Tertiary and Secondary roads are not.
ex:
secondary not found: http://www.openstreetmap.org/browse/way/161232954))
residential found: http://www.openstreetmap.org/browse/way/106553566 (but points to wrong position, points to road center)
residential found: http://www.openstreetmap.org/browse/way/98441664 (mostly all addresses are found)
residential not found: http://www.openstreetmap.org/browse/way/98494939 (no address on that road are found)
I have currently no idea why some are found while others are not …
Hi mapper,
I would suggest to join the mkgmap mailing list http://www.mkgmap.org.uk/maillist and post your questions there, maybe some improvements can be made to the address search in mkgmap. You can also have a look at http://tools.geofabrik.de/osmi/?view=addresses to check if the addresses correspond with the streetnames on OSM.
Btw can you check if the ref tag on secondary/tertiary roads is maybe the cause of this behaviour? Maybe it is included in the streetname by mkgmap and therefore not findable anymore (streetnames must be exactly matching with the addr:street tag of the housenumber)
Mapper_07,
I can confirm that if the streetnames contain ref tags (like most secondary and primary highways have), the housenumbers are not findable anymore, because mkgmap adds the ref# to the name. This is a mkgmap bug that needs to be solved, thanks for spotting it!
Hello.
I have a serious problem with the Openfietsmap Lite.
In these places stretches of road are missing even though data correctly is entered into the base OSM:
http://www.openstreetmap.org/?lat=50.112264&lon=18.245636&zoom=18&layers=M
http://www.openstreetmap.org/?lat=50.09875&lon=18.21767&zoom=17&layers=M
http://www.openstreetmap.org/?lat=50.18336&lon=18.2124&zoom=17&layers=M
http://www.openstreetmap.org/?lat=50.18404&lon=18.24512&zoom=16&layers=M
Please tell me exactly which roads (http://www.openstreetmap.org/browse/way/osmid#)?
Can you post a screenshot here?
Where did you see it is missing (GPS, please specify the type of your unit or Basecamp?)
I will send photographs to the mail.
I ask for the address.
Thanks, you can send it to info at openfietsmap.nl
BTW I cant see anything missing on the OFM Western Europe version, see http://www.openfietsmap.nl/downloads/europe
I sent. Please rectify mistakes. I am using the map from November 2012 and I am very pleased with it.
Thanks, I see the mistakes too, something has gone wrong with the map generation, I’ll investigate it.
Edit: The same roads are also missing on the generic map, so maybe it is caused by a failure during the map generation process,
so please try the next update later and let us know if it will be ok or not.
Some of you might have noticed, I’ve not been very responsive lately. I needed a timeout to recharge a bit and only performed weekly updates. Many many thanks to Ligfietser and others for responding to questions.
I’ve added --process-destination and --process-exits to the script parameters which should be used with the next map update. Question: Are extra parameters needed to get the new overview functionality? This wasn’t clear to me reading the comments on the Mkgmap mailinglist…
There are big upcoming changes to my life: I’ll be adding one more to this planet’s overpopulation 
Obviously, during the next months I’ll be putting less time in this project preparing for the new arrival, though I hope to still be able to make a few large additions in between other real life stuff that needs to be done.
Hi Lambertus, congratulations with your newborn! 
About the overview map, the settings should be in the style files (I have to update the OFM lite and the new generic styles first, but the default one should contain already the right settings).
Then it depends on your map generating process. After the splitter I suppose you will create all the img’s in the first mkgmap pass, and mkgmap will automatically produce with every single img one ovm_*.img work file. This ovm work file is needed to produce the overview map. So if you generate a country or a custom mapset (in the next step?), those ovm img’s are needed, but it is not needed for the gmapsupp.img and it will also not be included in the mapsource installer files (I think).
It is not necessary, but maybe it is wise to include those ovm files in the osm_generic_tiles.zip, so someone can combine a few of those mapsets later and create a big overviewmap (otherwise the combined big overview map will be empty).
I think it’s best to start with the Generic Routable and see if the overview map is created, if all works well I can update the new styles and the OFM lite with the overview parameters in a following update?
Thanks 
but we have to wait a few months, we’re still in the ‘breeding’ stage… 
Ah, that explains why the generic map does not appear to have the overview map. I added an SVN update for the generic map style to the update scripts.
Thanks this means I need to add some more changes to the final map generation step (which you called ‘the next step’).
I guess that’s fair though I hope these ovm files aren’t too big.
A new update is started.
Thanks!
Thanks Lambertus,
Just updated a view changes into the new styles and the OFM lite styles to implement the overview map, hope it’s not too late 
I e-mailed you a bug report about some missing junctions in Poland, seems something went wrong with your planet update?
Ah, yes, apparently I did not post my reaction on the missing road issue. So here it goes:
The source for the map updates is a local copy of the OSM planet dump. Each time an update is performed this copy is updated with daily changesets using the tool osmupdate. Osmupdate wants to know how old the current local copy is so that it can download the required changesets. My update scripts used to provide the date of the local copy which is possibly incorrect, so this is now changed to tell osmupdate to fetch 2 more days of changesets. I think that safely covers any possible gap during the update process.
Your changes will be included in the next map because the current update has been restarted.
Hi! Don’t know if someone already asked it, but anyway - I’ve just downloaded Ukraine and I don’t see any houses and its numbers on the map. Is it bug or feature?
Ukraine, Sevastopol, Nakhimova avenue
Consider native OSM:
Downloaded Ukraine map in BaseCamp (no houses and house numbers):
