La bande du sud

[DeLaval]

Je lance un nouveau fil pour évoquer les questions liées à la cartographie. Ce terme regroupe en fait plusieurs choses différentes :

1) Il faut que le serveur sache où sont situées les terres, afin de déterminer si le bateau peut passer ou s'il est échoué.

2) Il faut que le serveur puisse afficher une carte au joueur sur laquelle apparait la position des bateaux et les indications de force du vent.

3) Les deux systèmes précités doivent être cohérents : Pas de stupidités du style : je grimpe sur les plages du finistère et j'entame un voyage dans les terres pour finalement rester coincé du côté de Plouguerneau; ou du genre : je suis échoué sur les iles Chausey qui existent mais n'apparaissent pas sur la carte !

Il nous faudra trouver ces données sous la forme de fichiers libres de droits, et exploitables.
Le format devra être manipulable par le programme client. Cette question est donc liée à celle du choix du langage de programmation.

[archibal]

Question peut etre idiote
Si on retrace une carte a partir d'un soft type Intellidesk, a partir d'un fond de plan.
C'est du taf, surtout si on veux tt redessiner, mais c peut etre une solution.
Ou bien on peut faire du partiel....
Moi je me suis scratché a Agadir cause WEnd prolongé, je me serais retrouvé a Marrakech avec obligation de retour j'aurais au moins continué la course....de tt maniere j'avais pris la mauvaise option alors dernier ou avant dernier c pas grave .
"l'important c de participer"

[DeLaval]

Depuis quelques jours je me suis mis à penser au système de cartographie de notre jeu.

Comme je l'ai déjà dit, celui-ci a une double utilité :

Premièrement il contient les données permettant l'affichage de la carte par le client
Deuxièmement il est utilisé par le serveur pour vérifier que les bateaux ne sont pas échoués

Par ailleurs, en y réfléchissant, je suis arrivé à la conclusion que le principe de codage des données devaient permettre :

- une division de la carte du monde en plusieurs zones. Ainsi, le logiciel qui doit accéder aux informations n'a pas besoin de parcourir tout le fichier. Il se contente de consulter la zone qui l'intéresse.
- une précision variable en fonction de l'endroit. Par exemple, dans le jeu de la route du rhum, la carte, qui couvrait tout l'atlantique nord, devait offrir une précision assez bonne aux abord de Saint-Malo et de la Guadeloupe, mais médiocre pour le reste.
De même pour nous, si l'on envisage de courir des régates en rade de Brest, il nous faudra une description de cette zone à quelques centaines voire dizaines de mètres près. Mais hors de question d'avoir cette précision sur la totalité du globe : Outre que le travail pour y parvenir serait irréalisable, cela conduirait à un fichier de données d'une taille monstrueuse !
- des modifications aisées, et notamment il devait être possible d'y ajouter au fur et à mesure des informations supplémentaires, soit concernant la cartographie de nouvelles zones, soit à propos d'un secteur particulier dont on souhaite augmenter la précision.
- une possibilité de séparation en plusieurs fichiers.

Cogitant à partir de ce cahier des charges, j'ai trouvé je crois une solution assez élégante.
Je vous la soumets :

Tout d'abord on part du principe que l'on indique que les terres. Autrement dit, l'information contenue dans le fichier cartographique indique ou on a de la terre et rien d'autre. Là où rien n'est indiqué, c'est qu'il y a de la mer.

Ensuite, on subdivise la carte par une méthode qui s'opère en deux étapes :

1) On découpe le monde en différentes zones, chaque zone étant comprise entre deux méridiens et deux parallèles (i.e. des longitudes et latitudes mini et maxi). Les zones en question ont une taille au plus de l'ordre de grandeur d'un continent. Remarquez au passage qu'il est inutile de se préoccuper des zones océaniques ne contenant aucune île, puisqu'on n'indique que les terres.

2) Chaque zone est ensuite redécoupée en fonction de la précision requise. Pour ce faire, on fait appel à une technique récursive...
A partir de maintenant suivez bien, et au besoin prenez un papier et un crayon pour faire des petits dessins parce que je n'ai pas mis d'illustrations (trop chiant à faire).

