linux and osx routeconverter don't write oziexplorer files

[hvdwolf]

Hi,

The title mentions linux and osx as I can't test the windows version currently.

I tried to convert tracks and routes in kml format to OziExplorer .plt and .rte files. I tried the 1.33 and the latest prereleases but all write 0 byte files when trying to write the mentioned file formats. Other file formats like .gpx and .kml work.

Edit: And the .plt and .rte are not read either. Even more, when in the file dialog window I set the file filter to "OziExplorer (*.plt/.rte/.wpt)" the files are even "greyed out" and can't be selected/opened. When I set the file filter to "all files" I can select them but the format is not recognized upon opening them.

[kumo]

I saved one of my *.itn as *.plt and *.rte with a windows pre-release.
Both were saved as WGS 84 formatted files.

Correct track (*.plt) and route (*.rte) were shown at the map when re-loading this files.

What about the linux and osx versions? Do they use a built-in GPSBabel?

Best regards,
Mathew

[hvdwolf]

What about the linux and osx versions? Do they use a built-in GPSBabel?

Best regards,
Mathew

They both have a builtin gpsbabel. I did a jar-xf for both jars and gpsbabel is in there.

Macosx: The macosx gpsbabel is located in "mac_os_x/x86/gpsbabel". The gpsbabel version is a Universal (i386/ppc) static compiled version and works as such after having set the execute bit. It does not work from inside routeConverter though. Maybe it is just as simple as setting the execute byte for gpsbabel inside the svn trunk.

I do not know how RouteConverter currently calls gpsbabel but if necessary this call could be changed for OSX. If we succeed in creating a working OSX bundle (see here) we could also package the gpsbabel binary inside the bundle separated from the jar. I will have a look at that.


linux: The linux version is a dynamically compiled version. A linux binary is always dependent on the Linux distribution and the version of that distribution. It means that packing "a" linux gpsbabel into the linux jar is not usefull. It might be better to note on the download page (and in the FAQs?) that linux users should download the gpsbabel binary via the package manager for their distribution (synaptic/apt-get for Ubuntu, yam for Suse, etc. etc.).
I do not know for which linux version this gpsbabel was originally compiled, but it was compiled against a very old expat library which makes me think that the gpsbabel binary itself is very old as well. As it didn't run I couldn't do a version check.

work around: I used both the extracted gpsbabel binary from Routeconverter and also downloaded the gpsbabel binary for OSX from gpsbabel.org. I tried with both (external gpsbabel from Extra) and it worked. I also installed the gpsbabel version for my linux version via the package manager belonging to my linux distribution/version. In both RouteConverters I set the path to the external gpsbabel binaries and now the conversion from/to the OziExplorer formats work.

@Christian: If you want to add this to the FAQs and you need some more info for the OSX or Linux way of working: just let me know and I write the neccessary info.

[kumo]

I had a similar effect in the past:

I specified a path to an external GPSBabel (never mind, why).

RouteConverter versions and the built-in GPSBabel changed over time, but my external version not (grin).

And one day I tried a conversion which needed the up-to-date version...

[hvdwolf]

linux: The linux version is a dynamically compiled version. A linux binary is always dependent on the Linux distribution and the version of that distribution.

This is not 100% correct. Al linuxes and their binaries/libraries are dynamically compiled. If you would compile the gpsbabel binary as a 100% (32bit) static binary it should work on every linux.

[routeconverter]

The title mentions linux and osx as I can't test the windows version currently.

On Windows, this works - at least the test suites are green. But I cannot test Mac OS X and I'm currently not testing on Linux.

I tried to convert tracks and routes in kml format to OziExplorer .plt and .rte files. I tried the 1.33 and the latest prereleases but all write 0 byte files when trying to write the mentioned file formats. Other file formats like .gpx and .kml work.

The OziExplorer formats are gpsbabel-based - I guess, it's not working on your platform.

[routeconverter]

Macosx: The macosx gpsbabel is located in "mac_os_x/x86/gpsbabel". The gpsbabel version is a Universal (i386/ppc) static compiled version and works as such after having set the execute bit. It does not work from inside routeConverter though. Maybe it is just as simple as setting the execute byte for gpsbabel inside the svn trunk.

I do set the execute bit. See BabelFormat:

private String considerShellScriptForBabel(String babel, String command) throws IOException {
if (Platform.isLinux() || Platform.isMac()) {
File shellScript = createShellScript(babel, command);
command = "/bin/sh " + shellScript.getAbsolutePath();
}
return command;
}

private File createShellScript(String babelPath, String command) throws IOException {
File temp = File.createTempFile("gpsbabel", ".sh");
temp.deleteOnExit();
BufferedWriter writer = new BufferedWriter(new FileWriter(temp));
writer.write("#!/bin/sh");
writer.newLine();
writer.write("`which chmod` a+x \"" + babelPath + "\"");
writer.newLine();
writer.write(command);
writer.newLine();
writer.flush();
writer.close();
return temp;
}

