All my OSM maps in Roadtrip and on my Garmin Colorado 300 have a blue dot POI in the middle of every road.
The whole map looks like a martian with chicken poxā¦
From what I have found, the option
āroad-name-pois= 0x2f15 (or a different code)
does this to allow searching roads. Did you turn this on recently (in the last week or two)?
Itās not needed to use Terminal to do that.
Open a Finder window and delete ~/Library/Application Support/Garmin/MapInstall/lastSelected.gdb. No need to delete the .plist.
I noticed this crash about a year ago and posted over in forums.Garmin.com but they were clueless.
Actually, I was finally able to reproduce your problem today. I received the same error about the damaged map installation and the crash of MapInstall. I believe this occurred because I had just re-installed a re-compiled version of a map. This was the same map which I had previously selected and sent to my GPS device, only this time, the map had fewer tiles than before. Since MapInstall attempts to save the last selected tiles between runs, I think it tried to select a now non-existent tile, causing the error.
At any rate, to solve the problem you donāt have to use Terminal, and you donāt have to delete anything. Just do the following:
Make sure MapInstall is not running.
Open the following folder: /Library/Application Support/Garmin
Rename the folder āMapInstallā to āMapInstall.oldā (or rename it to āMapInstall.2ā or something similar).
Restart MapInstall. You should now be able to reselect and transfer your map tiles without error.
(The folder which you renamed contains a file which saves your last-selected tiles. When the MapInstall program cannot find the folder named āMapInstallā, it creates a new folder with an empty selection file.)
Why not just delete it instead of renaming it? If not, youāll just have a useless old folder laying around.
Renaming a folder is good practice if you are troubleshooting and may want to put the old folder back if itās not the problem.
But it is the problem, soā¦
I find it also good practice if you are not sure what you are doing. The original poster mentioned this, and mentioned that they were nervous about deleting files which they did not know about.
I therefore often recommend this approach in instructions to others, as it is non-destructive. If the person following the instructions misunderstands something and renames an incorrect file, then there is no harm done: they can simply revert the change. On the other hand, if they delete an incorrect file and empty the trash, they will have to hope that they have a good backup.
On modern OSes a few extra folders lying around will make no significant difference, neither to performance nor to disk usage.
The country definitions for the presets are not optimal yet. There are a few other countries with the same problem. Should fix in the coming weeks.
Yes, that was turned on for this update, but only using the āāroad-name-poisā option. Iāll see if there is a POI code that doesnāt show up (prominently) on the map.
I am a grateful user of your map tiles. Stopped using the installer in favor of compiling the .img files into my own index files. Works fine using mkgmap. However, Iāve got a question. Iād like to be able to selectively replace individual tiles as I add map features to OSM. If I download a tile on date X, then on date Y (3 months in the future), I download a fresh copy and the tile number is the same am I asured that I will have a compiled map with no gaps or overlap? If there is overlap how will I know it? Iād prefer not to opverburden your servers by asking for the entire collection I am maintaining, which covers 6 states in the US and exceeds the tile count limit.
The tiles will/may vary per site update. You can check if a tile has changed by just remembering the area it covered. But better by watching the world.kml file (under the link ātemplate fileā). Save it and download again for a new update. Compare the coordinates for a tilenumber. (Just open the files in wordpad or notepad or any texteditor or what else).
Well, the overburden happens occasionally but Iām sure your request will not cause the system to go through itās knees
The way the tiles are generated now is not really compatible with your method of updating your map by downloading some -but not all- new tiles. Like greencaps says: the coordinates and tile numbers may vary on each update. Iām thinking about a way to let people like you just download the img tiles from the website without providing an too easy opportunity for leechers to just download everything everytime.
The problem with the maximum tile limit is caused by leechers who request much, if not the entire, planet on each update. That behaviour caused massive increased load on the system and bandwidth usage. Those rather few spoiled it for the rest when I added the tile count restriction. I consider the website to be a flexible service for people who travel through a few countries or who live near a border, not a service for those who wish to download large sections of continents that they will rarely travel anyway just for the sake of having it. I hope you (anyone) will accept my choices in this matter.
Maybe a smarter option could be developed to restrict abuse like maximising the amount of traffic someone generates over the course of, say, several weeks instead of the single-request-tilecount restriction that is implemented currently. I donāt know reallyā¦
Youāre hooked, I can tell
The next update is staring next Thursday after the new planet dump release. Iāve been on holiday last week which explains the delay.
Not 100% sure, but I guess itās not going to work. The inter-tile routing depends on special edge nodes that line-up perfectly in both tiles to be able to route from one tile to another. There also might be other caveats, perhaps not even routing related, that could happen. You could try it and see what happensā¦
Based on the reports so far, Iāve decided to remove the --road-name-pois feature for the next update. It does more harm then good IMHO. The country/state option in the address search on some models just needs to get fixed in Mkgmapā¦
Thanks for the input. I guess Iāll just request updated tiles in chunks that and make sure thereās goodly gaps between them so with no overlap i can update selected āchunksā.
How often do you update the maps? I was under the impression that your maps where updated monthly. I to have done a lot off additions added to the OSM data and looking forward to seeing my contributions.
Your mainpage indicates āBased on OpenStreetMap data from: 10-02-2010.ā I been eagerly coming back almost daily to see if the maps are updated. I was under the impression that thereās been no updates since the 10 of Feb.
I just had a look and noticed that the info on your homepage still says Based on OpenStreetMap data from: 10-02-2010. I decided to download a map. and when I had chosen the Australian map download it says last updated on the 4 of March, yesterday. I got a bit excited and quickly downloaded the map. Just installed onto my Mac using Roadtrip and it looks to still be based of a map from early February. Even tracks I put in a few weeks ago are not on the maps.
Iām a bit confused now. Why does the download from today say itās updated yesterday, whereby the map is still the same as a map I downloaded a month ago. Am I doing something wrong?
Usually the maps are updated weekly. But I was on vacation last week, so the current version is available for three weeks (I could not produce a new update in the time between when the planet dump became available and when I left).
The timestamp as given on the homepage is what matters if you want to see new data in the maps. The actual build date of a map is not of importance.
A new update is running as we speak, I guess itās going to be available somewhere Saturday or Sunday. Just keep an eye on the timestamp on the homepage.
New maps are going to be built after the next planet update (wednesday evening) and preprocessing (starting thursday until somewhere friday). So next update should become available somewhere saturday or sunday at the latest (provided there is no invalid XML in the planet dump like last week).