Imaginons que nous soyons en train de regarder la carte de l'une des grandes zones telle que définie au 1). Que voyons nous ? Nous voyons une partie de cette zone recouverte de terre, le reste étant occupé par la mer. Bien. Mais justement, il nous faut décrire plus précisément l'intérieur de cette zone et dire où est la mer, et où est la terre.
A cette fin, on trace un méridien situé à mi-chemin des méridiens extrêmes de la zone, et de la même façon un parallèle médian à égale distance des parallèles nord et sud de la zone.
La zone est ainsi découpées en quatre parties que nous appellerons quadrants. Le premier quadrant est au nord-est, le deuxième au nord-ouest, le troisième au sud-ouest et le quatrième au sud-est.
Il est possible que certains des quadrants obtenus soient entièrement constitués de terre ou de mer. Dans ce cas, inutile de s'en préoccuper davantage, il suffit d'ignorer celui ou ceux qui délimitent des zones purement maritimes et d'indiquer celui ou ceux qui sont purement terrestres ( toujours selon le principe fixé au départ : on n'indique que la terre, la mer est partout ailleurs).
Mais en général, l'un au moins des quadrants englobe à la fois une surface marine et une surface de terre. Il est donc nécessaire d'en décrire l'intérieur.
Alors on recommence l'opération au sein de ce quadrant que l'on découpe en 4 sous-quadrants. On répète le même raisonnement plusieurs fois jusqu'à ce que la taille des quadrants soit telle que la finesse de la description soit jugée suffisante.

Avez-vous compris le principe ?

Bon, je vais faire comme si, et continuer.


Maintenant me demanderez vous, cette idée est bien jolie, mais concrètement, comment implémenter cela ?
Et bien, voici la réponse : en XML ! (encore lui !)

Pourquoi en XML ? Parce que c'est un format standard lisible par les navigateurs internet et avec lequel on peut intéragir en JavaScript (langage candidat probable pour le logiciel client), et parce qu'il est parfaitement adapté pour décrire une structure hiérarchique telle que celle qui est définie par les découpages successifs de la carte.

Alors voilà à quoi j'ai pensé.

On définit d'abord la balise <z> (pour zone) :


<Z id="####" lat_min="####" lat_max="####" lon_min="####" lon_max="####" src="####">
(...)
</z>


L'attribut id est l'identifiant de la zone (= son nom), et il est obligatoire.
Les attributs lat_min, lat_max, lon_min, lon_max sont obligatoires et correspondent aux latitudes et longitudes extrêmes de la zone.
L'attribut src est facultatif, il correspond à l'URL du fichier contenant la description de la zone lorsque celle-ci est stockée dans un fichier extérieur.

On définit ensuite les balises <q1>, <q2>, <q3> et <q4> (pour premier, deuxième, troisième et quatrième quadrant) :

<q1 src="####"> (...) </q1>
<q2 src="####"> (...) </q2>
<q3 src="####"> (...) </q3>
<q4 src="####"> (...) </q4>

L'attribut src est facultatif, il correspond à l'URL du fichier contenant la description du quadrant lorsque celle-ci est stockée dans un fichier extérieur.

Et c'est tout !

Après, on applique le principe de départ : On n'indique la terre, on ignore la mer:

On repère les zones où il y a des terres, et on les spécifie avec les balises <z>.

Ensuite, à l'intérieur de chaque balise (ou éventuellement dans un fichier extérieur mentionné par src="###") on spécifie les quadrants de la zone qui contiennent de la terre. Ceux qui délimitent une zone de mer seulement, on les omet.
Pour chaque quadrant cité, on recommence l'opération. Lorsqu'un quadrant ne contient que de la terre, ou lorsque sa taille est jugée suffisamment petite, on laisse la balise vide.


Alors ?

Vos avis sur cette brillante idée ?

[samba]

Bravo Delaval !

Division par zone : c'est effectivement plus efficace d'autant que certaines zones ne seront peut etre jamais utilisées.

Précision variable : je rajouterai à ton exemple de St malo et PAP, un besoin de précision près des iles qui figurent sur la route.

On indique que la terre : ça c'est vraiment l'idée géniale, qui associée aux principes du découpage par cadran, permet une optimisation maximum du programme.

Bravo, maintenant j'attends que tu nous expliques comment tu traduis cette info sous une forle visuelle (visualisation de la cote).

Sinon meme pas mal à la tete !!!!

[silenzio]

Très clair, ressemblant au système de quadrillage des cartes d'état-major employées par l'armée de terre, permettant' entre autre, de désigner des objectifs ou position en coordonnées kilo, hecto, déca métriques; La difficulté va se trouver au moment de projeter une surface sphérique ( la vrai surface terrestre ) sur une surface plane à savoir une carte, qu'elle soit sur papier ou sur écran. Il y aura, suivant la solution retenue:
- des zones d'ombre
- des zones doublées donc floues
- des zones ( comme sur les cartes IGN )représentant des "carrés triangulaires", les méridiens n'étant pas, par définition, parallèles.
Si je ne suis pas clair, j'essayerais de faire un croquis et de l'expédier.
_________________


"Dans la vie, l'occasion d'être un héros se présente deux ou trois fois mais presque chaque jour se présente celle de ne pas être lâche"

[DeLaval]

Oui Silenzio, je vois tout à fait de quoi tu parles, j'ai cogité à cela aussi.

