Charts

[Psyches]

Originally Posted by ActiveCaptain

I don't have time to do the OpenCPN coding but I certainly can help assist an effort to integrate to our data. And get me involved in whatever hosting issues you might have also. Perhaps I can help with that too.

Hi Jeff, we've exchanged emails before. Does this mean you could make the ActiveCaptain "branded" marine POI database available to the OpenCPN project? I think that'd be really cool. I'm interested to see what others think about this too, including (especially) Dave.

OpenCPN seems to be making great progress, although we don't seem to have a lot of excess coding capacity either...

Mark

[idpnd]

Originally Posted by ActiveCaptain

I don't have time to do the OpenCPN coding but I certainly can help assist an effort to integrate to our data. And get me involved in whatever hosting issues you might have also. Perhaps I can help with that too.

There are quite a number of user-contributable (and non-contributable) cruising guides out there, some of which are already accessible via google earth. Perhaps the best point of integration would be the proposed KML/KMZ overlay on Opencpn. The cruising guides providers' databases would then have to be downloadable in "by region" packs.

The feature would add value to both sides; some of the more cutting edge C-maps include harbour photos, etc, whilst the idea of online cruising guidebooks is still semi-flawed for quick lookups (though excellent for planning).

[ActiveCaptain]

Yes, ActiveCaptain "branded" data could be included in OpenCPN. We're talking about a lot of data - many megabytes - and data that changes and evolves every day. And yes, there's got to be limited coding bandwidth to add anything. But our back-end is very flexible to providing any type of output needed. There are models we can use - panoramio for example - that could share a similar code base.

What I'd propose is a discussion to come up with what is needed. In the meantime, let the boat show">Miami Boat Show happen (mid-February) so I can show other things like this being implemented. That might make everything clearer by seeing what is possible.

I'd need to understand more about the KML ideas. Upfront, I don't like the idea. We probably have some sticky issues to deal with and we certainly need more than a flat file database to implement all of the data, reviews, and updates. Plus, synchronization should be a requirement of data like this that changes so frequently. You don't want cellular-connected boats to have to download huge updates weekly or monthly. They should be quick and easy to receive and update. Our server is built to handle synchronization - even if the synchronization fails part-way through. I also have a requirement that implementation would require the user to be able to create updates and reviews to add back upstream. The key with ActiveCaptain is getting the community to update the data as they experience it. That's a two-way street. The zen of it means that using it gives the user the responsibility of updating it too. Anything else gives bad sailing karma!

[idpnd]

So delayed synchronisation of user uploads would have to be necessary as well..

I would expect the licensing for user-contributed content to be public property/creative commons sharealike naturally (in keeping with the spirit of opencpn, and to ensure future availability as well); both the cruiserlog sailing wiki and sites like wikitravel or the German skipperguide use free documentation licenses.

[ActiveCaptain]

Originally Posted by idpnd

So delayed synchronisation of user uploads would have to be necessary as well..

I would expect the licensing for user-contributed content to be public property/creative commons sharealike naturally (in keeping with the spirit of opencpn, and to ensure future availability as well)

Delayed user-content synchronization becomes pretty simple with a real database. Yes, that would be required.

Licensing is an issue and there will be sticky points to it. Trust me, there's more factors at work here than you realize. We get threatened monthly with lawsuits by marinas. Panoramio seems to be a good model since they face many of the same issues in a more general way.

[idpnd]

The concept sounds exciting, I hope the lead developer(s) feel(s) so as well

This sort of innovative "layer" (thinking google earth here) could really give openCPN the competitive edge in what is otherwise a fairly inert setting..

[Leo12305]

Hi friends
I hope for a happy New Year. The German Skipper Guide your can use direktly in OpenSeaMap Chart. Select a harbour or marina sign and then klick the left mouse key.

leo

[idpnd]

Happy NY to you too..

What's the relationship between Freie Tonne and OpenSeaMap?

[Psyches]

ActiveCaptain, idpnd, good discussion, I look forward to more and others joining in.

idpnd, I'm still very positive about the kml/kmz idea but I suggest that POI integration wouldn't be any more a part of it than grib display will be. They will all need to work together, but should be separate, because they can be. Also, for the foreseeable future OpenCPN will need to support the older chart formats, or else support fast conversion from them...conversions will require more dev, perhaps a lot more; and we wouldn't want to say "convert your charts, or sorry no POI". The good news is POI isn't much more than waypoint support, although with fancier and more input, pictures, etc...unless I'm missing something.

ActiveCaptain, yes the reason I mentioned in the first place is to discuss licensing and closely related issues. I don't see data size as a big issue; most small laptops can hold the entire NOAA chart suite, so aside from lots of video or picture data, I expect the "guidebook" data shouldn't be a big problem. As mentioned, a good sync strategy will be important. I've done this before, it's quite doable but in this context, very leading-edge. And making useful "crowd-sourced" marine data available intrinsically sounds great.

As for the datastore itself, sure it could be one of the open SQL engines or a non-SQL store. I've used many, so this also doesn't concern me much. Setting up the licensing and good interfaces definitely concerns me, as does the actual development time needed for any solution at all.

Also, much of the OpenCPN community is not in the US, so I hope ActiveCaptain is growing its user-base internationally.

Mark

[sinbad7]

