des dates au lieu de coordonnées

[bermund]

En ouvrant les listes de zones de danger (pour Nissan Connect), j'ai remarqué qu'une certaine proportion de zones de danger avaient pour longitude des dates (c'est le cas, par exemple, de 52 zones de danger feu rouge sur 716 zones signalées). On trouve ce problème dans beaucoup de fichiers (presque tous). Ce sont donc des zones qui ne peuvent être lues puisqu'il manque l'une des coordonnées. Ne serait-ce pas l'une des causes de certains manques de zones ?

D'autre part, le format des coordonnées est variable de 6 à 9 chiffres (plus le point) pour les longitudes et de 5 à 8 (plus le point) pour les latitudes (soit des formats de [xx.xxxx] à [xx.xxxxxxx] pour les latitudes et de [x.xxxx] à [x.xxxxxxx] pour les longitudes). Cela n'explique-t-il pas certaines disparitions de zones de danger signalées dans divers topics (soit les zones de dangers que l'on retrouvent sur les cartes (par exemple Google maps ou sur Mapsource -Garmin) mais pas dans le GPS en utilisation) : je doute, mais peut-être le fait-il, je n'en sais rien, que Nissan Connect soit capable de lire des coordonnées de type [xx.xxxxxxx ; x.xxxxxxx] qui sont d'ailleurs d'une précision inutile, parce que le format qu'on lui a(urait) défini est plus court, dans ce cas il écrase(rait) une partie des coordonnées pour les lires sur un format plus court et ce ne sont pas nécessairement les derniers chiffres du format qu'il écrase(rait) si celui-ci est trop long ? Par exemple au lieu de lire [1.2345678; 12.3456789] il pourrait lire [2345678;.3456789] et pas forcément [1.2345;12.3456] soit respectivement les 7 et 8 derniers caractères des coordonnées. N'ayant pas d'exemple de zones de danger avec des coordonnées long format à proximité de mon domicile je ne peux vérifier cette hypothèse. Qu'en pensent les spécialistes du GPS, ce que je ne suis pas.

[Lufop]

Hello, des dates!

C'est marran ca! Ca viendrait pas du format d'excel? Tu a assayé avec notepad?

Lufop

[bermund]

Effectivement, c'est marrant : par exemple si on ouvre le fichier feu rouge avec Scalc (Open office) on trouve cette coordonnée [01/02/13 , 47.09955 ,] (la quatrième de la liste, sur le tri par défaut) mais si on l'ouvre avec le Bloc note on trouve [2.3813 , 47.09955 ,] !!!
Encore plus rigolo, quand on ouvre le fichier avec Scalc, il y a d'abord une première fenêtre d'importation des données où l'on peut vérifier que l'on l'importe bien au bon format, et dans cette fenêtre les coordonnées sont correctes ! Ce n'est qu'ensuite que les cordonnées de longitude (certaines) sont transformées en dates !?? Je n'ai pas essayé avec Exel, mais je vais le faire ainsi qu'avec 123. Mais il me semble qu'Exel ait des difficultés avec certains fichiers .csv (j'avais déjà essayé d'y transformé des waypoints de randos) mais pas avec 123 (ex Lotus). Bon je n'ai rien écrit ! Dont acte.

[bermund]

Suite des bizarreries marrantes :
toujours à propos des fichiers .csv avec Nissan Connect : si on enregistre des fichiers avec PoiEdit au format Garmin.csv (c'est, en principe, le format de Nissan Connect), Nissan Connect ne les reconnait pas ou bien toutes (TOUTES) les longitudes (ou les latitudes je ne sais plus) sont lues 00.00000 ! Et toutes les distances affichées de ces POI sont à plus de 5400 km (un peu comme si le POI était au pôle nord, sans doute ?) ! Alors que, même, si on les ré-ouvre avec le Bloc note (Notepad) elles sont correctes. Quand je modifie des coordonnées pour Nissan connect je n'utilise que le Bloc note mais sans l'enregistrer au format .txt (ça ne marche, pas non plus) en conservant le format d'origine .csv !

Bon à savoir quand même qu'il vaut mieux utiliser Notepad.

Merci de ta réponse.

[Lufop]

content que ça soit cà ! (ouf)

Je sais pas si tu connais mais je te conseille notepad++ -> http://notepad-plus-plus.org/fr/
Pour le nombre de décimale je regarderai ça prochainement .

Merci et a bientôt !

[SyStem_D]

Bonjour,
Après des tests il n'y a aucunes bizarreries, fait un clic droit sur la cellule comportant une date et format, elle doit être au format date donc forcément peut importe le chiffre il est automatiquement mis en jj/mm/aaaa.
Quand on ouvre un csv ne pas importer dans un document sur lequel on à déjà travaillé, les paramétres sont gardés, soit faire nouveau document ou simplement sur le fichier .csv ouvrir avec ... et toujours repartir de l'original téléchargé.
Quand au 00.0000 dans poiedit si c'est avec le fichier ouvert précédement comme il a gardé les dates c'est normal poiedit ne gére pas ce format
Pour l'écrasement en cas de long chiffre, l'écriture étant toujours de la gauche vers la droite (à part si on à définit un autre type d'écriture) ceux sont bien les derniers qui ne sont pas pris en compte (prendre exemple sur une simple calculette ou on à définit 3 chiffres après la virgule et rentrer 4.1111111111111 elle affichera 4.111) ca aussi ca se regle dans le tableur (excel, Ooo, libreOffice ou autre) en sélectionnant les colonnes et format.
En plus excel par défaut traite les csv avec des ; donc un csv avec des , sera mis dans une seule colonne et obligera un traitement données.

attention au format lng, lat ou lat, lng là oui on a des surprises 4.26, 2.64 et 2.64,4.26 ne donneront pas le même résultat forcément .

Les fichiers sont bons, vu le nombre de personnes les utilisant il y a longtemps que le problème aurait été remonté, il faut vérifier les paramétres du logiciel avec lequel on va le traiter.

En espérant que cela vous sera utile, bonne journée

[bermund]

Oui, c'est une question de format d'affichage, les chiffres eux-mêmes ne sont pas modifiés.

Cependant si on modifie puis enregistre un fichier garmin.csv avec PoiEdit, mon expérience est qu'après Nissan Connect lit une des coordonnéees O.0000 (j'ai fait cette expérience avec des fichiers autre que ceux de Lufop).

Pour ce qui concerne ma remarque sur la longueur des coordonnées, c'était juste une hypothèse pour expliquer ce que j'ai lu sur les forum Lufop où certains remarquaient que des zones manquaient. Vu le nombre de zones dans les fichiers Lufop, le plus élevé que je connaisse (il y a encore quelques semaines j'utilisais des fichiers venus d'ailleurs, je ne connaissais pas Lufop), ça me parassait étonnant et j'ai cherché des explications.

Donc RAS. Merci des réponses.

Autre question :
Je connais un radar tronçon du coté d'Alès (sur la D16), double sens, la sortie dans un sens correspondant à l'entrée dans l'autre sens. Dans ce cas comment entrer les données pour qu'elles puissent être lues par les GPS comme Nissan Connect qui ne tiennent pas compte du sens de circulation ? J'avais pensé à décaler de 100 m vers l'amont, dans le sens de circulation, les coordonnées de la sortie : est-ce judicieux ?
Cela donnerait avec Nissan Connect dans n'importe quel sens d'abord une alerte entrée, puis immédiatement une alerte sortie, puis vers la fin un alerte sortie et enfin, immédiatement après une alerte entrée ! (!! ???) Mais quoi d'autre ?

[philgoodgood]

bonjour

@bermund : ya rien a faire, le logiciel embarqué dans le GPS connect de Nissan est tres tres pauvre (seule la distance d'alerte au radar est paramétrable et est unique quelque soit la catégorie)
tomtom te donne les alertes sur la route sur laquelle tu roules, NISSAN te donne les informations sur le périmètre (le rayon de détection)
donc ca alertera pour toutes les positions de poi enregistrées dans cette zone, sur ta route, dans les 2 sens et sur les routes d'a-coté

enfin c'est comme ca sur mon QQ version mai 2011 et pour les POI perso de type "warning" bien sur

[bermund]

Merci de me répondre.
En fait je vais ouvrir un autre sujet, à savoir comment envoyer les coordonnées des radars tronçons pour qu'ils soient utilisables, justement par les GPS type Nissan Connect?