linux: The linux version is a dynamically compiled version. A linux binary is always dependent on the Linux distribution and the version of that distribution. It means that packing "a" linux gpsbabel into the linux jar is not usefull. It might be better to note on the download page (and in the FAQs?) that linux users should download the gpsbabel binary via the package manager for their distribution (synaptic/apt-get for Ubuntu, yam for Suse, etc. etc.).

To accomplish this, there is a lookup mechanism, that prefers a locally installed gpsbabel before calling the internal one.

I do not know for which linux version this gpsbabel was originally compiled, but it was compiled against a very old expat library which makes me think that the gpsbabel binary itself is very old as well. As it didn't run I couldn't do a version check.

I think I compiled it against Ubuntu 8.04, but I'm not sure.

@Christian: If you want to add this to the FAQs and you need some more info for the OSX or Linux way of working: just let me know and I write the neccessary info.

I'm somehow lost in this thread - what's the problem/question and what is the answer? Is this an FAQ or a problem I can fix in the code?

[hvdwolf]

To accomplish this, there is a lookup mechanism, that prefers a locally installed gpsbabel before calling the internal one.

I removed the setting for the external gpsbabel from RouteConverter, without removing gpsbabel from my linux system and it now works correct, so the mechanism works. That's nice.

I'm somehow lost in this thread - what's the problem/question and what is the answer? Is this an FAQ or a problem I can fix in the code?

The only point is that the built-in gpsbabel currently doesn't work. As long as it doesn't work I think a notification in the FAQs or on the download page would be welcome to new users to tell them to download/install gpsbabel.

[routeconverter]

The only point is that the built-in gpsbabel currently doesn't work.

Since it's 32 bit on Mac OS X and since it's too old on Linux?

As long as it doesn't work I think a notification in the FAQs or on the download page would be welcome to new users to tell them to download/install gpsbabel.

Did it: http://www.routeconverter.de/faqs/gpsbabel/en

[hvdwolf]

The only point is that the built-in gpsbabel currently doesn't work.

Since it's 32 bit on Mac OS X and since it's too old on Linux?

The packed gpsbabel inside the macosx jar as such is fine. When I extracted it (via jar -xf ..) and set the execute bit correctly, it worked fine when specifying it as an external gpsbabel. Please note that this universal 32bit gpsbabel will run on any macosx even if the macosx is 64bit. It will simply run the 32bit version against a separate 32bit kernel extension in a separate 32bit memory space. It functions diffferently for C-programs as for java jars/classes.

The linux version should be 100% statically compiled. A dynamically linked version will most certainly fail as soon as it is run on another version as the distribution version it was compiled on.
It will definitely fail on another distribution no matter the version.
As mentioned: A completely statically built version might run on all linux versions as long as the kernel (file and memory) calls haven't changed too much, but I wouldn't worry about that. I will see if I can compile such a statically linked version.

As long as it doesn't work I think a notification in the FAQs or on the download page would be welcome to new users to tell them to download/install gpsbabel.

Did it: http://www.routeconverter.de/faqs/gpsbabel/en

Nice, but for OSX it is not correct (Sorry, OSX differs on this point).
When using "linux ported" binaries you do that either from MacPorts or from Fink or you download the source and compile it yourself in which case it is installed in /usr/local/bin (default prefix). In case you use MacPorts, binaries are installed in /opt/local/bin. In case you use Fink, binaries are installed in /sw/bin.
Note that both MacPorts and Fink will set the binary paths in the PATH environment upon installation.
Linux might differ as well. Some distributions install "foreign" programs in /usr/local/bin. If you compile yourself it will definitely be installed in /usr/local/bin.
(That's why I mentioned some posts ago: "If you need info please let me know..")

To my humble opinion, the most "fail safe" way for linux would be (I think):
- the binary defined within the options dialog
- try to find the binary via the PATH, so without a path specified (/usr/bin, /usr/sbin, /usr/local/bin are always in the PATH statement)
- run the internal gpsbabel

The most "fail safe" way for macosx would be (I think):
- the binary defined within the options dialog
- try to find the binary via the PATH, so without a path specified (/usr/bin, /usr/sbin, /opt/local/bin, /sw/bin are always in the PATH statement. /usr/local/bin should be in the PATH.)
- run the internal gpsbabel

This would be a more "universal" approach for all possible configurations on osx and linux.
Off course, you could make it even more "fail safe" by testing all the mentioned paths after the "- try to find the binary via the PATH ..", but that would be more work on your side trying to compensate for users who messed up their environment (don't touch it if you don't know what you do).