ValentinAK <valentin_k@inbox.ru> wrote:

What about Russian? Many users in Russia use mkgmap with -charset:cp1251 or -code-page:1251. The index-branch version 1861 does not work correctly with the Russian character set.

Hello That is a good point I will make sure that it doesn't crash or work badly compared to trunk. It should also be possible to create a sort description that works properly with Russian so I will send another email later about how you could help make that happen. ..Steve

Hello On 26/02/11 16:46, ValentinAK wrote:

What about Russian? Many users in Russia use mkgmap with -charset:cp1251 or -code-page:1251. The index-branch version 1861 does not work correctly with the Russian character set.

To support code pages other than 1252 we need to create files that describe how the characters are sorted. The following will be of interest to just about everyone. This is specified in the SRT file and I have created a text file format that can be used to create these files. However I don't know 100% how it works, so some things have to be guessed. At the top of the file there are the following: # The code page codepage 1251 # I have no idea what these are for, but they are important # and if they are not present everywhere they should be then # things will not work. I don't know if they simply identify the # sort or have some other meaning. id1 7 id2 2 # Any descriptive text description "Russian Sort" Then there are the characters and how they should sort. The file itself is in utf-8, but characters can be represented either by themselves (in utf-8) or by a two character hexadecimal representation of their value in the target character set. Every different letter is on its own line, eg: code A code B Characters that differ only in case are separated by a comma: code a, A Letters that differ only by accent are separated by a semi-colon code a, A; á, Á Today I found this site: http://www.collation-charts.org/ which is a good source of information. ..Steve

El 26/02/11 17:46, Steve Ratcliffe escribió:

...

...

I still have the missing "Calle*" streets on MapSource. Any chance to fix it before merge? ________________________________________

Does that not happen on the current trunk too?

No, it works fine with trunk on the same input files.

If it doesn't then perhaps it is something that can be fixed but otherwise it is a case of new development to deal with this case, including configuration so that mkgmap can tell that "calle" is an ignorable prefix for searching purposes.

El 26/02/11 22:58, Steve Ratcliffe escribió:

Hi

...

...

Does that not happen on the current trunk too?

No, it works fine with trunk on the same input files.

Interesting, I'll try and compile a map of Spain and see if there is anything obvious that is wrong or different. In case you want to use the same options, below you have my relevant commands: osmosis --rb spain.osm.pbf --tf reject-ways source='EU%sCORINE%sland%scover%s2006' --tf reject-nodes "rednap:codigoine"=* --write-pbf file="spain-filtered.osm.pbf" omitmetadata=true java -Xmx1000M -jar splitter_pbf.jar --max-nodes=2800000 --geonames-file=cities15000.zip --mapid=55140001spain-filtered.osm.pbf #I know max-nodes is quite too high, but after removing CORINE data with osmosis there's a lot of unused nodes. trunk run: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args index run: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-index.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=39 --product-id=1 --series-name="OSM-España-index" --index --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --style=mio -c spain-index.args

There is a section MDR8 which I added which is an index of the first four letters of the street name into the streets section.

Now I think that would probably work OK, but there is one problem. In one case there is "Calle" spelt with a C-cedilla "Çalle" (is that even correct?).

Anyway when I search back to find the first street name beginning with "CALL", I stop after "ÇALLE REAL" because the search treats it as a different letter and so the first street that is found is "CALLE REAL (A-8076)"

Hi Steve, I'm not deeply involved in the current index code, but should the accented 'c' not beeing converted to a standard 'c' in the index? If I enter the street names in my etrex, I can enter the base character, i will get all streets which contain at this position special characters. In german I can enter the character 'o' and even umlauts like 'ö' will be found. So I think at this index there should be the the special charcters converted to the base characters. Regards, Johann

Am 28.02.2011 00:17, schrieb Steve Ratcliffe:

Hi

...

I'm not deeply involved in the current index code, but should the accented 'c' not beeing converted to a standard 'c' in the index? Probably yes for MDR8, but for the street index, no.

...

If I enter the street names in my etrex, I can enter the base character, i will get all streets which contain at this position special characters. In german I can enter the character 'o' and even umlauts like 'ö' will be found. So I think at this index there should be the the special charcters converted to the base characters. All the accented characters are sorted together, almost as though they were the same character, so that is why that works.

..Steve

Yes, this is my view too. This is how I expect it to work. So if there is an existing sorting function doing it this way, then there must be a compare function handling it correctly, i.e. doesn't distinguish between the different accentuated c's. Should not the same compare function be called in the search function for generating MDR8? Then there will be no different entries for 'call' / '¢all'. (Sorry, don't have the special char on my keyboard) I expect the same sorting/comparing rules in all MDRs. Regards, Johann

Found another bug in mkgmap-r1875. If I search for adresses on a Dakota, and skipping the place name (because often streets are assigned to the wrong place) and enter the streetname, the street is found but it points to a place in the Atlantic Ocean south of Ghana (lat0, lon0).

El 26/02/11 23:45, Steve Ratcliffe escribió:

On 26/02/11 22:30, Carlos Dávila wrote:

...

El 26/02/11 22:58, Steve Ratcliffe escribió:

...

Hi

...

...

Does that not happen on the current trunk too? No, it works fine with trunk on the same input files. Interesting, I'll try and compile a map of Spain and see if there is anything obvious that is wrong or different.

In case you want to use the same options, below you have my relevant commands:

OK thanks. I found the problem straight away on my first guess!

There is a section MDR8 which I added which is an index of the first four letters of the street name into the streets section.

Now I think that would probably work OK, but there is one problem. In one case there is "Calle" spelt with a C-cedilla "Çalle" (is that even correct?).

Anyway when I search back to find the first street name beginning with "CALL", I stop after "ÇALLE REAL" because the search treats it as a different letter and so the first street that is found is "CALLE REAL (A-8076)"

For the moment I am disabling the section, (I was wondering if it was even used, but I guess we know now that it is used by mapsource).

Now I get the same list of streets "calle*" than in trunk. You can go ahead with the merge for my side.

El 27/02/11 09:33, Marko Mäkelä escribió:

On Sat, Feb 26, 2011 at 11:30:50PM +0100, Carlos Dávila wrote:

...

I know max-nodes is quite too high, but after removing CORINE data with osmosis there's a lot of unused nodes.

Side note: Have you considered adding --used-node to the osmosis options after the --tf? Yes, but wouldn't it remove *all* nodes that are not part of a way? Or does it affect only the nodes of the ways filtered by the --tf instruction?

Am 27.02.2011 09:47, schrieb Carlos Dávila:

El 27/02/11 09:33, Marko Mäkelä escribió:

...

On Sat, Feb 26, 2011 at 11:30:50PM +0100, Carlos Dávila wrote:

...

I know max-nodes is quite too high, but after removing CORINE data with osmosis there's a lot of unused nodes.

Side note: Have you considered adding --used-node to the osmosis options after the --tf? Yes, but wouldn't it remove *all* nodes that are not part of a way? Or does it affect only the nodes of the ways filtered by the --tf instruction? You're right...all nodes would be removed, if they doesn't belong to an unfiltered way.

Henning