Integration with QtVlm - Data files and Import/Export

[JesperWe]

... continuing from here but with a thread name that you can find

Originally Posted by maitai

It wont be too hard to improve a lot the communication between the 2 platforms. We are OK to try and improve import/export of routes and WPs, copy/paste is a good idea too.

Actually the coolest thing would be copy/paste of both waypoints and routes.

I would think a paste buffer with text/xml Mime type containing a subset of KML would be the way to stay as close to existing standards as possible. It can be as simple as this: (This example works fine with Google Earth)

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
    <name>FooBar</name>
    <Placemark>
        <name>Untitled Path</name>
        <LineString>
            <coordinates>
                -12.43194624370459,51.70088470278394,0 -23.3080798202646,59.5624176344821,0 
            </coordinates>
        </LineString>
    </Placemark>
</Document>
</kml>

I do the OpenCPN part and you do the QtVlm and we get Google Earth interoperability as a bonus!

Originally Posted by maitai

For the grib, that's normal business, we keep integrating new, exotic gribs all the time. Send me a sample and I'll add it.

OK, I will do that.

[JesperWe]

Originally Posted by cagney

ZyGrib, qtVlm and now OpenCPN uses gshhs world map. This means that I have 3 copies, which is quite a waste. Double and triple files like this, will not fly with Debian, and probably not with the other big distros either.
What about agreeing on a default gshhs directory.
/usr/share/gshhs, looks like a decent location. not

I am totally open to this. zyGrib has an old version and a different format so they're out for now. I'm not that familiar with Debian culture and directory allocations but if those of you who are can agree on where they should go we could at least share between QtVlm and OCPN.

[JesperWe]

Originally Posted by cagney

The low resolution version is already available in Ubuntu. Unfortunately it is dependent on gmt (/usr/bin/GMT), for some reason.
So now we know of at least 4 different programs, that uses the gshhs files.
Thomas

OK,I might be a bit out of my depth here, but I think that is maybe the original Gshhs polygons (like Africa = 1 land area polygon) , which is not what we use. We use a world that is cut up into 1° x 1° cells, with individual polygons in each cell.

[cagney]

Originally Posted by JesperWe

OK,I might be a bit out of my depth here, but I think that is maybe the original Gshhs polygons (like Africa = 1 land area polygon) , which is not what we use. We use a world that is cut up into 1° x 1° cells, with individual polygons in each cell.

The higher resolutions seems to be on their way, See Pavels post in the original thread.I'm not suggesting that we should use the low res option. I just pointed out what's available now, and it's dependencies.
Thomas

PS. I have asked HamishB to look at this.

[maitai]

As far as copy/pasting is concerned, one good question is how much information do we want to transfer... a WP belonging to a route has much more than just a name and a position, for instance ETA, distance/hdg to boat and to next POI, wind data from grib at ETA (tws, twd, twa, awa and such), etc... Most of these data is recomputed automatically by the route module anyway so qtVlm won't loose much in case of copy/pasting back and forth, but some are useful flags, for instance "simplifiable", "navigation mode", "type of POI", etc. It also depends on what kind of information you want to display or use in ocpn.

[JesperWe]

I suggest we start simple. After all what we have today is involving lots of manual work, and any improvements will probably be welcome. Trying to specify all the bells and whistles will just get us too many users with different cases who wants to moon and the stars

Initial suggestion for discussion:

We export WPs as <Placemark>, and a <linestring> between them for the benefit of Googöle Earth, but when paste-ing we do not care about the linestring, only create routes between the <Placemark>s.

