Non-ascii characters disappear in exported gpx file name

Could you please confirm and fix the issue? A test gpx is attached below as a zip.

I'm suffering from meaningless file names.

Hi ta-ka

this is not an issue in correct word meaning. Actually it's an intent.

Check this problem - http://forum.locusmap.eu/index.php?topic=3796.msg28637#msg28637 . Since this, I added improved version of "generator of file names", that remove all special characters, except A-Z, a-z, 0-9, _, - ... and convert all chars like ö to simple o and similar.

Unfortunately it also remove all special characters as I see in your screenshot.

I'll try to check it if there is any way to improve it ...

EDIT

Oki, I think I've got working solution which correctly change some special characters like mentioned Ö, but also keep Japanese characters in file names. So in next test version, please try it and write me if there will still be any problem. Thanks

Hi, Menion. Thank you very much.

I'm looking forward to check it with next test version.

Meanwhile I'll follow and read the discussions in the link you indicated.

Thanks again.

You are welcome. Nothing serious in mentioned link. There was just an issue with export for files to KMZ, where Google Earth was unable to read them in case, in file was any special characters.

I tried Locus 3.0.2.1 and confirmed the improvement with the previously posted export_issue.zip. Thank you.

Unfortunately there are still some problems. Please have a look at an example png and gpx(zip) below. In the example, the character U+30D0 in unicode was converted into U+30CF.

I would like to ask that characters in unicode range from U+3000 to U+30FF (in UTF-8 from E38080 to E383BE) shouldn't be converted.

I also want to confirm, that export to gpx file cuts off cyrillic letters. I want to ask you not to convert file name - at least for gpx files..

Guys, I have to ask, is this really a problem?

Problem was in first step, when Locus removed some characters. Understand. But latest test version should keep characters, but for example in Czech, it just remove diacritics, nothing more. So it's not a problem at all.

I don't know how big is difference between U+30D0 and U+30CF, but for example between U+0159 and U+0072 is very small difference and in Czech, it's no problem. It's just like writting SMS with basic 26 latin characters.

Maybe something changed in test versions, I use latest from playmarket, 3.0.2.

I'm from Russia, and for me is much better have exported file called something like 2014-06-08_15-44-32_пущино.gpx

now I have file 2014-06-08_15-44-32_.gpx - with cutted cyrillic letters.

of course I can write file names using 'translit' - 2014-06-08_15-44-32_pushchino.gpx, but it's not what I was dreaming for - now I have to rename file in file manager after export.

I know that there is an issue with non-ascii letters in kmz, but for gpx conversion is not necessary.

I have to say that this is really problem for Japanese. It's not removing diacritics but changing or even destroying the word.

> I don't know how big is difference between U+30D0 and U+30CF

In this example, the original word was 'bike', and it became 'hiking'. Please note that in most of the case other than this example, the word becomes meaningless and strange.

> between U+0159 and U+0072 is very small difference and in Czech, it's no problem. It's just like writting SMS with basic 26 latin characters.

I see that removing diacritics in mobile or PC is usual practice in European Languages so my example might seem like the same practice. But in fact it's not. U+30D0 have to be always used as it is. Of course for SMS too ;)

Well ...

I'm confused and not sure if I understand well the kmz problem on Google Earth. Is it correct that files with non-ascii character in kmz file cause a problem and kmz file itself with non-ascii character cause no problem? If so, removing special characters of the files inside kmz including removal of Japanese and Cyrillic characters and keeping any kind of characters of kmz file itself will be a solution.

Thanks guys, understand. In Czech, when you remove diacritics, it usually do not completely change a meaning of work. It's big difference.

Because currently problems with this are really only in inner KML file of KMZ pack, I'll try to next test version add this "optimization" only to inner KMZ file and we will see if it will work as expected.

Thank you for your understanding, Menion.

I'll wait for next test version.

You are of course welcome. I'm sorry for this, because it's my problem. I'm little bit clever now, how these weird characters (for middle europian), works :)

I've confirmed with Locus 3.0.2.2 that important basic Japanese characters aren't removed now on exported file name. Thank you very much.

