rt3 Intégration des RADARS sur GPS RT3 /NAVIDRIVE

Quelques nouvelles structures de fichier (du travail pour JANFI67 ...)

 

Merci pour ces nouvelles infos

 

En attendant que je décortique tout ça et que je l'inclue, voila une nouvelle version avec quelques infos supplémentaires sur FRANCPOI.DAT, le champ n+19 et un des 2 flags. Avec en prime un schéma des liens entre les fichiers.

 

Edit:

Phil95, tes infos sur le contenu de XXXIND.COM sont très intéressantes. En effet, les infos dans les fichiers FRANCXXX.DSC sont triés par villes et avec XXXIND.COM, le systeme a un accès direct à partir d'une ville sur les POI. Ca nous éclaire un peu sur la manière d'ajouter des POI et sur les opérations à faire.

 

Edit2:

J'arrete le schweppes et/ou je n'écris plus tard le soir... Il y avait plein d'incohérences dans la dernière version... Quelques une sont corrigées.

Phil95, c'est toi qui avait parlé d'un champ échelle d'affichage? Ca doit être plus compliqué que ça. Il y a beaucoup de valeurs différentes, et un même type de POI peut avoir plusieurs valeurs...

Effectivement, il y a sans doute autre chose dans le flag de FRANPOI.DAT / FRANCDSP.POI; revons un peu ... Une valeur miracle qui ferait beeper le RT3 quand on s'approche d'un POI ?????

Plus serieusement:

 

DCN.CAT octet 2E, offset du premier caractere significatif du nom (on en a deja vu plein pour les rues, les villes ...)

 

Remarque sur FRANCDSP.POI octets 6-9

A mon avis, ce champ est invalide dans le cas des SCC; il pointe alors vers n'importe quel record de FRANCPOI.DAT, parfois ailleurs que dans la ville. Si on exclue les centre ville, il y a un seul DSP.POI pour un seul POI.DAT (verifie par programme sur mon CD).

 

Tres bonne idee le shema des liens; petite imprecision:

c'est FRANCPOI.DAT qui pointe vers SCITTANAME.DAT et non FRANCDSP.POI

remplacer FRANCXXX.POI par FRANCXXX.DST

 

Je cois qu'effectivement, on est pas mal avance pour commencer a developper.

J'ai commence a ecrire une moulinette pour inserer nos POIs; c'est loin d'etre evident, et l'ajout d'un seul POI modifie beaucoup de fichiers, de pointeurs, d'indexs ..., il y a des tris a faire, ...

 

Enfin on verra bien.

Il restera le probleme de la conversion des coordonnees...

Effectivement, il y a sans doute autre chose dans le flag de FRANPOI.DAT / FRANCDSP.POI; revons un peu ... Une valeur miracle qui ferait beeper le RT3 quand on s'approche d'un POI ?????

Plus serieusement:

 

DCN.CAT octet 2E, offset du premier caractere significatif du nom (on en a deja vu plein pour les rues, les villes ...)

 

Tres bonne idee le shema des liens; petite imprecision:

c'est FRANCPOI.DAT qui pointe vers SCITTANAME.DAT et non FRANCDSP.POI

remplacer FRANCXXX.POI par FRANCXXX.DST

 

Je cois qu'effectivement, on est pas mal avance pour commencer a developper.

J'ai commence a ecrire une moulinette pour inserer nos POIs; c'est loin d'etre evident, et l'ajout d'un seul POI modifie beaucoup de fichiers, de pointeurs, d'indexs ..., il y a des tris a faire, ...

 

Enfin on verra bien.

Il restera le probleme de la conversion des coordonnees...

 

A propos de l'insertion de POI... Je suis embeté de ne pas avoir trouvé d'ordre dans FRANCDSP.POI.

Si ce fichier n'est vraiment pas trié et vu sa taille (4 Mo) je doute qu'il soit chargé intégralement en mémoire je crains qu'il n'y ai quelque part (dans la cartographie?) des pointeurs ou des indices vers ces enregistrements pour permettre un accès direct depuis un MS vers tous les POI du MS.

 

Je vais essayer de chercher ça ce soir... mais ça ne me parait pas évident. Enfin, je sais qu'il y a un fichier avec beaucoup de références à des LS, MS, SS.. je commencerai par la.

 

J'ai corrigé le diagramme à midi, je pense que les erreurs que tu as détecté étaient dans la version de ce matin.

Bon, voila la reponse a ta question:

 

