ENC and/or DNC C++ libraries or kernels

[martinb0820]

Does anyone have information about commercial or LGPL (but not GPL) ENC (Electronic Navigational Chart) or DNC (Digital Nautical Chart) C/C++ libraries or kernels that will work with Qt?

Alternatively, I'd welcome any information about an approach to implement this directly.

Thanks,
Martin

[high_flyer]

..C/C++ libraries or kernels that will work with Qt?
Any C/C++ libs you will find will work with Qt.

[martinb0820]

Any C/C++ libs you will find will work with Qt.

That's great news - could you please name some of these compatible ENC/DNC libraries? I'm evaluating whether we need to develop ECDIS capability completely from scratch, and I'm having trouble identifying commercially available ENC/DNC packages.

Thanks,
Martin

[high_flyer]

could you please name some of these compatible ENC/DNC libraries?
I never developed applications in this field, so sorry, I can't do more then google it.
But that is also outside the scope of this forum, which is for helping with Qt programming.
I suggest you look at forums dealing with ENC/DNC issues.

[martinb0820]

I never developed applications in this field, so sorry, I can't do more then google it.
But that is also outside the scope of this forum, which is for helping with Qt programming.
I suggest you look at forums dealing with ENC/DNC issues.

Since the answer was a general one, and not that specifically all ENC/DNC libraries are compatible with Qt, is isn't strictly true that every C/C++ library is compatible with Qt. In the case of graphics (which applies to rendering electronic charts), a binding to Qt is required. If one doesn't exist, it can be created if the C/C++ library is open source; otherwise it may not be possible to create the binding, in which case the library in question would not compatible. For example, Open Inventor/Coin3D have the SoQt class to bind an SoRenderArea to a QWidget or subclass. Without that, maybe OIV could render in its own window, but it wouldn't be integrated into the Qt application.

I'll check the electronic charting forums...

Martin

[squidge]

I've used libraries like this before (not actually ENC/DNC, but libraries which are graphical) and they never attempt to draw things themselves, instead they either give you a pointer to the data and you draw it yourself, or they give you a bitmap which you can display. Either way the library is compatible as Qt doesn't prevent it from working.

If you have a library that directly opens windows and draws on such windows itself, then its not really a library. Libraries should not directly draw on the frame buffer or windows themselves unless that is there primary function (as in Qt).

So for example, Open Inventor/Coin3D could simply render to an in-memory buffer, and you copy/convert this buffer to an appropriate Qt Widget at regular intervals. Theres no need for the library to attempt to this itself - that just makes it less flexible. That way theres no need for a Qt binding and it would be compatible with a large range of GUI tookits.

Rather than being incompatible, I think the correct term would be "Degree of integration".

[martinb0820]

I've used libraries like this before (not actually ENC/DNC, but libraries which are graphical) and they never attempt to draw things themselves, instead they either give you a pointer to the data and you draw it yourself, or they give you a bitmap which you can display. Either way the library is compatible as Qt doesn't prevent it from working.

If you have a library that directly opens windows and draws on such windows itself, then its not really a library. Libraries should not directly draw on the frame buffer or windows themselves unless that is there primary function (as in Qt).

So for example, Open Inventor/Coin3D could simply render to an in-memory buffer, and you copy/convert this buffer to an appropriate Qt Widget at regular intervals. Theres no need for the library to attempt to this itself - that just makes it less flexible. That way theres no need for a Qt binding and it would be compatible with a large range of GUI tookits.

Rather than being incompatible, I think the correct term would be "Degree of integration".

In your OIV/Qt application without a binding (SoQt or Quarter, etc.), how did you handle mouse events, ray selections, etc. that take place in the Open Inventor rendering?

[squidge]

They are handled by the application layer, and the results passed to the library. Like I said, the library typically doesn't get involved in the user interface side of things, it does its job and the main application handles the user interface. This means the application programmer has more work to do, but it's a lot more flexible and means its not restricted to a single, or "only supported" gui frameworks.

[martinb0820]

They are handled by the application layer, and the results passed to the library. Like I said, the library typically doesn't get involved in the user interface side of things, it does its job and the main application handles the user interface. This means the application programmer has more work to do, but it's a lot more flexible and means its not restricted to a single, or "only supported" gui frameworks.

This is the method you used with Open Inventor and Qt?

[squidge]

No, as I've never used Open Inventor, but it is the method I've used with some other graphical libraries. Like I said earlier, I simply stated OI as an example.

[high_flyer]

Since the answer was a general one, and not that specifically all ENC/DNC libraries are compatible with Qt, is isn't strictly true that every C/C++ library is compatible with Qt.

Lets be clear - You can use any C/C++ library which exports its symbols with Qt.
Qt is nothing more then a C++ library by it self.
So in that regard, it is very true to say that Qt is compatible with any other C/C++ lib.

If what you mean is that other libs can't use the signal/slot mechanism that is true.
That however, does not spell no compatibility.
There are ways to solve it, the most obvious one is to create new classes that inherit QObject and the external class.

Of course, if the external lib is doing any sort of graphical rendering, it will stay in its scope, usually though, you can get a pointed to the data, which you can then give Qt to draw, if it is needed.

[martinb0820]

