I’ve implemented this as a filter using Osmosis (that was easy). The resulting tiles are about half a megabyte smaller, but I’ve not published one of the test runs yet.
But, regarding Translit, it’s a bit of a bottleneck while processing on a multicore machine. Do you see a possibility to do the translation in parallel? Or, alternatively, you once wrote that you were working on integration into Mkgmap? Any progress?
Damnit, then why does one of the fella’s at that mailinglist calls himself ‘stylesheet maintainer’?
I’m sorry that this doesn’t get resolved, but I’m really not going to create an maintain my own stylesheet. If the default stylesheet of Mkgmap becomes really outdated and there isn’t a good alternative one then I’ll cancel this service.
Is there somewhere a good alternative generic Mkgmap stylesheet that is being actively developed?
It appears there is an error somewhere in the UK country definition of perhaps it was a glitch during this build. I know that some countries haven’t been defined well enough (UK and Italy for example). Still haven’t looked at it yet. But you can always manually add and remove tiles to the selection.
At the moment I’m working on other things. But it is my to do list. I first would have to do this under windows. Then under linux. To be honest: I have not the slightest idea how to do that under linux.
Steve R. asked me to help with mkgmap. But that’s the same story of what comes first. I did not do anything for mkgmap yet.
Remember my aim was to use transliterated maps in my garmin driving east and now I can…
If you start with using a POSIX compatible threading library on Windows, then Linux won’t give you much trouble. PThreads might be useful if you use C or Boost if you use C++.
I don’t mind if you help Mkgmap first. On the contrary, I probably won’t be needing Translit if Mkgmap has good native transliteration (and I already run Mkgmap in parallel, something I cannot easily do with Translit on my current build scripts. Hmm, although, at a sudden I do see a new possibility now. I’ll get back at that…).
Besides about speed, threading and other such nitbits, having this in Mkgmap would probably be preferable anyway.
Yes, I know. And I know how things go when the important items on the todo-list are done. I don’t blame you, no, instead I’m grateful for your work. You know that.
When time, priorities and interest fail, you could also consider to make Translit OpenSource. I don’t think this is the case, but if so: it doesn’t matter if the code is sloppy or that you’re ashamed of your coding abilities. If perhaps there is a copyright issue that is holding back the release of the code then maybe I and others can help find a solution.
What it comes down to is this: the transliteration abilities of your code have shown their worth and would benefit a lot of people (not only me, my website or my map users). In case you loose interest in the OSM project (or something worse) then your OS code might still be used many years to come, but now everything depends on Linux’ backward compatibilities and your ability + willingness to fix any problems. That is not a healthy situation.
A new version is up. The tools have been updated to the latest versions but the biggest change is the enabling of the sea polygons. I hope it works ok, but I guess I’ll be hearing about a lot of problems with missing islands and sections of flooded land. So it will probably be disabled again on the next update, but we’ll see…
Edit:
Ok, the map is going offline again. The sea polygons are showing up much worse then I thought…
Hi
Can you add functionality/option to download archived osm file from selected territory? I have customized mkgmap a bit…
Another suggestion… When mkgmap is used with command-line param --charset=windows-1251 it produces good cyrillic map without transliteration… Can you add this functionality too?
No can do I’m afraid. There’s not enough disk space on the server. And it’s not needed because OSM planet or country downloads are available from other sources. Also, splitting the data is easy and can be done on modest hardware. So I don’t really see the advantage.
Not every GPS is supporting charsets other then Latin1, afaik. What GPS type are you using?
So, it seems that you have a modern Garmin which supports it, but many others don’t and I won’t disable the transliteration unless I’m sure that older devices handle cp1251 well too. Still, even if they do, maybe I’ll keep transliterating…
This is my first post to the forum. A million thanks to you for providing such a wonderful service. I have been using your service, the routable openstreetmap for garmin (Nuvi 1390T) for a month now and have started contributing by mapping the areas known to me during my holidays and free time. I live in Bangalore.
I do not know if this is the right forum to report bugs. I wanted to report a bug that I found on the openstreet map for garmin.
When I select “Where To” → “Point of Interest” → “Hospitals” and select a Hospital from the list of Hospitals and then click on the Name of the Hospital shown on the map, it displays “Food” (should have been “Hospital”) beside the blue “+” symbol.
Now, that is strange. I just HAD to test this out on my Zumo660 and I can search for hospitals and there is no food displayed anywhere with them. Must be specific to your Nuvi.
However, I have found something else disturbing: the OSM map doesn’t overlay the basemap, rather they are both displayed at the same time:
You can clearly see the basemap road going through the centre of Mae Sot and the relief shading also belongs to the basemap.
It’s still there @ 5km zoom, but zooming out any further makes most OSM data disappear, leaving just the basemap road and a few towns from the OSM map visible.
I tried disabling the basemap, but on the Zumo that doesn’t seem to be an option.
Not sure, but this might have something to do with the layer priority (e.g. the basemap has a higher priority then the OSM map). If the basemap is transparent the you’ll see what you see now. Maybe Charlie Ferrero can provide the yes/no on this?
I double checked. There is no transparency option used, so the OSM map is not (should not be!) transparent.
TYP file yes, but style no…
Altough any help with improving the default style sheet is welcome, seems the guys on the mkgmap list are not so willing to change it.
If the OSM map is being created as opaque (i.e. no --transparent option) then the base map should be hidden. I think this may be a “feature” of the Zumo. I’ve not heard of the base map showing through the OSM layer on other Garmin devices (which, in most cases, let you disable the base map anyway).
Not unless your mkgmap compile is really strange. I can’t imagine why the base map draw priority would be set high; in fact I suspect that the base map isn’t treated the same way as other maps by GPSr (at least on my GPSMap). For instance, if you try to route, the GPS will never route on the base map if another routing layer is available. I would have thought the firmware would ensure that the base map was always drawn below any other map, but that’s just a guess.