FRANCDSP.POI est trie par LS,MS,SS, mais LS et MS ne sont pas dans les records, et LS est planque dans X et Y; d'ou l'impression de desordre...

 

le fichier FRANC_EX.DPS contient 0xd800 enregistrements de 0x14 octets

Or 12 X 18 = 216 = 0xd8 et 12 X 16 X 18 X 16 = 0xd800

 

Le debut des enregistrements contient des pointeurs sur la cartographie mais surtout

les octets19 et 20 contiennent un index qui varie de 0 a 721E sur mon CD. Ceci veut dire qu'il y a 721E moyens carres qui contiennent qqc sur les D800 possibles.

 

Le fichier FRANCDPA.LZW contient 721F00 entrees de 16 octets (il faut le decompresser ...)

Donc: a partir de LS/MS on trouve une entree de FRANC_EX.DPS;

si FFFF, elle est vide, termine;

sinon on X par 256 et on ajoutte SS, et on a une entree de FRANCDPA.LZW

Cette entree est bourree d'index pointant dans d'autres fichiers ...

mais on trouve notamment:

octets 4-7: index FRANCDSP.POI (max 52E1B sur mon CD)

octets 8-9: nombre de records de FRANCDSP.POI pour ce petit carre...

 

J'avoue avoir pas mal cherche avant de trouver la nature de ces fichiers... coup de bol d'avoir trouve la signification des D8 et D800

 

Par contre, il faut le decompresser, le mettre a jour, et le recompresser (pas insurmontable) ...

 

A priori les autres champs sont utilises pour le tracage, j'ai compris pas mal de choses, mais pas tout, mais je sais qu'il n'y a rien sur les POIs

 

Par contre, j'ai un fichier qui m'interpelle:GRUPPO_2.DAT; il semble etre forme de plusieurs fichiers differents et je ne sais pas a quoi il sert ...

 

(Ouf - A suivre)

Bon, voila la reponse a ta question:

 

FRANCDSP.POI est trie par LS,MS,SS, mais LS et MS ne sont pas dans les records, et LS est planque dans X et Y; d'ou l'impression de desordre...

 

 

Bravo pour toutes ces infos...

 

J'avais bien pensé à cet ordre pour FRANCDSP.POI, mais un truc me chagrine:

 

J'ai essayé de localiser tous les POI dans FRANCDSP.POI de fegersheim (y'en a pas trop).

 

Pour ça, je commence par rechercher l'index de la ville dans SCITTANAME.DAT

0004087C 18728 FEGERSHEIM

 

Je cherche ensuite tous les enregistrements de FRANCPOI.DAT qui pointent vers cette ville :

 

00161D12 31622 19, RUE DE LA LIBERTÉ 03 FE 4E 16A8 00003D1F 0004087C 020A 26A 30C 000 0 0388640378

 

00161D43 31623 19, RUE DE LA LIBERTÉ 03 FE 4E 1B63 00003D1F 0004087C 0209 26A 30C 000 0 0388640378

 

00161D74 31624 24, RUE DE LYON 02 FE 4E 16A8 0000400E 0004087C 020A 3B7 09C 000 0 0388641777

 

00161DC9 31626 43, RUE DE LYON 12 FE 4E 56A8 0003A4C3 0004087C 020A 063 0E0 000 0 0388685354

 

0017E5FF 34281 N83 33 FE 4E 1B63 0002ED0D 0004087C 0209 03B 1FF 012 0 0388678167

 

5 enregistrements, tous dans le 4E (LS) FE (MS) et les SS groupés. Ca a l'air OK.

 

Ensuite, je cherche dans FRANCDSP.POI tous les enregistrements correspondant (qui pointent vers ceux de FRANCPOI.DAT) et les ennuis commencent :

 

Le premier trouvé est OK : 002AEF04 393EA 16A8 0EC4 026A 00161D13 020A

Mais pour le même enregistrement de FRANCPOI.DAT, je trouve 2 autres enregistrements de FRANCDSP.POI :

 

003CF0B4 5140E 115C 39D3 191D 00161D13 01F4

003D5F90 51D4B 115C 3902 1E5C 00161D13 01F4

 

Des centre-villes (déjà 2 pour la même ville, je suis un peu embeté) et pas placés du tout à coté du premier.

 

Pour le 2nd POI de FRANCPOI.DAT, tout va bien. Je trouve dans FRANCDSP.POI :

002AEF10 393EB 1B63 0EC4 026A 00161D44 0209

 

Pour le 3ème POI de FRANCPOI.DAT, rebelote. Un bon dans FRANCDSP.POI :

