HeoX - Cahier des charges fonctionnels

Bon si j'essaie de résumer ce qu'on disait dans le...
... précédent fil pour les fonctionnalités en 2 chapitres:

1Partie Navigation:
Cartographie
Positionnement et tracé de route
Intégration des données météo

2Partie Vie à bord:
Journal de bord
Gestion consommables
Fichier maintenance

Bon je vois que ça pour l'instant... A plus tard ;-) ;-)

Effectivement
Calcul de Marée
+ Intégration des courants

HeoX
l'aspect libre de HeoX me plait bien, ayant déjà ecrit un livre de bord électronique(windows)je suis prêt à fournir gratuitement le module jdb (il est déjà gratuit, dans sa version light)

En attendant la suite
En attendant la suite et comme évoqué dans un autre post, je vous propose de limiter la version "maquette" aux fonctionnalités suivantes :

HeoX 0.01A - version viewer format raster
HeoX 0.01B - version viewer format vectoriel S57

Ces versions devront permettre de lire des cartes nautiques (suivant format) et de les afficher, permettre de les scroller et zoomer.

Déplacement de la carte
Pouvoir avec le curseur, déplacer la carte dans la fenêtre.

(cf Acrobate Reader lorque tu es avec l'icône "main" te permettant de déplacer le document dans la fenêtre).

T.

lecture des cartes
le format S57 est inexploitable tel quel pour de l'affichage. Il faut le transformer dans un format interne pour être en mesure de l'afficher, un format permettant par exemple de récupérer d'un coup, sans avoir à analyser en détail les 10 giga de données, la liste des informations concernant le secteur affiché à l'écran.

Apparemment, mySQL a justement intégré récemment des formats cartographiques, et est apparemment utilisé par au moins un des softs de lecture de carte. Ca me parait une bonne idée :

1)écrire un module qui importe les cartes S57 dans une base mySQL (il tournerait uniquement quand on ajoute de nouvelles cartes/de nouvelles mises à jour)

2)écrire un module qui fait des requêtes sur la base mySQL (en spécifiant la zone concernée et le type d'infos voulues : pas la peine de récupérer les isobathes de précision 10cm si on affiche la carte mondiale) et transforme le résultat en commandes graphiques vectorielles (qu'on peut ensuite traduire trivialement en commandes vectorielles windows ou linux, ou ce que vous voulez).

Une fois définis les types d'infos possibles (la liste est dans la ref S57) et la base mySQL, on peut même écrire séparément et simultanément les 2 modules.

La première étape, pour moi, serait donc de faire une liste exhaustive (et plus simple que celle de la ref officielle) des infos présentes dans le S57, et de définir un schéma des tables SQL dont on aura besoin et de leurs relations.

Pour les autres formats de carte éventuels qu'on serait amené à supporter, il suffira alors d'écrire un nouveau module d'importation dans la base, toute l'appli derrière continuera de tourner sans modif. Le S57 prévoyant d'inclure des données "raster", une carte scannée pourra tout simplement être considérée comme une carte S57 réduite à un seul objet : une image.

J'ai téléchargé la référence S57 et je commence à la lire tranquillement. Il faudrait aussi vérifier si par hasard il n'existe pas déjà quelque part une moulinette d'importation similaire.

il faudrait:
les sources d'un viewer en GPL

autre info brute de fonderie sur GRASS
GRASS

Un logiciel SIG OpenSource, très puissant, mais pas facile dans l'utilisation. Tourne sur Unix, Windows et MacOS X.

très intéressant
GDAL semble contenir pas mal de choses très utiles. Notamment :
*lecture de fichier S57, y compris un ensemble complet de cartes
*écriture/lecture des données vectorielles dans une base de données géographique (en l'occurrence, mysql n'est pas supporté, mais postgresql, si)
*il y a également un viewer de données vectorielles multi-plateformes

Bref, la pluspart des briques dont on a besoin.

plus généralement
l'interface gps , à commencer par le protocole nmea en RS232 n'est pas une mince affaire. C'est mince en nbre de pages de listing mais assez technique , surtout sous windaube: gestion du port RS232 en tâche de fond nécessite une application multithread (ne marche pas toujours suivant la bécane et les nécessités de l'application) ou bien d'implémenter des it en assembleur pour gérer les buffers émission et réception (il existe des bibliothéques pour ça mais elles sont payantes cf "green leaf com"). Le cas échéant, je suis en mesure de fournir des billes la dessus. Sous linux , c'est beaucoup plus sympa, je crois d'ailleurs qu'il existe un projet qui gère l'interface de certains GPS (à vérifier)
de toutes façons, concernant le téléchargement de parcours ou de way point dans un GPS , j'ai peur que l'on ait affaire à des protocoles propriétaires et non documentés (non prévu dans la norme nmea me semble t'il)

Bon , la version 0 de Héox est un simple viewer , me semble-t'il?

négatif
à 9600bps pour pooler efficacement il faut 1000 accès par seconde en VB6 ça marche parfois mais c'est juste