Now, looking at kml file name inside exported kmz file, Japanese characters remain and Google Earth fails to open the kmz.

So, for kml file name inside kmz, would you please remove all special characters (except A-Z, a-z, 0-9, _, -...) as before? As a result, ".kml" file without base name in kmz will be potentially created. But it won't be a problem because Google Earth and Locus are able to open it.

Firstly thanks for testing.

This is anyway interesting. Because it should already works as you write. So KML file name should be without special characters (not all, but removed should be all as was here http://help.locusmap.eu/responses/non-ascii-characters-disappear-in-exported-gpx-file-name#comment-10547

Seems it's not enough to make KMZ working? I've tested it on some Czech texts and it worked correctly. So may you please write me a name of "waypoint", which exported to KMZ, do not work? Thank you!

The test had been done with a track on GNote2(4.1.1).

I tried the test again on HTC J(4.0.4) taking screenshots shown below and got the same result. May I ask you to try it with attached kmz file?

Meanwhile I'll try another test with "waypoint" (means normal point, right?). Thanks.

I've done a test with the point by using 'export_issue2.zip' in my old post above and got an negative result as shown in attached screenshot.

The kmz file name is as same as original point name (bike). This is good. The kml file name is changed but still contains Japanese character (hiking).

hmm I'm looking on some sample files from Google (samples of KMZ files), and all files has inner KML file named as "doc.kml". What if Locus export KMZ where will be always doc.kml file inside? It seems for me as a best solution.

Because when I try to optimize name with japanese characters to ascii name, I get probably only ".kml" :). doc.kml should be the best way.

I agree with your solution. I was also thinking to suggest the same way.

I've confirmed that Locus 3.0.2.3 creates doc.kml inside kmz and Google Earth opens the kmz then goes to its location. Thank you very much!

BTW, GE shows tracks but not points. I guess it's GE side issue.

So major issue is now solved, perfect.

What about points? I've just exported and tested huge pack of various points and seems they all works correctly. May you please describe step by step, what should I do to get same problem? Thanks

EDIT: ah back! I see one new problem there. So sorry for this. Next try in next version.

Oki - fixed also a points. Thank you for you patience. Should be fine now ... uff :)

Ah, you found something in Locus. Anyway I tell you how to reproduce.

1. download the kmz by balloni55 at http://forum.locusmap.eu/index.php?topic=3796.msg28619#msg28619

2. import it to Locus with 'Marge points with track'

3. export it from Locus as kmz

4. launch Total Commander (or any file manager) and share the kmz with Google Earth

Then, GE goes to the location and the track is shown as blue line but two points aren't shown as icons.

thanks, I think it will be issue I found. Problem is that in exported file aren't! included styles for points. Please wait for next version, I'm sure it will be OK

Hmm... Icons are still invisible on GE with kmz exported by Locus 3.0.2.5.

I tested with the instructions in my previous post.

Hello ta-ka

thanks for testing. For my own surprise, exact method (except point 4.) works perfectly for me.

If you check content of exported KMZ, are icon and photos inside this KMZ?

This is the contents in kmz created at the instruction 4. with Locus 3.1.0.

löffelstelz.kmz

|-- doc.kml

`-- files

|-- punkt_1_1397399164990.jpg

|-- punkt_2_1397399246098.jpg

`-- z-ico01.png

I attached the kmz below. My observations are:

1. If kmz is opened by Google Earth via total commander, only track is shown as blue line.

2. If track with points (at instruction 2.) is directly shared to GE from Locus, both track as blue line and points as red arrow icon are shown. By tapping the icon, description is also shown, but no jpg image.

3. If kmz is opened by Google Earth on PC, everything (track line, points icon, description and jpeg image by click the icon) are shown.

That's all...

Hmm yes, I have same experience with point 3. I never before tested result in Google Earth directly on device, but seems this app has some problems with it as you mentioned in steps 1. and 2.

Anyway generally, I believe that GE on PC is a better app for confirmation that exported file is OK. From my previous experience with GE on Android, I remember that this won't be only problem this app has.

So, finally we have somehow understood and fixed the kmz stuff. :)