002AEEF8 393E9 16A8 086C 03B7 00161D75 020A

et un centre ville très bizarre :

003B9DCC 4F7D0 115C 2DD2 2042 00161D75 01F4

 

Même topo pour le 4ème. Un bon:

002AEF58 393F1 56A8 08B0 044B 00161DCA 020A

et toujours un centre ville bizarre

003DF398 529A1 115C 0B42 0573 00161DCA 01F4

 

Enfin le 5ème qui a l'air correct

002AEFE8 393FD 1B63 0DB7 0BF3 0017E600 0209

 

Avec tout ça, je n'ai même pas le centre ville de Fegersheim...

 

Au départ, je me suis dit qu'il n'y avait pas de tri, puisqu'une même ville apparaissait à plusieurs endroits dans FRANCDSP.POI. Mais je commence à me demander si le pointeur vers FRANCPOI.DAT dans FRANCDSP.POI est valide pour les centre ville?

 

Si tout ce que tu as trouvé se vérifie (non non, je ne suis pas St Thomas lol) on a tout ce qu'il faut (du moins en théorie) pour insérer un POI simplement affichable comme un radar. Il ne manque plus que la fonction de projection pour convertir lat/long en LS, SS, MS, X et Y.

J'imagine qu'elle n'est pas simple, car en général, une projection marche bien pour de petites étendues, pas pour toute l'Europe. C'est pour ça que celles que je connais (vaguement) utilisent plusieurs fuseaux rien que pour la France (3 pour UTM, 4 pour Lambert)

Ta conclusion est bonne (cf ma remarque de 17h 04)

 

J'ai constate les memes anomalies que toi, mais pres de chez moi. J'ai donc ecrit une moulinette qui essaye de verifier la correspondance entre FRANCDSP.POI et FRANCPOI.DAT en verifiant que x, y, et ss sont egaux. Naturellement, ca n'a pas marche.

 

J'ai remarque que les enregistrements de FRANCDSP.POI de type centre ville pointent vers des enregistrements aleatoires de FRANCPOI.DAT, des fois dans le meme carre, des fois totalement ailleurs.

 

J'ai donc modifie ma moulinette pour en ignorer les records de centre ville. La moulinette est assez longue (2 heures sur un P4 3Ghz) car je verifie pour tous les records de FRANCPOI.DAT qu'un et un seul record de FRANCDSP.POI pointe vers lui. Et ca marche: chaque record de FRANCPOI.DAT a un et un seul record de FRANCDSP.POI qui lui correspond.

 

Ouf ...

le fichier FRANC_EX.DPS contient 0xd800 enregistrements de 0x14 octets

Or 12 X 18 = 216 = 0xd8 et 12 X 16 X 18 X 16 = 0xd800

 

Le debut des enregistrements contient des pointeurs sur la cartographie mais surtout

les octets19 et 20 contiennent un index qui varie de 0 a 721E sur mon CD. Ceci veut dire qu'il y a 721E moyens carres qui contiennent qqc sur les D800 possibles.

 

Le fichier FRANCDPA.LZW contient 721F00 entrees de 16 octets (il faut le decompresser ...)

Donc: a partir de LS/MS on trouve une entree de FRANC_EX.DPS;

si FFFF, elle est vide, termine;

sinon on X par 256 et on ajoutte SS, et on a une entree de FRANCDPA.LZW

Cette entree est bourree d'index pointant dans d'autres fichiers ...

mais on trouve notamment:

octets 4-7: index FRANCDSP.POI (max 52E1B sur mon CD)

octets 8-9: nombre de records de FRANCDSP.POI pour ce petit carre...

 

J'avoue avoir pas mal cherche avant de trouver la nature de ces fichiers... coup de bol d'avoir trouve la signification des D8 et D800

 

 

 

Alors la.. chapeau! J'avais bien calculé 52296 mais de la à avoir l'idée de 12*18*256...

 

Encore quelques infos et on pourra en plus faire quelque chose qui intéresse beaucoup les frontaliers (dont je suis)... Merger 2 cartographies et refaire un CD. Dans mon utilisation quotidienne j'échangerais volontiers le Bade-Wurtemberg contre la Bretagne (j'aurais pu dire la Corse... mais ils sont suceptibles )

 

C'est vrai que GRUPPO_2.DAT est étrange. Des références de fichiers, les chaines des catégories de POI en anglais, des débuts commun d'adresses en français, anglais, italien et dans d'autres langues, des enregistrements de 20 octets qui ressemblent à u accélérateur de recherche (suite de caractères couramment utilisées), une table de pointeur avec FFFFFFFF comme valeur non significative, ... le contenu de FRANCAT.POI, des noms de villes et de département...

 

