Thats because there is not enough information entered on OSM, the address search (when there are no housenumbers available on OSM) “guesses” in which place a street is located by looking at the admin_level=8 boundaries: http://www.openstreetmap.org/browse/relation/959849. (in the coming updates it will start looking for 10 in Austria first, if that isnt found it takes level 8). If there is no boundary at all, it will search for the places which lies the closest to that street (which could be the wrong village node if that lies closer).
I dont know how or if the administrative districts in Austria are related to the place names and addresses, if they are not entered on OSM, you will get garbage in, garbage out
ok, now country select is ok again, strange behaviour of my nüvi …
should the “Gemeinde” prefix already be removed?
process destination is displayed in the map but not in the route instructions … btw. highway exit numbers /names are also not displayed
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.
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?
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!
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?)
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.
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?
