Worldwide routable Garmin maps: URL REMOVED

OFM doesn’t have those red tiles anymore, but I do see a lot of red tiles in the generic map. I notice the tiles in the ocean are not matched together (because you use --no-trim=true). Any reason for this to use --no-trim? Maybe it helps to solve the splitter problem to leave this parameter out (the generic new map is fine).

Well, I thought the -no-trim option should prevent this behavior instead of provoking it. :wink:

But I’ll try it for the next update (after the one that’s currently running).

I never use --no-trim because it makes gaps in the ocean, so I guess it’s better to leave it out :wink:
If I search on the mkgmap dev list, I find this comment from Gerd:
http://comments.gmane.org/gmane.comp.gis.openstreetmap.mkgmap.devel/13701

The problem with the red-squares is solved, also for the generic map. :slight_smile: The script now expects at least 2 tiles from Splitter on each subsplit and when just one new tile is found it will simply render this without further tests. This is a solid work-around that even works when Splitter eventually gets fixed.

Next up: reducing the number of map variants (Windows, gmapsupp, gmapi, tiles) to reduce the CPU load. Especially the NSIS installer for Windows uses a lot of CPU cycles. Ligfietser’s OFM map shows that it’s possible to combine a small installer with the tiles in a single zip-file, resulting in the need for only one file for both Windows as Linux.

Edit 22:00 CET:
I’m guessing about 40 tot 50 people are downloading at the same time from the country server, the harddisk is maxxed-out and 200+ MBit/s is pumped out the ethernet port… :sunglasses: :smiley:

Why has my Norton Anti-Virus software blocked this website as a “known malicious” website, as of this morning?

I think it is a false positive, these things happen. You can check yourself by testing the website using online virusscanners like http://www.virustotal.com

Bodee, please also report it at https://submit.symantec.com/false_positive/

Ligfietser, I have a first test map that includes a small installer in the _tiles.zip. BaseCamp shows the map alright. :slight_smile:

Only difference is that this installer does not move+install the map in \Garmin\maps but simply in the directory where you unpacked the zip file. Do you think this a problem for end-users?

I know the tiles are just a random selection, this test is purely about the _tiles.zip file and the small install.exe

I understand this new approach takes a little more effort for the user than just click on the exe installer and let the installer do the job.
As long as we give them good instructions about the changes (perhaps in the wiki?) I dont think its a problem?

The only big difference is that the users need to do an extra step,

  1. unpack it to the location where you want to put the map
  2. look for the install.exe file and execute this

BTW another problem, the install.exe might be detected as false positive by some scanners :confused:

And there was much yayness \o/ :slight_smile:

Hi,

newbee question:
How can I give the maps in BaseCamp meaningful names?

I composed two maps for two trips. Now I get the osm_generic_new_gmapsupp…exe file, I use the Windows Version and execute it. After that I have one map in my basecamp. But now I want to install a second map of a different Region. How can I do this having meaningful names in the Basecamp Dropdown box???

I also installed the map on my Germin device copying the map to a SD Card and rename the .img file, this works fine.

With best regards

Gerhard

PS: Want end up with the tracks of all my trips and having all maps used for that trips in basecamp

You can rename the maps with JaVaWa GMTK: http://www.javawa.nl/gmtk_en.html

I noticed that this landuse=reservoir was not showing on my oregon 300 gps it is showing in basecamp.
https://www.openstreetmap.org/#map=17/36.16946/27.99237
generic routable new 13-06-2014 greece

The other thing, in basecamp a lot of the islands in Greece are rendered with hatching, If i look at the data in the editor there is not anything defined.
So for instance next to the reservoir there is “nothing” while the whole of Rhodes is hatched, including the reservoir.

And something else that i noticed while walking around in the old city of Rhodes with my gps is that those streets are rendered as very thin white lines against a light background on even the maximum zoom in level. Making it almost impossible to see the roads inside the old town.
https://www.openstreetmap.org/#map=18/36.44260/28.22540

Mafketel, sounds like this is caused by a missing typ file, there were some errors in the map generation a few weeks ago (see http://forum.openstreetmap.org/viewtopic.php?id=2625&p=87)).
Could you please try the latest version?

That removed the hatching for the Islands and made the map more readable with basecamp.
This map is installing on my gps as we speak… but this always takes a long time with my mac… And if I don’t install them and just copy the gmap image from the website every time I open basecamp it will load the map from gps and I have two identical maps as a choice in basecamp (one from gps and one already on pc).

By the time I was done checking and changing Crete I could also check my gps where the old town and the lake are both rendered correctly now.

Crete is a different matter though. I already noticed that the hatching was much bigger then the Island, partly 10km GISCO buffer zone and the other side is Crete/south aegean periphery.
I Assume this is a data problem at osm and I am willing to change it except I have no idea what is wrong :wink: scratch that I think I know what is the problem and I hope I fixed it.

… I assume it is the multipolygon Κρήτη (Crete) 453129 and then in particularly the fact it was tagged place=island , which I just removed.

So that should be ok in the next rendering :wink:

Correct, the tag place=island is rendering the whole boundary as island. I’d better make this polygon invisible instead of rendering it as land (hatched pattern if you dont use a typ file), because I fear more mistakes are made with this tag.

Provinces mixed up in Thailand:

Search for the city of Suphan Buri, located at N14.46762 E100.11834. In Mapsource and the GPS all places in Suphan Buri province that I have seen so far are shown as located in the neighbouring province:

Suphan Buri
Phra Nakhon Si Ayutthaya Province, THA

Suphan Buri is capital of the province with the same name.

I notice something strange as I point my mouse at the provincial boundaries. W of Node: 2902644726 it shows both province names, E of this only one. At this point the boundary for a national park splits off. I don’t understand enough about relations to troubleshoot this, so I would be glad if somebody could take a look. I don’t even know whether this is related or not.

Info about the node:

Node: 2902644726
  Data Set: 63db73
  Edited at: 2014-06-06T10:13:24Z
  Edited by: Paul_012 (100662)
  Version: 1
  In changeset: 22771905
  Coordinates: 14.8350687, 99.3081859
  Coordinates (projected): 1.105493668599175E7, 1670199.6986975581
  Part of: 
    Way: 286584848
    Way: 286584849
    Way: 141066689

I don’t even know whether this is a Garmin map problem or a problem with the data.

I think rendering place=island as land is correct, just need to fix the mistake in the data :wink:

And i think it was the only one in the area I looked at.

@Beddhist sounds like a data problem, make a map note if you don’t know how to fix it :wink:

Peter, could be a broken boundary problem in OSM, maybe it is fixed in the next update because it was edited recently: http://www.openstreetmap.org/relation/1908824 (seems not broken now)

Thanks for noticing it Mafketel, because I now see that this place=island polygon is causing more issues, like covering too many details (like covering other landuse types) so I have to made it invisible in the TYP file anyway. Now it will only render the island names. Land area is already rendered by the coastline tags so there is no need to do this with a place=island tag.