Je n'ai pas encore tout compris non plus

 

Voila la dernière version de la doc, mais terminée à plus de 2h du matin... elle contient certainement des betises.

Bonjour et bravo pour le travail effectué !

 

A la lecture des différents posts, je crois que vous êtes à la recherche du système de coordonnées avec lequel les POI sont répertoriés.

Je vous propose de comparer les données des fichiers avec les coordonnées en Lambert II étendu des POI et vous devriez trouver votre bonheur. ce système de coordonnées "orthogonal" est particulièrement adapté au pricipe de "dallage" que vous avez identifié.

Je reviens vers vous dans quelques jours après avoir fais quelques vérifications sur ce sujet.

 

A bientôt

Bonjour et bravo pour le travail effectué !

 

A la lecture des différents posts, je crois que vous êtes à la recherche du système de coordonnées avec lequel les POI sont répertoriés.

Je vous propose de comparer les données des fichiers avec les coordonnées en Lambert II étendu des POI et vous devriez trouver votre bonheur. ce système de coordonnées "orthogonal" est particulièrement adapté au pricipe de "dallage" que vous avez identifié.

Je reviens vers vous dans quelques jours après avoir fais quelques vérifications sur ce sujet.

 

A bientôt

 

Bonjour et merci beaucoup pour le coup de main.

 

J'ai découvert le système géodésique de Lambert après quelques lectures sur les coordoonées et la géodésie. Mais il me semblait que Lambert2 n'était valable que pour la Francé métropolitaine. Sur le site de l'ign (http://www.ign.fr/telechargement/education/fiches/geodesie/projections.pdf) il est même dit :"L'inconvénient de ce système est que l'altération linéaire est croissante vers le nord et le sud.". Je sais qu'il existe un système Lambert72 Belgique, mais qu'en est-il pour l'europe entière? En plus, Magnetti Marelli est italien, et Lambert un système français...

 

J'ai l'impression que la projection utilisée est plus "universelle" que ça, genre projection UTM associée au systeme géodésique ED50... et que la latitude/longitude d'origine change en fonction des zones (même si ça ne se voit pas dans LS, MS, SS, X Y ce qui complique encore les choses). Mais ce n'est pas exactement UTM, la taille des zones n'est pas la même. Quoique... on doit pouvoir mapper des coordonnées UTMXX (carrés de 100Km*100Km) sur un système LS,MS, SS, X Y

 

Mais tout ça n'est qu'une impression.. toutes les bonnes volontés sont les bienvenues...

 

Tant que j'y suis, j'ai récupéré quelques translateurs de coordonnées (circée de l'IGN, Convers, http://www.dmap.co.uk/ll2tm.htm) et j'aimerais faire des essais. Quelqu'un aurait-il les coordonnées lat/log de POI bien identifiés dont on connait LS, MS, SS X et Y? De préférence loin de l'Alsace que je puisse comparer avec mes mesures. L'idéal serait peut être des relevés faits avec le RT3 lui même devant nu POI,parce que les coordonnées lat/long de maporama et autres.. bof bof. Merci d'avance

Oui, toutes les bonnes volontes sont bonnes pour résoudre ce probleme de transformation de coordonnees.

 

Les essais que j'ai fait avec les centre ville se sont montres completement rates (D'ailleurs qu'estce qu un centre ville ? La place centrale du village ? le centre de gravite de l'aire du village ? un carrefour ?)

 

Les essais faits avec les mairies sont plus significatifs mais insuffisants (quelques kilometres sur la surface de la France, a partir de quelques points de reference).

 

Je pense qu'un solution presque acceptable serait de construire une base plus consequente (peut etre quelques centaines de point de reference sur la France, et d'agir par interpollation entre les 3 points les plus proches du point recherche.

 

Le gros du boulot est la constitution de cette base de référence.

 

Il y a une autre piste, tres ardue a explorer.

Dans le fichier FRANC_EX.DPS, il y a 3 coefficients qui m'intriguent beaucoup:

 

(0xD800 records de 0x14 octets)

14-15 coef1

16 coef2

17 coef3

Ces trois coefficients ont l'air d'etre lies aux latitudes et longitudes du MS correspondant:

