He is using Main St as a hypothetical example. Translated it is Via Principale. In English we have road, avenue, crescent, lane and a few more. This is what he refers to as type. It seems common for Italians to know the name part, but not the type.
I believe the problem is with Garmin only searching from the beginning of the name string. Users of Spanish, Thai and no doubt many other users have the same problem.
It’s a usability problem. The street can only be found if you search for complete name. The problem is that you don’t always know the way qualifier (“St.” “Av.”, …) or how the contributor wrote it in OSM, and in other languages like spanish the qualifier is before the name.
There is some work in progress to solve or avoid the problem in the following South America map. http://www.i-nis.com.ar/osm/garmin (scripts to make the map are GPL)
You are correct.
It’s not only a problem of trying if a way is defined as street, road and so on. In Italy the common name tag value of OSM is of the form: type of the way / name / surname
e.g. Viale Dante Alighieri, Via George Washington, Piazza del Duomo. So in order to match a way you have to know in advance the type of the way (street, avenue…) the name and everything that is in the OSM name tag value in the correct order. That can be a daunting enterprise.
Here you are not correct. In my old Nuvi 205 if I use the Garmin maps I can enter Dante, Alighieri, George, Washington, Duomo and I get a list of results. If I do the same with an OSM map, 99% of the times I get No Matches Found. 
Isn’t it possible to create all the (reasonable) combinations of the parts of the name and add all of them to the index search?
For Via Dante Alighieri you would add:
Via Dante
Via Alighieri
Via Dante Alighieri
Dante
Alighieri
Dante Alighieri
Thank you
maxx
Thank you, I downloaded the source and will try to adapt it to the italian naming rules.
bye
maxx
Thanks Maxx I understand the problem now. This index search problem is a longer existing mkgmap issue.
Popej just posted a possible fix to deal with this problem on the mkgmap dev list, so maybe this can be solved soon:
http://gis.19327.n5.nabble.com/multi-word-street-search-td5750803.html#a5826288
Hi,
Do you heave any idea when a new version of the map is available?
Cheers,
Sieds
The generic_new map is already updated, the other two are expected to come online in a day.
Edit: no, only the update for OFM lite is still running.
Thanx for the good work!!
I wasn’t able to post the question due to unstable internet connection and obscure links
We’ll be happy to relay your question
I’m getting some questions about installing more then one custom map alongside each other on Windows (BaseCamp). I’m not too familiar with this process, so I’d like feedback on the workflow so I can update the wiki FAQ.
This is what I’ve done:
For every new custom map the same sequence of events is performed, each time using a new unique ID and name.
This process seems straightforward enough to me. However, when I install the second custom map, the map installer will warn that there is already a map installed. This warning can safely be ignored but it is confusing to a lot of users. What can be done to prevent this warning?
I think the problem is that GMTK doesnt remove the map installer when updating the map data.
So there are two options, adjust GMTK or adjust the custom map procedure by letting the user enter a unique FID and name before generating the map. Maybe contact Javawa by pm to discuss this?
Is it possible for you to provide the maps in two encodings? This way you have maintained compatibility with older devices while the users who need Unicode maps can download them from here. Unicode support is a serious issue and affects the bulk of OSM data being developed in Asia. Imagine local street names in Arabic, Persian, Chinese, Korean, Japanese, … Older and incompatible devices are unusable for these regions anyways.
Free Unicode maps won’t work in newer devices like Edge 1000, GPSMAP 64, some recent models of nuvi. It looks like Garmin decided, that all Unicode maps should be digitally signed, which can’t be done with 3-rd party tools.
Hi,
first of all: Thanks for the great maps!
I recently tried the “new style” on my Nüvi 1255. During daytime everything is very nice, but the night-mode looks ugly - there are many black areas along with even more almost white areas. Can I do something about this, maybe using a dedicated typ file?
Another remark: I’d appreciate a style with a few less details, e.g. I don’t need every single house in an urban area rendered. This would help with older and slower devices like mine.
The night mode is totally undeveloped so any volunteers who want to improve this feel free to help.
You can edit the typ file with tools like typviewer and typwiz.
The typ file you can find in the metadata folder of the download link.
In order to change the typ file of the map on your device, you can use typchanger
Mueschel, just set your device to day mode only and it will be fine. You may want to turn down the brightness at night…
typviewer seems to be a fairly easy tool to change colors. But, typchanger doesn’t work at all. After adding the files and clicking ‘change’, it just displays ‘Done’, but there is absolutely no change made to the map file. Do you have any advice how to debug this or another tool to accomplish the task?
Thanks, gmaptool works fine. I changed some of the colors for night mode. For sure the result is not perfect, e.g. I did not manage to remove the white outline of paths and unpaved roads in night mode - my device seems to ignore this setting. Anyways, the result seems much more pleasing than the default colors. I uploaded the changed typ-file in case anyone is interested: http://osm.mueschelsoft.de/24276.typ