GPX file output

[muddylanding]

I have a Filemaker Pro script which writes a text file in GPX format. 

The resulting text file works correctly when running on Filemaker Go (on an iPad or iPhone) BUT when the script runs on MacOS under Filemaker Pro 17, the resulting GPX file won't work correctly with several applications which use GPX. The file looks identical but just won't work.

The file written under iOS on an iPad works fine after being transferred to MacOS. It appear that the same script creates a different file under iOS than under MacOS.

The script uses "export field contents" from a single global record.

I'm guessing that "non printing" characters like CR TAB LF may be the issue. Can anybody confirm that iOS and MacOS use different characters when using "export field contents"?

Anybody got other ideas?

 

[Ocean West]

export field contents renders file as utf-16 

you can use new FM18 functions to create open and write a file and specify the UTF format or use BaseElements Plugin to do the same. 

[muddylanding]

Thanks! That just might be it. I have UTF-8 in the GPX file:

<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" Version="1.1"
Creator="Europe Diary">

So perhaps iOS use UTF-8 and MacOS UTF-16

 

NO!  I tried changing the XML  specification to UTF-16 but no go.  I will have another look at the Base elements plugin. It looks like another "Case iOS, xxx, MacOS,xxx,Windows,xxx" thing. Sigh...

Edited June 25, 2019 by muddylanding

[comment]

1 hour ago, muddylanding said:

The file looks identical but just won't work.

It's hard to tell what the problem is based on this description.

 

1 hour ago, muddylanding said:

I tried changing the XML  specification to UTF-16 but no go.

The encoding attribute in the XML declaration is descriptive, not prescriptive. Changing it changes the contents of the file, not its encoding. It's very easy to create a discrepancy between the two.

If indeed encoding is the problem here, you can change it by loading the exported file to a container and re-encoding it as UTF-8, then exporting the result (requires version 16 or higher).

 

Note also that in Filemaker Pro (though not in Filemaker Go) you can export your data as XML and use an XSLT stylesheet to transform the output to a GPX file. This is most often the preferred method to produce an XML file.

[muddylanding]

The problem is that although the iOS and MacOS files appear identical, the iOS file works with other apps and the MacOS file doesn't. The iOS file works under MacOS with a range of applications.

I'll have a go at your suggestion to import to a container and re-export.

I did consider exporting as XML but a GPX file unfortunately has some critical differences and my expertise in style sheets is near zero. Also, the usage (Navigation and trip logs) is mainly iOS based so not being able to use the same script on the Mac and in iOS would be a pain.

Thanks for your interest and advice

 

Edited June 25, 2019 by muddylanding

[comment]

36 minutes ago, muddylanding said:

the iOS file works with other apps and the MacOS file doesn't. 

As i tried to say, "doesn't work" is not a good description of a problem.

In any case, if you want to know the exact difference/s between the two files, attach them here (after zipping them to prevent changes in transit).

 

[muddylanding]

Two zipped files attached.

By "doesn't work" I mean the files can't be used by other applications. Typically the app will throw up "this file can't be opened" or "the file is corrupt" or will produce an empty waypoint set, to give three examples. The error message depends on how the application handles whatever the issue is.

The iOS produced example file works with all apps and applications under iOS or MacOS.  The MacOS produced file produces the error messages.

The same Filemaker document is used on iOS and MacOS

If I run a MacOS hosted Filemaker document and produce the GPX using a client iPad (iOS) the GPX file is fine.

GPX.zip

Edited June 25, 2019 by muddylanding

[comment]

These files do not have the same content: for example, the MacOS file has:

<name>GRONG Mixed Parking</name>

on line 16, while the iOS file shows:

<name>SOMNA Mixed Parking</name>

 

Other than that, the MacOS file uses UTF-16LE encoding and CR line endings, while the iOS file is UTF-8 encoded, with LF endings. I don't think the line endings should matter here because a well=behaved XML parser will accept either. OTOH, not all applications know how to read a UTF-16 encoded file. Especially if the XML declaration claims it's UTF-8 encoded.  It's too bad you don't have more detailed error messages.

As an aside, both files contain some "noise" in the form of invisible characters and a spurious "> after each wpt start-tag.

You can verify that encoding is the (only) problem here by changing it in a text editor and testing the result with your target applications. I have done this with your file and I am attaching the result here.

MacOS8.gpx.zip

[muddylanding]

Thanks so much for that, your explanation is clear and the file that you sent works with all the applications that I use.

I will have to get up to speed with encodings. In the past I have ignored coding types.

I see the fact that Filemaker Go and Filemaker MacOS use different encoding from the same FM document as a bit of a quirk!

From an earlier post I see that FM 18 gives additional functionality with text files and encoding so I will probably upgrade from 17. 

As I understand it, Plugins aren't really the way to go because most of my solutions are iOS based using FM Go.

Once again, thanks for your help.

[comment]

1 hour ago, muddylanding said:

From an earlier post I see that FM 18 gives additional functionality with text files and encoding so I will probably upgrade from 17. 

You can control the encoding in earlier versions too (since v.16, as I already mentioned above). Just add a global container field and do:

Set Field [ AnyTable::gContainer; TextEncode ( YourTable::Textfield ; "utf-8" ; 1 ) ]
Export Field Contents [ AnyTable::gContainer; “file:exported.gpx” ]

If necessary, you can change the line endings, too:
https://fmhelp.filemaker.com/help/18/fmp/en/index.html#page/FMP_Help%2Ftextencode.html%23

[muddylanding]

I've used the container approach that you suggested and it works perfectly.

I still think it's a bit weird that FM Go and FM Pro use different encoding for "Export Field Contents". Bit of a trap for young players!

Thanks for your help, much appreciated.

[Ocean West]

Few points from the 16 Help file, also reference to the TextEncode function 

https://fmhelp.filemaker.com/help/16/fmp/en/index.html#page/FMP_Help/export-field-contents.html

• FileMaker creates a UTF-16 format text file
• FileMaker Go exports text as a UTF-8 format text file.
• FileMaker WebDirect does not support this script step in mobile browsers.

https://fmhelp.filemaker.com/help/16/fmp/en/index.html#page/FMP_Help%2Ftextencode.html%23wwconnect_header

 

[muddylanding]

Thanks Ocean West.

I used the technique suggested by Comment of placing the text in a container and setting the Encoding before exporting the field contents. Works a treat.

I'm still a bit bemused by FM Go and FM Pro using different encodings for the same script element. I have some more reading to do!