Leurs valeurs varient assez regulierement (quand on parcours un MS, on va 16 fois vers l'est puis un grand coup vers l'ouest et un peu en haut, et on recommence 15 fois, etc...). Or ces coef vaient suivant cette loi. Ceci semblerait indiquer que les carres de projection sont des MS. Comment utiliser ces coefs ? Pas de reponse...

 

Pour ce qui est du fichier GRUPPO.DAT, je pense qu'il decrit en realite le layout du CD; n'oublions pas que deux versions differentes ou de pays differents de la carto ne comprennent pas forcement les meme fichiers (moi j'ai pas de GUIDA_CHAMPERARD.POI). De plus, lorsqu'on a les noms de rue, on n'a pas le type de la voie (rue, boulevard, avenue, ...). Il est probable que ce nom est code, et que le nom est dans ce fichier.(Non je n'ai pas encore trouve comment).

 

Peut etre y a t'il aussi des modifs a faire dans ce fichier ?

 

(A suivre)

J'ai fait quelques essais cet après-midi enfaisant mes courses.

 

J'ai pris les coordonnées GPS de POI que j'avais repéré sur la carto.

 

Pas évident d'ailleurs de prendre des coordonnées GPS. D'abord, faut arriver à se garer pile-poil sur le POI... et avec un 807, ça bouche un peu... Après, il y a des erreurs dans la cartographie. La mienne confond un restaurant avec la mairie, séparés de 400 bons metres. Ensuite, le GPS en lui même n'est pas d'une folle précision. Une vingtaine de mètres quand les conditions sont bonnes. Et en pratique il est difficile de faire des mesures totalement reproductibles. Faites une mesure, un demi-tour et revenez au même endroit... ben, vous n'êtes plus exactement sur le POI... Sur une route, on ne s'en rend pas trop compte, je crois que le système fait un mélange de la position GPS et de la route sur laquelle il croit que vous roulez pour vous mettre le triangle au meilleur endroit possible, et pas dans les champs ou à contre sens sur l'autoroute. Mais quand les POI ne sont pas sur une route, plus de corection. Idem quand on tourne d'ailleurs, il prend quelques secondes à corriger la position du curseur.

 

Mais bon, ce n'est pas le sujet lol.

 

Muni de mes coordonnées et de mes fichiers RT3 j'ai calculé avec Excel :

 

Un E, N (c'est comme ça qu'on dit dans la bonne littérature) dans le système du RT3 avec LS, MS, SS, X et Y

E = X + 1000*SS mod 16 + 16000*MS mod16 + 256000*LSmod 12

N = Y + 1000*SS div 16 + 16000*MS divd16 + 256000*LS div 12

 

Mais comme je ne fais pas mes courses très loin de chez moi, seul SS varie.

 

Et en utilisant mes coordonnées latitude/logitude et Circé2000 de l'ign, j'ai essayé toutes les transformations possible de coordonnées géographiques en coordonnées planes

 

source :

*SYSTEME : WGS84

*TYPE : GEOGRAPHIQUES

*ELLIPSOÏDE : GRS 1980

*MERIDIEN : Greenwich

*UNITE : DMS

 

destination :

LAMBERT OACI-DECCA, EuroLambert, LambertEuroCarto, UTM Nord fuseau 32 (je suis dedans))

 

pour avoir un autre couple E,N. Et rien à faire, ça ne colle pas, quelque soit la transformation.

 

Si je prends le point le plus au nord est comme référence, l'erreur entre E et N dans les 2 systèmes augmente avec la distance. Pourtant, je ne me suis pas éloigné de plus de 10 Km entre les POI les plus extremes...

 

Ca me fait penser que j'ai lu quelque part un facteur d'échelle (très proche de 1, à 4 ou 5 décimales près) lié à UTM...

