Quelle méthode ?

Je viens de relire les fils de mai 2005 sur Heox. J'ai trouvé extrêmement intéressant et productif le fil sur le logo. Par contre les fils techniques semblent s'être enlisés. Mon diagnostic, et c'est pas la première fois que je vois ça : un logiciel doit être conçu par ses utilisateurs, non par ses développeurs.

Je m'explique : le fil "cahier des charges fonctionnel" a très vite dérivé vers une discussion de spécialistes sur leurs outils et méthodes, et chacun a évidemment sa préférence, comme les archis navals ont leurs outils logiciels, et, c'est bien connu, le meilleur est celui dont on a l'habitude de se servir. Je ne déroge pas à la règle lorsque je vous fais des démos de ce qu'on peut faire avec "java" :)

D'autre part les informaticiens ont trop tendance, dans les discussions, à explorer jusqu'au fond des choses les différentes branches de l'arbre des choix techniques possibles. Par exemple, dans le fil "technique", on discutait des difficultés d'interfaçage entre une appli informatique et un gps. Perte d'énergie à ce stade : on sait que c'est possible, et on délèguera à un moustachu la réalisation de la chose, sans embêter tout le monde avec des problèmes "d'it" ou autres liés à la programmation temps réel.

Au contraire, le fil "logo" était déconnecté des outils utilisés, mais chacun a mis son grain de sel sur le look, et finalement on a trouvé des trucs sympas et pourquoi pas une solution définitive.

Alors je me permets de proposer une méthode pour avancer. Je l'ai pratiquée depuis de nombreuses années et j'ai constaté qu'elle est efficace. C'est très simple. Pour faire une application informatique, on commence par faire son manuel d'utilisation. Comme le manuel d'utilisation, aujourd'hui est destiné à être lu sur un écran, et pourquoi pas consulté en ligne sur internet, on fait un site internet qui explique aux utilisateurs comment utiliser le logiciel.

Je vois déjà des sourcils se lever, comme si on voyait un bateau se présenter sur la ligne de départ d'une régate le cul en avant... Alors permettez moi de m'expliquer.

Le manuel d'une application informatique décrit, si possible d'une manière exhaustive et claire, toutes les fonctionnalités du logiciel. Une fonctionnalité existante dans le manuel et non réalisée dans le logiciel amènera les utilisateurs, fort logiquement, à pousser des cris et à réclamer avec insistance et urgence la mise à disposition de la fonction correspondante. A l'inverse, une fonction disponible dans le logiciel et non documentée les amènera à pousser des hurlements contre le malheureux rédacteur du manuel.

Mais comment peut on faire un manuel si on n'a pas le logiciel en main. Eh bien c'est là, justement, qu'il faut faire preuve d'un peu d'imagination. Aujourd'hui tout le monde, je veux dire tous ceux qui sont capables de se promener sur un site comme HEO, utilise des logiciels. Il y a évidemment des invariants : des menus déroulants, des menus contextuels, des fenêtre de dialogue popup, des boutons, des cases à remplir, à cocher, des boutons radio, des curseurs de potentiomètres, des fenêtres uniques ou multiples, des onglets, etc... Et ce ne sont pas les exemples qui manquent, comme par exemple Google Earth...

Le manuel, s'il est bien fait, vous montre les différents éléments de l'interface utilisateur tels qu'ils sont (souvent ce sont des copies d'écran du logiciel) et vous les commente. Eh bien il suffit d'inverser la procédure : on dessine les écrans, peut importe avec quoi, y compris avec la boite de crayons de couleur et un bout de papier (et un scanner pour montrer aux copains), et on décrit par du texte la fonction qui est réalisée.