Interesting news from the Norwegian Coast Guard which has adapted OpenSeaMap.

The Norwegian Coast Guard is now offering a free charting service for Norway.
The new development is that they are using OpenSeaMap as a base,with choice of up to date ECDIS compatible nautical charts for the entire coast of Norway. Presently only available via internet.

All the nautical charts are collected directly from 'Sjøkartverket' ,the coast guard's charting service. The maps are collected as WMS (Web Map Service) Each time the user pans or zooms the chart,a call is made to the Sjøkartverkets WMS server,making sure you reveive the very latest chart information. If OpenCPN could be made WMS compatible, it would in theory be possible to collect the charting data direct from Sjøkartverket.

About the WMS service:

Perhaps a similar model could be adapted for use with other free charting services such as USA and Brazil.

As the data is presently only available over the internet,I suggested that perhaps arrangements could be made to download particular chart areas prior to each planned trip which could later be updated or deleted as required. This would avoid having to download the entire and huge database.

I have suggested that we could all benefit from a discussion to find a solution to offer a total FREE navigation package to the boating fraternity.

[scotte]

The problem with the ActiveCaptain data is that it is not open and not published/available freely under an open license, so it would taint OpenCPN unless it's only one possible datasource in an otherwise open system, with other sources as well.

[Psyches]

Originally Posted by scotte

The problem with the ActiveCaptain data is that it is not open and not published/available freely under an open license, so it would taint OpenCPN unless it's only one possible datasource in an otherwise open system, with other sources as well.

Good point - I completely agree. It might be the first such source, but should not be built to be the only, otherwise it really violates the spirit of OpenCPN.

Mark

[ActiveCaptain]

Originally Posted by scotte

The problem with the ActiveCaptain data is that it is not open and not published/available freely under an open license, so it would taint OpenCPN unless it's only one possible datasource in an otherwise open system, with other sources as well.

It would be completely unexpected for it to be the only data source. I'm just biased that it will be the best.

We evaluated all of the totally open POI attempts made for boating as well as other segments before we started with ActiveCaptain. We found that they all fail for similar reasons. It requires a huge amount of back-end work to validate the facts of the POI markers - that was just never done with any of the open license attempts. I guarantee that you'd be shocked to know how much time it takes.

I liken our data source to the way that panoramio is used by developers. There's no questions that Google owns the pictures but they make it quite easily available for inclusion into other sites and applications. It doesn't de-value the applications that use it. Instead it gives them additional overlays and capabilities to make the user's experience better.

In the meantime, I really wish that OpenCPN had a quilted type of chart display. Chart-by-chart navigation is really behind-the-times. If that isn't possible, consideration for a "slippy map" type of display should be made - see our X beta tab to see how we did our first cut at it - select NOAA Charts as the map type. Displaying POI's over clipped chart edges doesn't provide the best type of experience.

[bdbcat]

Jeff, Mark, et al...

I guess I'll weigh in on this...

First off, I like the idea of integrated user experiences, with seamless hooks between multiple data source, all providing enhanced functionality in an intuitive and natural way. Information-rich offline POI browsing is just one application.

However, I don't especially like the notion of embedding specific proprietary third party data type support in the main trunk of opencpn. The third party data types we support now are all open, (or de facto open, in the case of BSB).

Which is not to say that a branch of opencpn couldn't fork off to incorporate any private data types desired by the new implementors, subject of course to the requirements of OSF. Specifically, this means that any enhancements of this sort made to opencpn must themselves be open sourced, and released in source code form to the universe. This will no doubt be a deal-breaker for many data sources....

So, lets think about this. We currently (thanks to Thomas Haller) support GPX waypoint and POI import with embeddable html links. So, we could today do something useful with minimal impact on opencpn:
1. Get ActiveCaptain POI database as GPX files(s) with embedded hyperlinks. These links would point to documents which are read by....
2. Create (in Java, probably) a browser interface to the data. This would support ActiveCaptain private data types, user input, database re-sync, etc. It would run locally if offline, and access the online AC data if available. To the user, this looks like a natural "pop-up" extension to opencpn.

This could work. It would not be a small job to create a fully featured AC data local interface, however. This coding activity is not really an opencpn effort, in my view.....

A final philosophical note:
My vision for opencpn is to be "excellent, best-in-class", not "popular and widely used". Those goals are not automatically the same. As one who has made a good living developing, selling and supporting software solutions, this new vision requires a real change-of-gears in the mindset. Open source software development is a sea-change, all right.....


Comments welcome, as always
Dave

[Psyches]

Thanks Dave. All makes complete sense to me. This was an area I was thinking of when I mentioned an OpenCPN ecosystem a few weeks ago. I was imagining your #2 scenario, where OpenCPN supports one or more types of extension. The idea probably has occurred to you and many others here - it first occurred me when Thomas (cagney) wrote his ruby support for building ships weather observations import (my post: http://www.cruisersforum.com/forums/...tml#post361586).

There are many such extensions that would be nice to support, and I think a best-of-breed open chart application would enable such extensions in an uncumbersome way.

The only true OpenCPN code-base support needed would be the ability to support extensions/plug-ins. Possibly some of the waypoint code could be reused, obviously not if the work was done in java or other environment. And yeah, the AC integration is doable and would be very nice, but not a really small job, no matter how it's sliced.

Mark