Et que dans Circé il y a un résultat Altération linéaire (en mm/Km que j'ai oublié de générer)... C'est quoi ça au juste? Peut être faut-il que je corrige mes valeurs E et N avec ce coefficient qui change pour chaque point?

 

Si quelqu'un de compétent en géodésie lit mes quelques lignes et s'il se sent le courage d'intervenir... Ce sera bien volontiers

Combien de points as tu releve ?

Combien de points as tu releve ?

 

Une douzaine, mais je n'ai testé les coordonnées que sur 5.

 

Ci-joint mon excel de travail et la translation utilisée

 

*Samedi 26/8/2006 -- 19:49:22

*Résultat de la transformation de type Standard entre:

*SYSTEME : WGS84

*TYPE : GEOGRAPHIQUES

*ELLIPSOÏDE : GRS 1980

*MERIDIEN : Greenwich

*UNITE : DMS

 

*SYSTEME : ED50

*TYPE : PLANES

*PROJECTION : UTM Nord fuseau 32

 

* E N Alt Conv(HMS) Alt Lin(mm/km)

406960.681 5377661.294 0.000 0.034675 -293.7

404571.743 5374643.635 0.000 0.035235 -288.1

404592.778 5374674.164 0.000 0.035230 -288.2

404570.177 5374551.007 0.000 0.035234 -288.1

402555.595 5371960.215 0.000 0.035705 -283.3

402071.790 5371289.114 0.000 0.035818 -282.2

* Fin Samedi 26/8/2006 -- 19:49:22

Bonjour Janfi67

Peux tu m'envoyer les autres points que tu as releve ?

 

Je pense que tes points sont trop rapproches et que c'est de la que viennent tes problemes.

En effet:

une incertitude de 1 sec d'arc correspond a un ecart de plus de 30 m plus l'incertitude due au RT3 (faut il prendre le centre de l'icone, il y a des erreurs de carto, ...); je pense qu'il faudrait essayer de prendre des points situes aux extremites d'un moyen carre pour voir les resultats.

 

Car de toutes façons, localement, il devrait exister une relation lineaire entre les lat/lon et les LS:MS/SS/X/Y.

 

Si on ne trouve pas cette relation, il peut y avoir plusieurs raisons:

1/ Notre theorie des carres est fausse.

2/ Il y a trop d'incertitude sur nos points de reference

3/ La carto est fausse

4/ Les coordonnees des points sont volontairement fausses (XOR de x et y avec une valeur cachee).

 

Objectivement, je ne sais pas quoi penser pour l'instant

Bonjour,

 

Je vois que ça bosse dur !!

J'ai donc vérifié une éventuelle cohérence des données que j'avais extrait d'un CD NAVTEQ destiné à un système VDO-Siemens avec celles qui figurent sur le CD fourni avec mon RT3.

Je n'ai pas retrouvé la présence de LII étendu ce qui va dans le sens de la remarque de Janfi.

Par contre, étant en possession des coordonnées NAVTEQ (en LII étendu) pour un certains nombres de POI's, je propose de prendre les POI "communes" ou les POI "Gares" comme base de travail.

Avec les coordonnées de ces POI, je propose de les positionner sur un sig (Mapinfo) avec les informations qui vous avez identifié comme étant celles de positionnement.

Une certaine logique devrait se dégager ...

Qu'en pensez vous ? L'avez vous déjà fait ?

 

A bientôt

 

Sunny 307

Bonjour Janfi67

Peux tu m'envoyer les autres points que tu as releve ?

 

Je pense que tes points sont trop rapproches et que c'est de la que viennent tes problemes.

En effet:

une incertitude de 1 sec d'arc correspond a un ecart de plus de 30 m plus l'incertitude due au RT3 (faut il prendre le centre de l'icone, il y a des erreurs de carto, ...); je pense qu'il faudrait essayer de prendre des points situes aux extremites d'un moyen carre pour voir les resultats.

 

Car de toutes façons, localement, il devrait exister une relation lineaire entre les lat/lon et les LS:MS/SS/X/Y.

 

Si on ne trouve pas cette relation, il peut y avoir plusieurs raisons:

1/ Notre theorie des carres est fausse.

2/ Il y a trop d'incertitude sur nos points de reference

3/ La carto est fausse

4/ Les coordonnees des points sont volontairement fausses (XOR de x et y avec une valeur cachee).

 

Objectivement, je ne sais pas quoi penser pour l'instant

 

 

Hello.

 

J'ai aussi pensé que mes points étaient un peu proches les uns des autres, néanmoins l'erreur a l'air de varier avec la distance... Dès que j'ai un peu de temps, je complète ma fauille excel avec les autres points. Mais ils faut que je retrouve les POI dans les fichiers, j'ai fait d'autres relevés que ceux que j'avais préparé.

 

1/ pour les carrés, ça a pourtant l'air de bien marcher. C'est un sytème couramment utilisé et pour qu'ils se rejoignent correctement, il vaut mieux qu'ils soient de dimension constante. Néanmoins, il me semble qu'UTM utilise des fuseaux (et des zones?) en partie basés sur des angles constants? Il faut que je creuse

 

2/ Les mesures GPS sont loin d'être parfaites, mais il y a une erreur qui devrait être du même ordre de grandeur pour chaque point. L'erreur ne devrait pas varier en fonction de la référence

 

3/ Il y a des erreurs, c'est sur. Mais généralement, un POI sur la carte est bien ou il est indiqué. La corrélation avec le pointeur de l'écran, la position carte et la position réelle est plutot bonne

 

4/ On devrait le voir avec un plus grand nombre de points. Si l'erreur est aléatoire, les coordonnées sont peut être faussées. Mais ce n'est pas mon impresson, au moins sur des POI proches. Les valeurs relatives de X et Y me semblent cohérentes, ou tout du moins placer les points dans les bonnes directions.

 

C'est vrai qu'à toute petite échelle, la relation lat/long -> E,N devrait presque être linéaire. Circé2000 nous montrera si c'est vrai et jusqu'à quelle limite.

 

Bonjour,

 

Par contre, étant en possession des coordonnées NAVTEQ (en LII étendu) pour un certains nombres de POI's, je propose de prendre les POI "communes" ou les POI "Gares" comme base de travail.

Avec les coordonnées de ces POI, je propose de les positionner sur un sig (Mapinfo) avec les informations qui vous avez identifié comme étant celles de positionnement.

Une certaine logique devrait se dégager ...

Qu'en pensez vous ? L'avez vous déjà fait ?

Sunny 307

 

Les gares, ça me parait une bonne idée. PLus que les communes, car on peut vérifier les coordonnées en allant devant.

Je vais voir si je peux extraire facilement les POI de type gare et les mettre dans un excel pour les travailler.

 

A plus

Voici la verison que j'utilise !

 

SIF+

Release DRF E35723-1 (Q1-2005)

France (33.0.0)

Date Wed Apr 06 17:27:11 2005

 

Travaillons nous sur la même base ?

Moi je travaille avec

SIF+

Release DRF E37471-1 (Q2-2005)

FRANCE (34.0.0)

Date Thu Jul 07 16:33:22 2005

 

Je ne suis pas sur que deux personnes travaillent sur la meme version; toutefois, il ne semble pas y avoir de differences notables d'une version a l'autre ...

Nouvelle version de Navidraw, avec utilisation de fichiers juqu'alors inutilises ... La doc suivra plus tard.

Oui, je sais, la navigation n'est pas pratique, la souris n'affiche pas x et y, s'il n'y avait que ca ... Mais on commence a tracer.

Pensez a remplacer FRANCDPA.LZW par sa version decompressee ...

Si vous trouvez des choses interessantes sur la nature des traces, faites en profitter tout le monde...

Voici la verison que j'utilise !

 

SIF+

Release DRF E35723-1 (Q1-2005)

France (33.0.0)

Date Wed Apr 06 17:27:11 2005

 

Travaillons nous sur la même base ?

 

Voila un excel avec toutes les gares issu de la version

 

SIF+

Release DRF E37471-1 (Q2-2005)

FRANCE (34.0.0)

Date Wed Jul 13 16:50:25 2005

 

j'ai l'édition 2 2005/2006, je suppose que tu as l'édition 1

 

Je joins en attachement le script python qui m'a permis de décoder FRANCPOI.DAT. Un simple grep sur le type ne laisse que les gares.

Il serait bon de travailler sur le même version

Il serait bon de travailler sur le même version

 

 

Dites-moi

 

Ce serait bien pratique en effet...

Bonjour, d abord je voulais vous feliciter pour vos recherche qui corresponde a de grandes heures de travaille. Je ne suis pas informaticien mais j arrive a me debrouiller sur certaine chose. Donc si je peut vous etre utile pour des saisi ou autre si besoin s en fait et si quelqu un est pres a m expliquer se que je doit faire, je serai tout a fait prêt et ravi d y contribuer. N hesitez pas de me demander. Je vous souhaite a tous une bonne journée et encore felicitations pour ce travail

Je crois que travailler tous avec la meme version ne serait pas une bonne solution; en effet, visiblement nous avons tous des versions differentes, ma version et celle de Janfi67 etant totes les deux des versions Q22005, l'une du 13 juillet 2005 et l'autre du 7 juillet 2005. Il est meme possible qu'il n'y ait pas 2 CDs identiques.

Je pense qu'on doit plutot chercher a etre le plus universel possible et si possible etre independants de la version de la carto.

Aujourd'hui on attaque des fichiers tres importants puisqu'il s'agit des fichiers contenant la carto proprement dite:

 

FRANC100.DPL:

Fichier index de 0d8h entrees de 12h octets (indexee par LS)

0-3: no record FRANC100.DRL

4-5: N1 ?

6-7: N2 ?

8-9: N3 ?

10-11: N = N1 + N2 + N3 = nombre de records du carre dans FRANC100.DRL

12-15: offset dans fichier FRANC100.DEG

16-17: ?

 

FRANC002.DPL:

Fichier index de 0d800h entrees de 12h octets (indexee par MS)

0-3: no record FRANC002.DRL

4-5: N1 ?

6-7: N2 ?

8-9: N3 ?

10-11: N = N1 + N2 + N3 = nombre de records du carre dans FRANC100.DRL

12-15: offset dans fichier FRANC002.DEG

16-17: ?

 

FRANC100.DRL

Fichier routes basse resolution: records de 17h octets

chaque record decrit un segment de droite (bipoint)

0-3: X0

4-7: Y0

8-11: X1

12-15: Y1

16-17: troncon

18: flag du troncon

19-22: offset FRANC_NV.DAT

X0,X1,Y0,Y1

 

FRANC002.DRL

Fichier routes moyenne resolution: records de 0eh octets

chaque record decrit un segment de droite (bipoint)

0-3: P0

4-7: P1

8-9: troncon

10-11: offset FRANC_NV.DAT

Pourr les deux points,

X = P & 0x3fff

Y = (P >> 14) & 0x3fff

flags = (p >> 28) & 0xf

 

FRANC100.DEG

Fichier autres traits (frontieres, ...)

Suite d'enregistrements de longueur variable:

0: nature du trait ?

1-2: 15 bits de poids fort indiquant le nombre de points n

1 bit de poids faible indiquant la presence de 3 octets d'entete supplementaires.

si bit de poids faible octet 2:

3-5: ?

suite de n points sous la forme de 8 * noctets:

3 ou 6 + (n * 8) a 3 ou 6 + (n * 8 + 3): X

3 ou 6 + (n * 8 + 4) a 3 ou 6 + (n * 8 + 7): Y

X et Y

 

FRANC002.DEG

Fichier autres traits (voies ferrees, fleuves, ...)

Suite d'enregistrements de longueur variable:

0: nature du trait ?

1-2: 15 bits de poids fort indiquant le nombre de points n

1 bit de poids faible indiquant la presence de 3 octets d'entete supplementaires.

si bit de poids faible octet 2:

3-5: ?

suite de n points sous la forme de 4 * n octets:

3 ou 6 + (n * 4) a 3 ou 6 + (n * 4 + 1): X

3 ou 6 + (n * 4 + 2) a 3 ou 6 + (n * 4 + 3): Y

X et Y

 

FRANC_EX.DPS

Fichier index D899h records de 0x14 octets

0-3: entree FRANC_EX.DSS

4-7: entree FRANC_EX.RID

8-9: ?

10-11: ?

12-13: ?

14-15: Ajust1 ?

16: Ajust2 ?

17: Ajust3 ?

18-19: index FRANCDPA.LZW (decompresser le auparavant)

 

FRANCDPA.LZW Fichier compresse (cf Navidec) enregistrements de 0x10 octets

0-3: offset FRANC_DET.DRS

4-7: no record FRANDSP.POI + flags

8-9: nb de records FRANCDSP.POI

10-13: offset FRANC.DEG

14-15: n; n*3 represente l'increment du champ precedent.

 

FRANC.DEG:

Fichier complement de traces haute resolution

Suite d'enregistrements de longueur variable:

0: nature du trait ?

1-2: 15 bits de poids fort indiquant le nombre de points n

1 bit de poids faible indiquant la presence de 3 octets d'entete supplementaires.

si bit de poids faible octet 2:

3-5: ?

suite de n points sous la forme de 3 * n octets:

3 ou 6 + (n * 3) a 3 ou 6 + (n * 3 + 2): P

X = P & 0x3ff

Y = (P >> 10) & 0x3ff

flags = (p >> 20) & 0xf

 

Ouf (Bon courage JANFI67 ...)

 

 

Tous ces fichiers sont utilises dans NaviDraw version 1.10

 

Ceux d'entre vous qui l'ont essaye ont pu constater que les traces manquent de precision:

Par exemple les autoroutes sont formes de 2 traits qui devraient etre paralleles. Or on constate que les deux voies se croisent assez souvent et que l'ecartement des deux voies varie. Il est presque sur que les bits de poids faibles des coordonnees des point sont modifies (xor avec une constante par exemple, ou plus complique). Je n'ai a ce jour pas trouve la formule "magique", peut etre la meme que pour les POIs

 

(A suivre, mais on s'approche du but ...)