Une fois le manuel complet, et il peut faire cent pages sur papier, et seulement une fois que tout le monde est d'accord sur le contenu, on appelle les informaticiens. Forcément ils vont avoir des remarques à faire, proposer des simplifications, voire dire que telle ou telle fonction est impossible (en général ils ont tort sur ce point). Et à partir de là, il faut en trouver un ou deux, moustachus de préférence, qui vont structurer l'appli informatique (on appelle ça faire de l'analyse organique), décomposer le boulot, et lancer la réalisation. Evidemment, à ce stade, il faut faire le choix d'outils (langage, structure des données, utilisation d'une base de données, standards, formats, etc...), le choix étant souvent plus guidé par des contraintes de disponibilité des ressources humaines que par des critères de performances.

Après, les choses sont en général sur des rails et ne peuvent pas dévier, parce que justement le manuel d'utilisation est là. Il est interdit à un informaticien de rajouter une fonction qui ne serait pas approuvé par les utilisateurs et mise dans le manuel auparavant. Il est obligatoire que, sauf en cas d'impossibilité technique constatée collégialement par les spécialistes, on respecte les désirs des utilisateurs.

Voyant la créativité au niveau textes et graphismes sur ce forum, je ne doute pas que le manuel de HEOX ne puisse voir le jour très rapidement. Et d'expérience, je sais que les informaticiens peuvent aller vite en développement s'ils savent exactement ce qu'ils doivent faire.

Qu'en pensez vous ? Quelle procédure peuvent nous proposer les gestionnaires du serveur HEO pour faire en travail collaboratif un site web (une branche du site HEO) qui constituerait le manuel de l'application HEOX ?

Des volontaires pour proposer les premiers roughs d'écrans ? Vous avez en tête la métaphore du siècle en plaçant l'utilisateur dans le Nautilus du capitaine Nemo ? Dans un vaisseau du 17eme siècle ? Dans une navette spatiale en perdition ? En vision stéréoscopique illustrant la dualité ange-démon sur fond de paradis et d'enfer... Allez, les mordus de Photoshop et d'Illustrator, lachez vous...

L'équipage
17 fév. 2006
17 fév. 2006
0

Ben.... Pas moi !
Non pas que je sois contre... bien au contraire !
Mais je viens de fermer ma boite (d'informatique) et que je n'ai pas envie pour l'instant de faire ce que je faisais hier. Mais, malheureusement, il faudrait le faire comme tu le dis...

17 fév. 2006
0

Par contre, entre fada
Moi aussi je cherche le bâto du phadha...
mé ca cé 1 ôtre phil (ki raisthe a fer)

18 fév. 2006
0

Analyse pertinente !
A laquelle je souscris;-)

Je passe une partie de mon temps à écrire du code pour piloter des instruments, et, en effet, je commence toujours par dessiner l'interface avec l'utilisateur ce qui n'est qu'une façon d'écrire le manuel et les fonctions.

Pour le logiciel dont on parle ici, les fonctions sont bien connues et il n'y a rien à inventer, seulement à choisir lesquelles on réalise en premier.

18 fév. 2006
0

C'est bien rigolo tout ça.
un poil à côté et enfantin quand même. Je cite :
"Le manuel d'une application informatique décrit, si possible d'une manière exhaustive et claire, toutes les fonctionnalités du logiciel."
Et qui a définit les fonctionalités:
- ça peut être l'étude préalable de besoin faite avec l'utilisateur, un cahier des charges fonctionnel rédigé lui aussi en colaboration entre les users et les techniciens;...

Si je ne m'abuse, c'en était à peu près à ce stade lorsque ,et tu as tout a fait raison sur ce point, des users aussi techniciens se sont noyés (c'est malheureusement habituel chez les français habitués à la bite et au couteau) dans des considérations d'un autre âge (dans le développement du projet, s'entend) et confondu leurs différents rôles.
J'avais lancé un fil sur les interfaces qui était justement ce mot d'alerte : les orientations doivent être prises au départ par les utilisateurs qui, selon qu'ils voudront un super bidule dirigiste ou un gentil machin intuitif détermineront par la même les fonctionnalités essentielles.
Quant à rédiger un guide utilisateur, je l'ai toujours fait rédiger PAR les utilisateurs LORS des phases de recettes, parce que ce doit être un document de référence et pour tel, il doit être exact , exhaustif (description et utilisation des interfaces, fonctionnalités et objectifs de chaque procédure) et qu'il n'est pas possible, lors de la phase préalable (celle où je pense en est resté ce projet, de connaître les dialogues dans le détail puisque les fonctionnalités ne sont pas recensées exhaustivemnt,....... blablabla, la poule et l'oeuf.

18 fév. 2006
0

la question est aussi vieille que l'OST
comprendre l'Organisation Scientifique du Travail. Il y a des lustres que ceux qui savent ou qui croient savoir s'imaginent qu'ils sont les seuls à savoir comment il faut faire.

Depuis plus de 30 ans circule dans tous les services informatiques la fameuse BD de la balançoire qui tient sur une seule page en une dizaine d'images et qui se termine par celle représentnant "ce que voulaient les utilisateurs".

Depuis que je suis venu à linux, je m'aperçois que si le noyau, (déjà là on devrait dire LES noyaux) est modelable comme on le souhaite et qu'on peut le débarasser de toutes les protubérances inutiles qui encombrent Windaube, les applis pêchent toutes à côté des applis windows ou mac.

Dès que l'on sort des applis classiques de bureautique, déjà au niveau des drivers d'imprimante, de sono, de modem, de routeurs, de scan etc... c'est le parcours du combattant. On passe plus de temps à se regarder pédaler qu'à pédaler.

Alors certes c'est libre, et je comprends que les développeurs patentés soient intéressés, mais la grande majorité des simples utilisateurs n'y vont que parce que c'est gratos assez souvent.

De grace, entre une suite comme celle d'Adobe avec illustrator, photoshop, in design, adope première, effects où tout fonctionne parfaitement sous mac ou windaube, avec une unité de conception et inskape et gimp pour ne prendre que ces 2 là, où les courbes de bézier et le reste ne sont pas traitées de la même façon... parce que développées par des groupes différents sans compter les blocages parce que toutes les dépendances ne sont pas présentes, je garde linux pour m'amuser un peu mais je travaille sous mac pour le graphisme.

J'ai pas de temps à perdre à toujours être obligé de lever le capot dès que çà bloque.

J'ai parcouru aussi le cheminement HOEX et j'ai bien rigolé. Bon courage les gars. On peut toujours refaire la roue....pour le plaisir de la voir tourner. Il y a déjà du temps que d'autres y sont arrivé et bien.

Alors Sailsoft, ta méthode, je l'ai mise en oeuvre avec "merise" il y a 20 ans. çà marche effectivement, mais la question première avant même de se mettre à l'oeuvre n'est-elle pas : pour qui, pour quoi, comment et que va-t-on faire de plus que ce qui existe déjà.

18 fév. 2006
0

Pas d'accord
Je te cite : "Dès que l'on sort des applis classiques de bureautique, déjà au niveau des drivers d'imprimante, de sono, de modem, de routeurs, de scan etc... c'est le parcours du combattant. On passe plus de temps à se regarder pédaler qu'à pédaler".

On lève moins souvent le capot avec Linux,ce n'est pas nécessaire si on utilise le système dans les mêmes limites que celui, quasi monopolistique, d'une société bien connue. La différence, c'est que ça fonctionne, donc il n'y a pas besoin de lever le capot.
Rigolo de constater par ailleurs la quantité d'applications portées depuis Linux sur les systèmes officiellement payants : PHPmyadmin, Apache, OpenOffice, Gimp, pour n'en citer que quelques un. Qui tournent par ailleurs indubitablement mieux sur leur système d'origine.

Ce qui fait que certains s'y perdent, c'est qu'ici, il est permis, non-obligatoire, mais permis, de soulever le capot. Et, là comme ailleurs, il est préférable pour la suite des évènements de savoir ce que l'on fait. Promis, je ne démonterai jamais, quoique, une moissoneuse-batteuse.

18 fév. 2006
0

Ben non.................Ben oui.............
" un logiciel doit être conçu par ses utilisateurs, non par ses développeurs."

Dans le vrai monde, je veux dire celui qui est censé faire vivre les gens de la sueur de leur front (chaud ou froid selon les saisons) , si on demande ça aux Zutilisateurs, on va droit dans le mur. Because, les Zutilisateurs, c'est le café du commerce..Blabla sympa mais sortie de conversation = .....
Les développeurs : ben surtout ne pas leur demander leur avis. Dans le vrai monde, on ne les paie pas pour ça mais pour qu'ils pondent du code sans bugs (un truc que Bill G. n'a jamais réussi à faire :))
Il n'y a qu'une solution : trouver des mecs tellement forts qu'ils vont anticiper les attentes des Zutilisateurs que comme ça ils trouveront tout bien et que les développeurs ne trouveront rien d'impossible à faire.

dingue non....

PS : normalement quand je suis dans la vraie vie, je rédige sans fôte d'ortographe des contrats pour des logiciels à 2 ou 3 M de roros en tant que "responsable commercial " (lol) d'une boite de soft.

PS (2) : I am waiting for the bullets but I am bidonning a lot for ce qui va suivre

18 fév. 2006
0

Je veux bien faire un truc
Mais uniquement les jours de pluie, quand je ne peux pas bosser sur autre chose.
J'ai lu attentivement ton post, Sailsoft, et je pense que tu as raison.
A une lointaine époque, j'ai fait du développement (systèmes de contrôle électronique de documents, entre autres, pour ceux qui connaissent) pour une multinationale d'origine japonaise.
Moi, ma démarche était un peu différente mais je pense qu'elle rejoignait la tienne.
La mienne consistait à demander aux utilisateurs ce qu'ils attendaient d'un soft ou d'une base données, à le mettre sur papier, et à sortir le plus rapidement possible une "maquette" à massacrer par les susdits utilisateurs, afin de confronter leurs demandes avec une utilisation réelle, et modifier le bastringue en fonction.
Si quelqu'un peut me résumer les fonctionnalités attendues et qu'on puisse discuter le coup (priorités,...), je veux bien tenter de dessiner des écrans. Pour le reste, ce que j'ai encore comme connaissances est sans doute trop spécifique d'une part, et trop néenderthalien d'autre part...

18 fév. 2006
0

pas pour la polémique Bernard
mais si tu peux m'expliquer comment dès le chargement terminé on fait tourner une simple canon i560 qui n'est pas un perdreau de l'année sur une debian tu m'intéresses. Comment tu fais tourner skype sur la même distribution, même remarque. Naturellement tout çà sans lever le capot.

18 fév. 2006
0

c'est rigolo ...
5 posts plus tard c'est reparti dans les querelles de clochers par les spécialistes :-D

Voyons, voyons, ça fait longtemps qu'il n'y a plus grand chose de neuf à inventer comme concepts pour un logiciel de navigation basique pour la plaisance.

A ma connaissance (mais je peux me tromper !) , le seul outil qui n'existe pas en logiciel à acheter pas cher, c'est celui qui permettrait de se fabriquer des cartes vectorielles soi-même au format standard S57 à partir des cartes papier.

Tout le reste (nav basique à partir de cartes raster ou vectorielles, fabrication de cartes raster à partir des cartes papier) se trouve à plus ou moins 100 euros, voire gratuit pour les fonctions basiques.

Cela marque fortement les limites dans lesquelles on peut se mouvoir pour inventer du neuf.

18 fév. 2006
0

çà existe Robert
du moins dans le principe, mais c'est encore trop simpliste. J'ai essayé avec streamline. On m'a dit que les linuxiens avaient quekchose d'équivalent. Le problème c'est que çà transforme toutes les courbes en une multitude de segments droits.

Une courbe n'est jamais que la juxtaposition de segments. Seulement voila, quand ils se multiplient çà devient ingérable, il faut repasser derrière à la mimine et çà prend plus de temps que de décalquer directement avec un logiciel comme illustrator.

Alors, çà va bien pour un chti bout de carte, mais pas pour une collection, sauf à changer de hobby.

:aurevoirdame:

Un certain nombre de marqueteurs de mes amis ont tenté l'aventure, car le dessin initial est la première difficulté dans notre activité. Ils en sont revenu. Tu prends un tableau de maître, streamline et hop soit c'est trop simpliste, soit c'est un fouilli de points d'inflexion et de toute façon, des lignes brisées.

Il y a effectivement une niche de ce côté là mais il faudra aussi en parler au père Copyright.

19 fév. 2006
0

Uninx linux
c'est tres bien,

mais combien de personnes savent ce qu'est VI

car il ne faut pas se leurrer, mettre en place linux n'est pas aussi simple que cela (pour un néophite,héophite) .
parler de noyaux c'est déja passer au dessus de sa connaissance (mis à part ceux de pêche ou autre)

la cartographie numérique, c'est trés bien mais elle ne sait pas gerer l'oeil de l'humain qui à une culture papier

ce que veut un utilisateur, c'est un micro qui ne tombe jamais en panne (soft) et qui réponde à ses exigences à lui.

19 fév. 2006
0

Faux
Pas besoin de savoir ce qu'est Vi. Mettre Linux en place est très simple, en tout cas à partir du moment où on le fait sur base d'une distribution de type RPM. Dans ce cas, pas besoin de parler de noyau ou quoi que ce soit.
C'est même beaucoup plus simple que chez le célèbre concurrent : pour installer un PC et ses périphériques sous Linux, il suffit, pour avoir un système prêt à l'emploi : de connecter et d'alllumer toute la quincaillerie (imprimantes, webcam et toutes les cochonneries qui se connectent), et de donner les CD ou DVD à manger à la machine. Une demi-heure plus tard, vous avez une machine prête à l'emploi, sans CD de la carte-mère à rajouter, sans CDs additionnels pour les drivers, sans CDs additionnels pour les programmes. Le système installé est prêt à l'emploi, sans effort, avec des équivalents de tous les logiciels courants qu'on trouve sur la plate-forme "concurrente".
Pour moi, Linux est plus simple. A mettre en place et à utiliser. Car plus logique. Un peu différent certes, mais demande 3 heures d'adaptation.

20 fév. 2006
0

Je bien d'accord
avec toi, Robert. Peu importe qu'un bourrin fonctionne mieux qu'un autre ou pas, ce qui compte est effectivement ce que les gens utilisent. Ma réaction ne portait que sur des points avec lequels je ne suis pas d'accord, et qui sont bien loin du sujet du fil.

20 fév. 2006
0

çà progresse, çà progresse Robert
dixit linuxfr.org[...]12.html

..."Un petit journal pour signaler que mes statistiques aMule indiquent une forte progression de Linux sur les derniers mois.

En effet, il y a 3 mois, aMule arrivait difficilement à atteindre 0,3% du total des logiciels de P2P utilisés (le reste des logiciels utilisés sous Linux étant insignifiant, 0,1% tout au plus). Depuis, j'ai constaté que aMule est passé progressivement à 0,4%, puis aujourd'hui à 0,5% atteignant même parfois 0,6% (et toujours 0,1 à 0,2% cumulé pour le reste des logiciels de P2P sous Linux). Évidemment, tout ceci sans que je ne change rien à la nature des fichiers que je partage* depuis tout ce temps.

En quelques mois à peine, la proportion d'utilisateurs aMule a donc quasiment doublé. Cela reste des statistiques, et on ne peut donc leur accorder beaucoup de valeur, mais vous en tirerez vous même vos propres conclusions. Certainement que les échos récents dans la presse généraliste y sont pour quelque chose :-)"...

M'enfin çà reste inférieur à 1%.....

C'est aussi ce que me donnent mes statistiques sur mon site de marqueterie.

Pour palier aux viscicitudes des "fenêtres", j'ai trouvé un truc extra pour 40 euros, clône expert. çà permet de sauvegarder tout un disque ou une partition et de la remettre en service quand on veut.

J'ai donc 2 partitions XP au feu. Une en service et l'autre en réserve, copie conforme de la première au niveau des applications, mais pas en utilisation. Quand çà commence à merdouiller, je recharge la totalité de ma partition après avoir effacé la merdique et çà repart nikel. Naturellement mes données sont sur une troisième.

Çà vaut vraiment pas le coup de s'emmerder avec de multiples autres distributions.

19 fév. 2006
0

??
J’utilise indépendamment linux et windows, pour moi ce n’est pas un problème,
mais je me met à la place des utilisateurs basiques qui lorsqu’ il faut changer de version
ou ajouter un soft pas toujours bien pensé pour son installation suivant les distributions.

La multiplication des distributions RPM, Read heat , Suse ou autre ne facilite pas
l’engouement et le choix d’aller vers linux

j’avoue que winmachin est mal fait, mais il fonctionne si on ne lui demande pas trop
de choses à la foi car il ne supporte pas plusieurs applications (gourmandes en mémoire(voir maxsea))
en même temps (même si on à le top du top du moment)

mais pour quidam moyen c’est surement vers win qu’il va se retourner

19 fév. 2006
0

voilà bien ...
une querelle de clocher de spécialistes !

Ce qui compte, c'est la réalité des faits : le nombre d'usagers de Linus est infinitésimal comparé à celui des usagers de windaube.

Que les usagers de l'un ou de l'autre aient tord ou raison n'a aucune importance ;-)

19 fév. 2006
0

Méthode, suite 1
J'ai quitté un peu le fil pour le week end : avec la dépression qui vient de passer, vous pensez bien que j'allais pas rater la poudre fraiche. J'arrive juste d'une séance de navigation aux sensations dans le coton, avec de temps en temps un sapin qui s'invite dans la réalité qu'on s'arrange à faire passer sur le coté du champ visuel. Whaoooooo ! j'aime glisser sur l'eau, j'y peux rien, même lorsqu'elle est cristallisée. Et y'a une deuxième dépression derrière qui arrive ce soir...

Une parenthèses : je me suis trouvé une fois dans la benne de La Flégère à Cham avec Eric Tabarly. Il a vu que je le reconnaissais, et je crois qu'il n'aimait pas ça. Au sommet il a chaussé, et je me suis dit "tu te fais plaisir, tu skies avec lui". Eh bien j'aime autant vous dire que j'ai eu du mal et que j'ai finalement dû laisser tomber parce que ma douce de l'époque, en rade derrière bien que loin d'être nulle, n'aurait pas apprécié que je la largue pour un coureur des mers ! Sacré skieur, Eric !

Je reviens à mon fil. La discussion sur la méthode elle même, avec quelques interventions d'informaticiens, semble indiquer un certain consensus pour dire que l'important est de tirer les vers du nez des utilisateurs pour savoir ce dont ils ont besoin. Mais, et là je m'adresse aux non informaticiens qui me lisent, il doit être clair qu'on ne va pas leur demander de prendre position sur telle ou telle plateforme technique (un micro, un système d'exploitation, une distribution, etc...). Lorsque j'achète un CD de musique, je me fous de savoir si mon lecteur est un youkaidi ou un josephson. Je mets le CD dedans et j'entends la musique, c'est tout. La question est donc seulement de savoir quelle musique je veux entendre.

L'enfer, c'est bien connu, est pavé de bonnes intentions, et j'ai peur que les informaticiens que nous sommes, surtout lorsqu'ils se retrouvent à plus de deux dans un lieu quelconque, fut il le café du commerce du coin (ou un fil HEO), fassent fuir dans les minutes (ou les posts) qui suivent ceux pour qui l'informatique n'est qu'un outil sur leur bureau (ou sur leur table à carte). Alors, pour parler des mérites de linuxaube version trucmuche ou du langage pouet pouet, faisons un fil entre nous, en annonçant bien la couleur, pour que ceux qui s'en foutent ne perdent pas de temps.

Mais j'aimerais bien lire une discussion entre marins, qui ont quelque expérience de l'utilisation de l'informatique au bureau ou à la maison puisqu'ils sont sur HEO. Quelle que soit le degré (fut-ce le degré zéro) d'expérience de l'informatique en mer qu'ils aient, ils devraient pouvoir dire quels sont les services qu'ils aimeraient avoir de leur micro à bord. J'ai vu une application super sur Excel pour gérer la cambuse. Et je suis certain que des idées comme ça, il y en a d'autres.

Pour ce qui concerne la cartographie, effectivement comme cela a été dit, il y a des produits disponibles dans le commerce. Pour être un peu caustique, je dirais qu'au dernier salon il n'y avait que ça sur les stands. Mais je dois vous dire que pour l'instant, le site internet où je peux charger gratos des cartes vectorielles et le freeware qui permet de les lire, je ne connais pas, du moins pas des vraies cartes marines. Donc si ça n'existe pas, ça reste à faire. Le travail est double : créer les données, présenter les données. Dans les deux cas, je suis certain que le travail collaboratif est LA solution, et que c'est à la portée d'une communauté comme celle des heoiens : et là, l'exemple de Linux est effectivement instructif.

Mais AMHA vouloir faire quelque chose d'aussi précis, complet, évolutif, et donc "de référence" que les cartes marines, par exemple du réputé SHOM, est un leurre. Il faut avoir les cartes papier à bord et il faut savoir s'en servir. Mais quelque chose de plus simple (le trait de cote, les isobathes jusqu'à portée de la quille des voiliers pour les zones d'approche, ou jusqu'à portée de l'ancre pour les zones de mouillage, le balisage principal, par exemple devrait être suffisant. Et je pense qu'il n'y a pas besoin d'être informaticien pour discuter de savoir s'il faut faire des isobathes tous les mètres ou tous les dix mètres.

Par ailleurs, j'insiste sur l'enrichissement permanent par les utilisateurs. J'ai fait pas mal de camping car, à l'époque héroïque où des engins non toujours identifiables étaient bricolés par leurs propriétaires pour servir de villégiature roulante. Et savez vous sur quoi arrivait invariablement la discussion entre adeptes, une fois les présentations des hommes et des machines faites : sur les cartes. Chacun sortait la sienne (sa carte, botpipel), et on échangeait sur les bons coins, reportant force annotations... Après quelques rencontres, la carte toute crayonnée, on savait par exemple, en arrivant dans tel bled, qu'il y avait un robinet derrière une porte en bois sans cadenas dans la guérite à matos du fossoyeur au cimetière, et ainsi on avait le plein à portée de jerrycan.

Inconvénient évidemment, au bout de quelque temps, les autochtones se posent la question de savoir ce que toutes ces fourgonettes vont faire garées devant leur cimetière, il y aura des malins pour comprendre et mettre un cadenas sur la porte. Et il faudra trouver une autre source miraculeuse. Donc la gomme est un instrument aussi important que le crayon pour travailler sur une carte.

Personnellement, je verrais bien quelque chose comme ça pour HEOX. Enfin, je lance le bouchon, et on va voir jusqu'où il va flotter...

20 fév. 2006
0

J'voudrais pas être désagréable sailsoft
Mais c'est à la côte qu'une carte marine qui te permet d'identifier les amers est intéressante.

Si tu es un peu au large, même en restant à 1 mille, pour le trait de côte, et au risque d'être iconoclaste, une carte michelin suffit amplement. fous la paix à tes neurones.

20 fév. 2006
0

quoi qu'on fasse
on butte toujours sur le problème du contenu .
Quelle que soit la source, il est appartient toujours à quelqu'un . Que tu le scannes ou que tu ramasse un CD dans une poubelle .

Or sans un fond cartographique sérieux, il n'y a pas de programme de navigation utile .

Exemple d'un truc dont j'ai souvent eu envie :
La partie terrestre des cartes marines est lamentable .
La partie marine des cartes terrestres (IGN 1/25000) est meilleure que la partie terrestre des cartes marines mais pas assez fiable pour naviguer .
En dépit des liens organiques qui devraient exister entre le SHOM et l'IGN, cela ne change pas .
J'ai souvent eu envie de marier les deux . Je peut le faire tout seul dans mon coin sans grand risque . On sait décoder les fichiers BSB . On sait décoder les fichiers BYO . Passer d'une projection conique (Lambert) à une projection cylindrique (Mercator) n'est pas très compliqué .

Le faire collectivement ou publiquement !
Il s'avère que pour les cartes françaises, qu'elles soient SHOM ou IGN, un éditeur contrôle le jeux et n'hésite pas à employer les grands moyens pour protéger ses "oeuvres" en interdisant même de publier la façon dont elles sont codées (cf E. Sibert). Ce qui veut dire qu'il est risqué d'intervenir sur des fonds cartographiques protégés même pour en enrichir le contenu .

Et il y a peu de chances que cela change !

20 fév. 2006
0

Mais non tu n'es pas désagréable
mais au contraire fort pertinent. Refaire des cartes marines, avec comme tu le dis les amers, etc... n'est sans doute pas intéressant. Et même dirais-je à éviter, car le jour où un navigateur se planterait parce qu'il y aurait un bogue dans la carte ou le soft, et qu'il y aura des morts ou des bléssés graves, faudra bien que quelqu'un se présente devant le juge.

Mais par contre avoir un outil qui permet d'enrichir les cartes (cf mon exemple des cartes IGN 1/100 000 des camping-caristes toutes crayonnées) est non seulement à notre portée mais plus intéressant pour les utilisateurs.

J'en avais parlé sur un autre post (enrichir des carges google-earth). En fait, après réflexion, je me dis que les posts de nos forums heo sont référencés par thème / auteur / sujet / date. On pourrait y rajouter un geo-référencement (recherche par latitude / longitude).

Et finalement, il y a indépendance entre les données géo-référencées et le choix du "fond de carte" sur lesquel on les projette et on les rend accessibles. On peut tout gérer, qu'il s'agisse de cartes vectorielles en format standard (S 57), de photos satellite issues de G.E., de photos aeriennes (orthophotos des cotes) mises dans le domaine public par l'état, etc...

Je reviens donc, en écrivant ça, sur mon post précédent en reconnaissant que l'idée de refaire des cartes marines est sans doute une bétise (pour ne pas être désagréable avec moi même). Pour les neurones, ça va, quand ça fume trop, je débraye.

21 fév. 2006
0

Bien d'accord Alien
Il ne faut pas oublier que les cartes marines sont d'abord faites pour la navigation professionnelle et que seul leur format est accessoirement adapté à la plaisance.

Où sont passées les cartes anciennes, celles avec les hachures qui figuraient les reliefs et permettaient d'appréhender de loin le profil de la côte ? les cartes US présentent les courbes de niveau, mais sont en noir et blanc sous cette forme.

De toute façon attendu que l'électronique de positionnement prendra de plus en plus le pas sur la nav traditionnelle, ce sont ces procédés qui seront privilégiés par les éditeurs qui paieront le prix aux sources officielles pour avoir les fonds de cartes précis et mis à jour par les mêmes moyens Ces sources ne sont pas près d'être gratuites, le shom et les autres ne vont pas scier la branche sur laquelle ils sont assis.

21 fév. 2006
0

Pfouuuu...
Ben ca alors ...!?
Il était tant que j'arrête.( Et en plus je suis moutachus)
M'enfin... Bonne chance.

Votre réponse

Merci de contribuer aux réponses sur HISSE ET OH !

Merci de vérifier de bien répondre au sujet. Fournisser des détails sur votre réponse et partager votre expérience et vos recherches !

Mais éviter de …

  • Demander de l'aide ou de répondre à une autre question (utiliser les commentaires dans ce cas).
  • Porter un jugement et manquer de respect dans votre réponse.
  • Pour plus d'information, consulter la FAQ et la Charte de HISSE ET OH !

Déposer un fichier ici ou Cliquer pour envoyer

Oh fil de l'Oh

Souvenir d'été

  • 4.5 (185)

Oh fil de l'Oh

novembre 2021