C'est pour ça que les zones de départ ne devront pas avoir une trop grande extension, en tout cas pas dans le sens nord-sud.

Il faudra se restreindre à des zones dans lesquelles la distance entre deux méridiens reste à peu près constante. Ainsi, les quadrants garderont des proportions "largeur/hauteur" à peu près constantes.

Tout près des pôles par contre, les quadrants seront effectivement "triangulaires" mais à la limite ce n'est pas gênant.

Pour la projection utilisée, on pourra éventuellement proposer plusieurs choix , Mercator ou autre, mais ça c'est à l'étape de l'affichage que ce sera vu.

Par contre, je n'ai pas capté le coup des zones "doublées donc floues".
pourrais-tu expliciter ?

[silenzio]

Je voulias dire par là que dans une bande taillée N/S sur notre spére, si nous ne faisons pas des "carrés triangulaires" trés tôt sur les parralléles au niveau au moins des tropiques. En faisant des "petits" carrés on se retrouvera forcement avec des informations doublées .

Là au niveau du foncé, non?
_________________


"Dans la vie, l'occasion d'être un héros se présente deux ou trois fois mais presque chaque jour se présente celle de ne pas être lâche"

[COMIC]

je pense avoir un peu compris! Beau boulot
_________________

[thathalie]

[DeLaval]

[soufriere]

J'ai à peu près compris le principe que tu proposes DeLaval.
Cela me parait très bien.

Reste à définir la taille des "carrés" minimaux (ceux que l'on ne subdivise pas en cadrans et dont on dit qu'ils ne contiennent forcément que de la terre ou que de la mer).

Et bien sur, il faut voir aussi comment afficher cela sur la carte pour que les données prises en compte par le serveur pour déterminer l'échouage soient les mêmes que celles affichées sur la carte du client.

Quant au problème de la rotondité de la terre, cela me parait un problème à part entière qu'il faudra traiter sur un autre topic (peut-être en existe-t-il déjà un) : comment calculer le déplacement du bateau en foncion de sa vitesse et de son cap ?

[DeLaval]

La tailles des quadrants minimaux peut être choisie au cas par cas selon l'endroit.

On peut décrire un port en quadrants qui ont une dimension de l'ordre du mètre, et représenter une cote dont il n'est pas prévu que l'on s'approche trop près par des morceaux de 100 km.
c'est justement là tout l'intérêt de la méthode.

La cohérence entre les cartes du serveur et celle affichée par le client repose tout simplement sur le fait que les deux se basent sur la même information.

Quant à la rotondité de la terre, elle est automatiquement prise en compte puisqu'on raisonne en termes de latitude et de longitude.

Après, la projection utilisée pour l'affichage c'est une autre question mais qui ne pose pas de problème particulier (il suffit de se reporter à la définition mathématique de la projection choisie)

Ex: pour mercator : http://fr.wikipedia.org/wiki/Projection_de_Mercator

[soufriere]

En fait, quand je parlais de rotondité, je pensais surtout au problème de calculer le déplacement du bateau : quelle est l'évolution en latitude et longitude d'un bateau qui avance à un cap de X degrés par rapport au nord ? Cette évolution dépend je pense de la latitude.

Mais ce type de calcul doit exister quelque part sur le net.

[DeLaval]

Ah oui, d'accord.

En fait tu parles là des formules relatives à la trajectoire loxodromique.

Effectivement, ce sera un truc à voir, mais les formules en question sont connues et on pourra les trouver sans difficulté.

[soufriere]

Voila ce que j'ai trouvé sur un forum (http://www.lion1906.com/Php/Forum/ForumPostDetail.php?IdPost=903&Arbo=1&SansRep=&Debut=15). On devrait pouvoir s'en inspirer.

Sujet : calcul du 2ème point GPS grace à la distance (par LeZouave le 22-08-2006 à 13:4 Répondre
Message :
Pour ce faire, il faut calculer la projection de la distance sur la longitude et la latitude (on raisonne en géométrie plane car les distances sont petites)
Latkm=2.5*cos(cap)
Lo nkm=2.5*sin(cap)

Ensuite, il faut transformer ces km en angle.
C'est immédiat si les distances sont petites

Latdegre=(Latkm/6366) *(180/pi)
Londegre=(Lonkm/6366)*(18 0/pi)/cos(lat)

lat étant la latitude du point de départ

Ensuite ajouter au sens algébrique les valeurs trouvées aux coordonnées du point de départ.

Les valeurs étant en degré, il faut peut-être les tranformer en minutes et secondes.

Attention au signe, les Londegre négatives indiquent une direction vers l'Ouest, et les Latdegre négatives une direction vers le Sud.

Ces calculs sont basés sur des approximations qui sont justifiées si la distance du point visé n'est pas trop grande (moins de 50km)