Lets be clear - You can use any C/C++ library which exports its symbols with Qt.
Qt is nothing more then a C++ library by it self.
So in that regard, it is very true to say that Qt is compatible with any other C/C++ lib.

If what you mean is that other libs can't use the signal/slot mechanism that is true.
That however, does not spell no compatibility.
There are ways to solve it, the most obvious one is to create new classes that inherit QObject and the external class.

Of course, if the external lib is doing any sort of graphical rendering, it will stay in its scope, usually though, you can get a pointed to the data, which you can then give Qt to draw, if it is needed.

My original comment wasn't at all about signals/slots; it was about using a binding to render graphics into a QWidget. Of course one could reinvent the wheel and write code to do what the binding does. This could be an interesting exercise, but wouldn't go over well in the kind of commercial environment, with deadlines and cost considerations, in which I work.

Regarding the way to use Open Inventor/Coin3D, in particular the SoQt binding, if there is any interest in this topic perhaps someone who has actually used Open Inventor will weigh in.

[martinb0820]

I accept with information:it does its job and the main application handles the user interface. This means the application programmer has more work to do, but it's a lot more flexible and means its not restricted to a single, or "only supported" gui frameworks.

I've worked with radar displays that do what you describe. When the operator clicks on a point on the screen, the software has to translate screen coordinates into latitude/longitude, which are then used to determine what object is under the mouse pointer. There is no coupling between rendering and the user interface in that architecture.

In my Open Inventor work using SoQt, however, I always let OIV classes handle mouse events and let OIV do the rendering. Below is an example of how easy it is to put an OIV render area inside a Qt widget:



SoQtRenderArea *viewer = new SoQtRenderArea(VisGui::Instance()->visOIVWidget);


In my opinion, there are benefits to this approach too numerous to mention. For example, OIV mouse events give the coordinates of the mouse action in OIV coordinates regardless of how the screen has been resized. :) I still don't understand why so many people have responded that they don't want to leverage this kind of high level capability, so hopefully you can clarify the technical and schedule reasons for me.

I think most employers would not be at all pleased if they found out their S/W engineers weren't using capabilities the company had paid thou$and$ to license OIV or Coin3D in order to obtain.

So, specifically in your own Open Inventor/Coin3D and Qt applications, what were the technical or other considerations that caused you to decide to not use SoQt, but to do all the work yourself? :confused:

It seems worthwhile to recall that this is a Qt forum, Qt is (IMHO) a great product (and now LGPL!) and the topic we're discussing is specifically OIV/Qt/SoQt, not some arbitrary combination of libraries, so I would appreciate it if you can also clear up my confusion about why there's so much concern about wanting to use a non-supported GUI?

Thanks,
Martin

[martinb0820]

I have the answer to my original question. At least one, SevenCs ECDIS Kernel, is compatible with Qt. It hands you bitmaps (unlike OIV) so there is no need for a binding between it and Qt. It handles all the formats I was interested in: S-57 ENC, AML, DNC and more.

[wysota]

At least one, SevenCs ECDIS Kernel, is compatible with Qt.

Every C++ library is compatible with Qt (unless there are some symbol conflicts which is nowadays almost impossible). It might not cooperate with it in any special way but it is compatible. Especially considering the fact that Qt has many other applications than graphics and ui.

[martinb0820]

The SevenCs product is intended to render into a bitmap, so the considerations that were discussed relative in particular to Open Inventor/Coin3D earlier in this thread don't apply, and I fully agree that there are no compatibility issues.

To summarize, earlier in the thread the discussion (d)evolved (?) into how Open Inventor/Coin3D work. I could be wrong, but it seems like the people who participated in the discussion have never used OIV, although they didn't explicitly say that.

As far as I'm concerned (and I'm not telling anyone else what to think or do), if a GUI toolkit forces you to write code to have OIV render into a bitmap a lot of the power of OIV (as well as a lot of the co$t of OIV) is being wasted. In that case, I wouldn't consider the GUI toolkit and OIV to be fully compatible. This is, however a non-issue, since most toolkits one would likely encounter (Qt, FLTK, Win32...) have OIV bindings. (And I would suggest that the existence of these bindings attests to their utility.)

I think it's time to close off this thread! I appreciate the many responses I've received telling me how OIV works, but will continue to use Open Inventor with SoQt even if that's a really bad thing to do... :)

[wysota]

if a GUI toolkit forces you to write code to have OIV render into a bitmap a lot of the power of OIV (as well as a lot of the co$t of OIV) is being wasted.
Thanks God Qt is not one of those toolkits... Are you talking about any toolkit in particular?

[martinb0820]

Thanks God Qt is not one of those toolkits... Are you talking about any toolkit in particular?

As far as I know, Open Inventor/Coin3D are fully supported (i.e. bindings are available) for Qt, Windows, X11, WxWidgets, FLTK and probably others I'm not aware of. I was thinking in the other direction: If one has a powerful tool (OIV) and a powerful GUI toolkit like Qt, why not use their capabilities to the maximum?

[wysota]

If one has a powerful tool (OIV) and a powerful GUI toolkit like Qt, why not use their capabilities to the maximum?

But what prevents you from doing that?

[martinb0820]

But what prevents you from doing that?

Absolutely nothing prevents that. That's been my point all along.