For extra information that is not part of the KML DTD, we use a sub-format in the description field of paths and WPs, this way your extra information is preserved and can be edited as dumb text in O.
And the whole thing is still parseable as XML. (Google Earth will read that fine but re-export it as a CDATA section. But let's not do that ourselves, this makes parsing easier)

For example:

<description>
<seq-name>001</seq-name>
<simplifiable>true</simplifiable>
<poi-type>foobar</poi-type>
</description>

When copying a route from O, WP names, coordinates and description are exported. <seq-name>:s are added if not already there (Since you need alphabetical order).

When pasting, your routing will have lots of points not in the original route, so it will be imported as a track. This way timing information can be kept, since each WP has a timestamp and a speed. If the user wants to turn that into a navigatable route then he can use the "Route from Track" feature.

In your "Copy", take the settings you do not recalculate (Simplifiable and friends) and put them in the description field of the WP. O Paste function will extract them from the named waypoints in the track, and put them on the named waypoints in the original route. This way next time the Route is copied from O, it will have all setup data, which is useful if weather has changed and we are rerouting.

[maitai]

Ok then. Do we want/need an xsd definition?

It's a bit vacation time here so coding productivity is not at its maximum . I might have some time next week to start something though.

I've added your high-res grib in qtVlm. It contains also waves data which are not recognized (yet) by qtVlm but that doesn't hurt, it's simply ignored. You can test it if you take the last version from repository.

[JesperWe]

Originally Posted by maitai

Ok then. Do we want/need an xsd definition?

I'm not going to do any verification, and Google Earth seems to accept stuff fine without it, so I say no.

[CarCode]

It would be a nicer world if we had Qt of course but now we have wxWidgets (wxW slogan: "Let's program like it's 1999") so let's live with it...

As mentioned by me before Qt has its pros and I hesitaded to second this statement. But after all it will be a lot of work to transfer OCPN to Qt and further more the status of Qt seems to be uncertain. Nokia has once bought Qt from Trolltech and obviously they want to sell it now. Nobody knows if Qt will be LPGL anymore then.

Gerhard

[sinbad7]

maitai..

Seems to have lost your download page. Where do I download the latest patch ....3?

Tore

[maitai]

It's all in the wiki.

The download page is QtVlm Download

If you are on mac/os the compilation is not ready yet, the guy "in charged" is on vacation

[sinbad7]

maitai.. thanks...

Must´ve been sleeping in the class, BUT, how do you avoid the optimized route from touching land?

Tore

[maitai]

If the route has been generated through a routing and coast detection was on, then it's automatic.

Otherwise you have to manually set critical POIs as "not simplifiable"

[JesperWe]

OK, some changes after having done the initial coding and some testing with GE.

Here is a typical paste buffer content from O:

<?xml version="1.0" encoding="UTF-8" ?>
<kml>
  <Document>
    <name>Gotland Runt</name>
    <Placemark>
      <name>Alma</name>
      <description>
        <extradata>
          <sequence>0000</sequence>
        </extradata>
        </description>
      <Point>
        <coordinates>19.1448,59.1529,0. </coordinates>
      </Point>
    </Placemark>
    <Placemark>
      <name>Gotska Sandön</name>
      <description>
        <extradata>
          <sequence>0001</sequence>
          <text>Old freeform description text if any...</text>
        </extradata>
      </description>
      <Point>
        <coordinates>19.6812,57.9781,0. </coordinates>
      </Point>
    </Placemark>
    ....
    <Placemark>
    <name>Path</name>
      <LineString>
        <coordinates>19.1448,59.1529,0. 19.6812,57.9781,0. 19.4064,57.5133,0. 18.8264,57.1395,0. 18.1251,56.8246,0. 17.8923,57.3626,0. 18.2093,57.6399,0. 19.1136,59.1462,0. </coordinates>
      </LineString>
    </Placemark>
  </Document>
</kml>

The <extradata> tag is needed to be able to parse the content of description as XML (must have single root element).

The <Placemark> with <LineString> is only ornamental, the route is fully defined by the <Placemark><Point>'s.

Any other tags you place inside <extradata> will be propagated back to the original route when your routing is pasted, so it will come back round-trip.

/jesper

(Oh, and totally other thing, just so you know, you have a memory leak in your GshhsReader.cpp line 277, GshhsReader::setQuality() )

[maitai]

(Oh, and totally other thing, just so you know, you have a memory leak in your GshhsReader.cpp line 277, GshhsReader::setQuality() )

Thanks It's fixed.