Discussion :

[souviron34]

Bonjour

Je met ce post ici, car je pense qu'il aura plus d'audience, mais il est AUSSI à destination du sous-forum IGN, et du forum externe GeoRezo.

J'ai eu l'occasion il y a peu de récupérer des données provenant de divers SIG, et mes observations ont rejoint certaines anciennes remaques que j'avais déjà eu l'occasion de formuler sur le forum Algorithmes à propos de la précision des données. Du coup je crée ce post pour attirer l'attention des programmeurs et fournisseurs d'outils, ainsi que des utilisateurs. Vous pouvez bien entendu partager ce post où et avec qui vous voulez.

• Tout d'abord concernant la précision des données GPS: je vois souvent sur le forum Algo des personnes postant avec des données ayant 12 ou 14 décimales. Il faut savoir que les GPS ne fournissent des données qu'au mètre près . Pour s'en convaincre, on peut se référer aux documents originaux : le document officiel du gouvernement américain sur le GPS :http://www.gps.gov/systems/gps/performance/accuracy/
  
  On y lit :
  
  

  Real-world data collected by the FAA show that some high-quality GPS SPS receivers currently provide better than 3 meter horizontal accuracy

  Et
  

  Higher accuracy is available today by using GPS in combination with augmentation systems. These enable real-time positioning to within a few centimeters, and post-mission measurements at the millimeter level

  En gros, tout ce qui est en dessous du mètre de manière générale et en dessous du mm si on bénéficie d'équipement/sources particulier(e)s n'a aucun sens : ça a bien une valeur numérique (parce que c'est un nombre flottant qui est envoyé), mais pas de valeur physique.. Les GPS publics sont en général à 10 mètres près, les militaires au mètre.
  
  Etant donné que grossièrement 1 degré = 100 km, alors une précision de 5 chiffres est au mètre. Donc un GPS ne donne pas plus que 5 chiffres significatifs après la virgule.
  
  Cette remarque permet de diminuer la taille des Bases de Données d'environ 50%, et d'avoir des données qui ont du SENS....
  
  
  
  
• Si maintenant on regarde les outils/logiciels : les opérations arithmétiques se passant en coordonnées flottantes, beaucoup (tous ?) les logiciels style IGN, ESRI, ou autres, utilisent bien plus de décimales que celles initiales.. SAUF QUE LA PLUPART LES RESSORTENT SOUS CETTE FORME..... Ce qui est aberrant... Si on a une précision du mètre en entrant, on ne peut pas mathématiquement avoir une précision supérieure en sortant. Et c'est même le contraire : on diminue la précision à chaque opération...
  
  Les logiciels ET les programmeurs d'outils ne devraient donc pas ressortir plus de décimales qu'ils n'en ont eu en entrée... Or les remarques que j'ai pu faire sur les données à ma disposition m'amenaient à des précisions de 10^-12 ou 10^-13... Soit au micron près, pour des bordures de parcelles de terrain !!!!!!! Ce qui entraîne des artefacts certains et gênants (auto-intersections par exemple), et un volume de données bien supérieur à ce que cela devrait être : par exemple lors de l'accrochage de portions de contour à une autre portion, cela crée des points supplémentaires situés à 10^-12 des précédents. Des mesures que j'ai pu faire, cela double environ le nombre de points initiaux. Tout simplement parce que bien que les valeurs numériques soient différentes en flottant, elles ne le sont pas à la précision des données initiales ..
  

Je tenais à vous faire partager cette réflexion, pour 3 raisons principales :

• d'une part en tant qu'utilisateurs vous diminueriez, avec les 2 effets cumulés, la taille de vos Bases de Données par 75%, et donc doubleriez les vitesses de calcul et/ou d'affichage, en ayant beaucoup moins de problèmes du style auto-intersections ou autres du même style.
  
  
• d'autre part parce qu'en tant que programmeur ou fournisseur de logiciels SIG, il est inconcevable de créer des données avec plus de précision que celle des données entrées. C'est aberrant mathématiquement. (et cela amène du coup à des complexifications des algos utilisés pour vérifier "une égalité" ou non, une pente, une linéarité, etc)
  
  
• enfin parce qu'il semble que de nos jours la notion d'ordre de grandeur ait fortement disparu, et que la logique d'un physicien que je suis par rapport aux ordres de grandeur est choquée par de telles pratiques, qui, outre leur manque profond de bon sens, justifient souvent le recours à des blbliothèques spécialisées "grands nombres" par exemple, alors que c'est parfaitement inutile.

Voilà.

J'espère que cela pourra vous servir, et sera diffusé largement, car cela m'apparaît comme un problème de fond (un peu comme le nombre de gens pensant, avec l'essor de GoogleMap et des outils connexes, qu'une distance entre 2 lat/lon est simplement une distance euclidienne)

Cordialement

Jean

[Jérôme_C]

J'adore ce genre de coup de gueule Un sujet sur les abus dans les usages en informatique contemporaine. Malheureusement il y a quelques approximations, surement liées au fait que souviron n'a fait que récupérer des données pour valider un programme. J'apporte donc un regard un peu plus pratique à ces déclarations.

Tout d'abord, précisons qu'avec 15 décimales sur une coordonnées GPS, nous sommes à l'angström près, soit le rayon commun d'un atome.


Ensuite, remarque critique générale à propos de ce sujet intitulé remarques sur la précision à destination des utilisateurs et créateurs de logiciels SIG : le sujet en fait est celui de l'utilisation des coordonnées géographiques exprimées en degré décimal (L'EPSG:4326 pour les intimes).

Cette précision est loin d'être anodine. Le plus naturel pour des coordonnées dans un système d'information est d'être exprimé en mètres. Les coordonnées géographiques exprimées en degré décimal sont très pratiques pour quelques petites choses fondamentales, mais pas pour le système d'information :
- L'interopérabilité, la communication des coordonnées. N'avoir que des coordonnées géographiques exprimées en degré décimal est très pratique, cela évite toutes ces erreurs qu'on voit tous les jours.
- Se repérer très grossièrement. Les latitudes et longitudes du coin, au degré près, souvent on connait.

Notons que certains SIG acceptent de travailler avec ce système de coordonnées, d'autres n'acceptent de travailler qu'avec un système de coordonnées projetées.


Pour les avantages en terme de performances d'une base de données d'une optimisation sur le nombre de chiffres sur la latitude et la longitude, souviron donne la réponse en fin de message :

J'espère que cela pourra vous servir, et sera diffusé largement, car cela m'apparaît comme un problème de fond (un peu comme le nombre de gens pensant, avec l'essor de GoogleMap et des outils connexes, qu'une distance entre 2 lat/lon est simplement une distance euclidienne)

Faire de la géométrie sphérique, ou convertir dans un système projeté sur chaque requête avec un peu de géométrie, ça va vous plomber vos temps de réponses, bien plus que 50 %, je vous le garantis. Une distance euclidienne, c'est bien plus simple que tous ces sinus, cosinus, logarithme népériens et autre fonctions rationnelles.



Maintenant, le fond du message, même si je trouve qu'il est un peu hors sujet

Tout d'abord concernant la précision des données GPS: je vois souvent sur le forum Algo des personnes postant avec des données ayant 12 ou 14 décimales. Il faut savoir que les GPS ne fournissent des données qu'au mètre près . Pour s'en convaincre, on peut se référer aux documents originaux : le document officiel du gouvernement américain sur le GPS :http://www.gps.gov/systems/gps/performance/accuracy/

Ou alors on peut simplement avoir suivi quelques cours à ce sujet, suivi une formation professionnelle, lu le petit livre rouge ou pratiquer réellement la mesure sur le terrain.

Le GPS qui fournit des données au mètre près, ce n'est que le premier chapitre d'un cours sur le GPS, il y a un peu plus à savoir que cela.

En gros, tout ce qui est en dessous du mètre de manière générale et en dessous du mm si on bénéficie d'équipement/sources particulier(e)s n'a aucun sens : ça a bien une valeur numérique (parce que c'est un nombre flottant qui est envoyé), mais pas de valeur physique.. Les GPS publics sont en général à 10 mètres près, les militaires au mètre.

Un GPS public, ce n'est pas que le TOM TOM de voiture ou de randonnée.

Les GPS professionnels (je fais bref mais je peux faire un petit cours sur le GPS si besoin ), sont plutôt de nos jours couramment décimétriques (précisions de plusieurs décimètres), le centimétrique professionnel temps réel est très accessible, le millimètre est réservé pour des points de contrôles précis. En dessous, on y arrive aussi, mais c'est de la géodésie, on ne va pas le rencontrer dans les SIG tous les jours.

Pour les besoins d'un SIG classique, on va dire que nous sommes décimétrique, et donc une précision de 1e-6° !


Ensuite, une précision métrique, cela signifie-t-il qu'on doit avoir une grille d'un pas d'un mètre pour exploiter nos données ? Couramment il veut mieux avoir une résolution d'1/10 de la précision de nos données.

Ceux qui travaillent avec les données raster auront déjà remarqué qu'on travaille au 1/10 de pixel, le calage est plus précis que le pixel entier, on arrive à distinguer des objets inférieurs à la taille d'un pixel.

Un exemple simple de saisie d'une ligne droite permet de voir qu'une résolution égale à notre précision est néfaste : Imaginons la ligne droite sur une coordonnées Y finissant en 1.5 m. L'arrondi au plus près nous donnera soit 1 m, soit 2 m selon notre avancée sur la ligne. Et donc, au lieu d'avoir une ligne droite, on aura des zigzags très peu élégants.

Donc pour les besoins d'un SIG classiques, nos coordonnées devraient donc au moins être exprimés au centimètres, et donc en degré décimal 1E-7°.

Etant donné que grossièrement 1 degré = 100 km, alors une précision de 5 chiffres est au mètre. Donc un GPS ne donne pas plus que 5 chiffres significatifs après la virgule.

Cette remarque permet de diminuer la taille des Bases de Données d'environ 50%, et d'avoir des données qui ont du SENS....

Passer de 12 à 5 chiffres, je travaillerais plutôt raisonnablement à 7 chiffres après la virgule pour ne pas avoir tous mes utilisateurs sur le dos. Cette considération atténue les conséquences sur la base de données d'une telle mesure. Et encore, je ne prend pas l'exemple du SIG topographique qui va demander des précisions de ses jeux de données au centimètre près, et donc 9 chiffres après la virgule.

Ce qui entraîne des artefacts certains et gênants (auto-intersections par exemple), et un volume de données bien supérieur à ce que cela devrait être : par exemple lors de l'accrochage de portions de contour à une autre portion, cela crée des points supplémentaires situés à 10^-12 des précédents. Des mesures que j'ai pu faire, cela double environ le nombre de points initiaux. Tout simplement parce que bien que les valeurs numériques soient différentes en flottant, elles ne le sont pas à la précision des données initiales ..

Tu es juste en train de te plaindre que tu ne travailles pas avec un SIG topologique (GRASS par exemple), ou bien qu'il n'y a pas de validation topologique dans le cas d'un SIG non topologique (ESRI par exemple). Ne confondons pas les problèmes !

Si maintenant on regarde les outils/logiciels : les opérations arithmétiques se passant en coordonnées flottantes, beaucoup (tous ?) les logiciels style IGN, ESRI, ou autres, utilisent bien plus de décimales que celles initiales.. SAUF QUE LA PLUPART LES RESSORTENT SOUS CETTE FORME..... Ce qui est aberrant... Si on a une précision du mètre en entrant, on ne peut pas mathématiquement avoir une précision supérieure en sortant. Et c'est même le contraire : on diminue la précision à chaque opération...

J'ai vu des logiciels qui nous sortaient des précisions atomiques, mais beaucoup ou tous, pas vraiment. Je vérifie...

Sur GlobalMapper (version d'essai dispo), version 14 : le curseur est au millimètre pour les coordonnées projetées, à 1e-4 secondes pour l'affichage DMS, soit 1 centimètre de résolution.

Sur QGIS (logiciel libre), version 1.8.0 : le curseur est au mètre.

Sur Circé, logiciel de l'IGN pour convertir les coordonnées version 4 : Résultat exprimé au millimètre, 1e-5 secondes pour l'affichage DMS, 1e-8 pour l'affichage en degrés décimaux.

Les dizaines de décimales superflues dans quasiment tous les logiciels, je ne vois donc pas vraiment comme une réalité.

d'autre part parce qu'en tant que programmeur ou fournisseur de logiciels SIG, il est inconcevable de créer des données avec plus de précision que celle des données entrées. C'est aberrant mathématiquement. (et cela amène du coup à des complexifications des algos utilisés pour vérifier "une égalité" ou non, une pente, une linéarité, etc)

De nombreux SIG vont te demander la précision de tes données afin d'adapter la grille de saisie, de validation ou simplement l'affichage (deux exemple que je connais : GeoConcept et ArcGIS lorsqu'on travaille avec le format natif la geodatabase, et non pas avec le format d'export, le shapefile).

Ton SIG s'adapte au projet, pas l'inverse. Ne me fait pas un logiciel qui ne va pas accepter des coordonnées métriques avec virgule ! Une anecdote sur l'utilisation d'un SIG, j'ai appris l'utilisation d'un SIG pour de l'anatomie, car le docteur en question ne connaissais pas l'époque de logiciel médical permettant de faire ce qu'il voulait.

enfin parce qu'il semble que de nos jours la notion d'ordre de grandeur ait fortement disparu, et que la logique d'un physicien que je suis par rapport aux ordres de grandeur est choquée par de telles pratiques, qui, outre leur manque profond de bon sens, justifient souvent le recours à des blbliothèques spécialisées "grands nombres" par exemple, alors que c'est parfaitement inutile.

Une bibliothèque grand nombre pour un SIG, absurde en effet. Tu as des exemples en SIG ?

Rien que la transmission à l'oral des coordonnées suffisantes, c'est beaucoup moins fastidieux.

[bretus]

En gros, tout ce qui est en dessous du mètre de manière générale et en dessous du mm si on bénéficie d'équipement/sources particulier(e)s n'a aucun sens : ça a bien une valeur numérique (parce que c'est un nombre flottant qui est envoyé), mais pas de valeur physique.. Les GPS publics sont en général à 10 mètres près, les militaires au mètre.

Je confirme les dire de Jérome, tu passes assez aisément en dessous de 10 cm de précision avec certaines techniques (différentiel, etc.)

[*]d'une part en tant qu'utilisateurs vous diminueriez, avec les 2 effets cumulés, la taille de vos Bases de Données par 75%, et donc doubleriez les vitesses de calcul et/ou d'affichage, en ayant beaucoup moins de problèmes du style auto-intersections ou autres du même style.

Les coordonnées sont représentées avec des doubles en base de données (OGC Simple Feature for SQL). Au passage, on ne stocke pas que des coordonnées en GPS dans les base de données du type PostGIS, mais aussi des coordonnées projetées. En Lambert 93, on y éclate vite la limite des flottant. C'est par exemple utile quand on fait de la surveillance de bâtiment pendant qu'on creuse dessous.

[*]d'autre part parce qu'en tant que programmeur ou fournisseur de logiciels SIG, il est inconcevable de créer des données avec plus de précision que celle des données entrées. C'est aberrant mathématiquement. (et cela amène du coup à des complexifications des algos utilisés pour vérifier "une égalité" ou non, une pente, une linéarité, etc)

De nombreux SIG travaillent sur des grilles.

[*]enfin parce qu'il semble que de nos jours la notion d'ordre de grandeur ait fortement disparu, et que la logique d'un physicien que je suis par rapport aux ordres de grandeur est choquée par de telles pratiques, qui, outre leur manque profond de bon sens, justifient souvent le recours à des blbliothèques spécialisées "grands nombres" par exemple, alors que c'est parfaitement inutile.

On a besoin de bibliothèque de "grand nombres" (ou pire : des arbres d'expression) pour assurer des constructions exactes. En gros, pour éviter d'avoir à arrondir les résultats des utilisateurs sur une grilles avant la fin des opérations.

Essaye peut-être de comprendre l'approche de la bibliothèque CGAL avec ses "exact predicate exact construction kernel" (CGAL: The Open Source Computational Geometry Algorithms Library vidéos).

Ensuite, c'est une question de pragmatisme : Il est plus simple d'écrire les algorithmes en arithmétique exacte qu'en faisant de l'analyse sur chaque opération sur les flottants ou en faisant du SnapRounding (qui est à l'état de recherche en 3D pour ce que je sais)

Simple remarque : Pour les SIG libre, la bibliothèque de référence est JTS en java et son portage GEOS en C++. Vous y trouverez la notion de PrecisionModel qui permet de définir une grille et celle ci ne repose pas sur des grands entiers.

[souviron34]

Tout d'abord, à ll'intention de Jérôme C, qui a l'air de me prendre de haut : je ne suis pas aujourd'hui utilisateur, et je me tamponne comme de l'an 40 que vous fassiez de fausses mesures.. Ce n'est pas un coup de gueule du tout... C'est une remarque..

Si cela vous hérisse le poil, tant pis, je n'y peux rien..

Ma remarque et ce post ont été établis après une discussion avec un responsable négional d'un pôle spécifique de cartographie d'une administration française, lui-même historien et géographe depuis 30 ans. Moi je ne suis pas du domaine précis, mais je suis confronté à ces problèmes depuis maintenant 18 ans..

Cela fait 17 ans que je travaille avec des données SIG, et je fûs responsable d'un outil national à utlilisation critique.. Mais pas en France..

Simplement je vois tous les jours des questions aberrantes sur le forum Algo, je suis un physicien de plus de 30 ans d'expérience, et il se trouve que dernièrement j'ai eu cette expérience citée juste au dessus..


Venons-en au fond :

Malheureusement il y a quelques approximations, surement liées au fait que souviron n'a fait que récupérer des données pour valider un programme. J'apporte donc un regard un peu plus pratique à ces déclarations.

Non, j'avais mes propres données, créées depuis plus de 15 ans, et un Service de Géomatique d'une très grande ville française m'en a fourni tout à fait offciellement.

Y compris après vérification chez eux, ce sont donc des données 1) telles qu'elles sont effectivement stockées, et 2) avec les explications du Responsable, y compris alors qu'en entrée des SIGs utilisés il donnait la vraie précision.

Je ne me serais pas permis d'émettre cette remarque auterement..

Tout d'abord, précisons qu'avec 15 décimales sur une coordonnées GPS, nous sommes à l'angström près, soit le rayon commun d'un atome.

Effectivement j'avais noté de le corriger puis ça m'est passé au dessus en faisant autre chose .Je vais de ce pas le corriger..

Note: bizarre, le bouton EDITER n'est plus sur ce message...

Ensuite, remarque critique générale à propos de ce sujet intitulé remarques sur la précision à destination des utilisateurs et créateurs de logiciels SIG : le sujet en fait est celui de l'utilisation des coordonnées géographiques exprimées en degré décimal (L'EPSG:4326 pour les intimes).

Si tu veux...

Les coordonnées géographiques exprimées en degré décimal sont très pratiques pour quelques petites choses fondamentales, mais pas pour le système d'information :

Ceci est faux....

C'est très pratique pour un système d'information géographiue SI IL MANIPULE PLUSIEURS PROJECTIONS EN MEME TEMPS.. ou sil veut changer de projection dynamiquement.

Par exemple un des cas sur lesquels j'ai eu à travailler est exactement ce qui se passe en ce moment-même au Québéc, au Lac-Mégantic. Moi c'était pour le fleuve St-Laurent , mais c'est la même chose : une pollution se passe (un accident, un bateau s'échoue, une usine laisse fuir ..). Les gardes-côtes utlilisent UTM. Le fleuve et ses courants sont cartographiés par une université tous les 10 cm en profondeur et tous les 5 mètres en longueur sur 500 km. Un modèle de dispersion de pétrole dans l'eau, avec les courants et les algues, est bâti et prend des coordonnées relatives, en mètres. Mais il lui faut en entrée aussi les préviisons de vent, qui, elles, sont établies en coordonnées stéréo-polaire. Ce qui se passe est :

• Les gardes-côtes relèvent les coordonnées de la nappe actuelle (en UTM).
• Ils envoient ça à la météo
• La météo utilise ses préviisons de vent (en stéréo-polaire), les injecte avec les coordonnées et les caractéristiques de la nappe et la cartographie spécifique du fleuve au modèle de dispersion
• Il en sot une cartographie (relative) temporelle des mouvements et formes de la nappe
• La météo doit indiquer heure par heure aux gardes-côtes et à l'armée où poser des barrages flottants pour éviter le maximum de pollution des côtes (donc en retradusiant en UTM)

Faire de la géométrie sphérique, ou convertir dans un système projeté sur chaque requête avec un peu de géométrie, ça va vous plomber vos temps de réponses, bien plus que 50 %, je vous le garantis. Une distance euclidienne, c'est bien plus simple que tous ces sinus, cosinus, logarithme népériens et autre fonctions rationnelles.

On dirait vraiment que tu me prends pour un c.n.


Quand je parle de gain en place, c'est parce que stocker un batiment à l'angstrom près, c'est idiot..

Non, tu ne trouves pas ça idiot ??


D'autre part, je ne sais pas sur quels systèmes tu travailles, mais moi c'était sur l'Amérique du Nord (6000*6000 km), avec des informations venant d'un peu partout, des avions, des bateaux ou des bouées au large de l'Atlantique ou du Pacifique, des ballons-sondes, des modèles numériques, des stations météo au sol, etc... Ou bien des garde-côtes et les urgences météo et l'armée.. Et environ 6 à 10 bases de données réparties sur 3 continents et possédant chacune leur propre projection, à afficher le tout simultanément sur le même écran, en temps réel svp..


Mais de toutes façons, je ne vois pas ce que vient faire cette remarque : d'une part une distance euclidienne est fausse, tout simplement.. A moins d'être déjà dans le bon système..

Mais surtout quand je parle de 50%, c'est que au lieu de stocker :

45.2323232323223 2.22222222222222

On ne devrait stocker que

43.232323 2.222222

au grand max... Donc au lieu de 2+1+13 caractères par point, seulement 2+1+6... Soit 8 au lieu de 16 par coordonnée... D'après mes calculs ça fait bien environ 50% non ????

Ou alors on peut simplement avoir suivi quelques cours à ce sujet, suivi une formation professionnelle, lu le petit livre rouge ou pratiquer réellement la mesure sur le terrain.

Visblement, ce n'est pas ce qui est connu de nombre de gens postant sur le forum algo...

Le GPS qui fournit des données au mètre près, ce n'est que le premier chapitre d'un cours sur le GPS, il y a un peu plus à savoir que cela.

Les GPS professionnels (je fais bref mais je peux faire un petit cours sur le GPS si besoin ), sont plutôt de nos jours couramment décimétriques (précisions de plusieurs décimètres), le centimétrique professionnel temps réel est très accessible, le millimètre est réservé pour des points de contrôles précis. En dessous, on y arrive aussi, mais c'est de la géodésie, on ne va pas le rencontrer dans les SIG tous les jours.

Alors dis-moi pourquoi ce service tout à fait officiel de l'Administration française me fournit des limites de parcelles de développeent urbain au nanomètre ?? Et d'autres indications, que je ne peux divulguer, mais où des positions de choses macroscopiques sont données et stockées avec 13 décimales alors que cela n'a strictement aucun sens ???


Quelques extraits de notre conversation :

• En effet c'est stupide d'avoir autant de décimales. J'ai vérifié les données, et à mon avis, cela vient des logiciels utilisés (QGis et GDAL ?). J'ai crée la couche avec QGis il me semble qu'il ne propose pas de tolérance ou avec ArcGis ; je garde dans ce cas la tolérance par défaut, qui est à 0,001 m (ce qui est trop précis pour du zonage qui sera imprimé à 1/2000). Dans notre service, nous créons toujours les données en cartésien. Pour la création des zones, je me base à 99% des sommets des parcelles de la base Cadastrale.
  Sur QGis, et peut être d'autres, quand je récupère les coordonnées, je viens de faire un test, j'ai (au moins) 8 chiffres après la virgule.

  Normalement notre cadastre se veut avoir une précision au mm... En même temps il n'a pas de topologie... Le dernier bornage que j'ai reçu, le géomètre à indiqué 2 chiffres après la virgule.
  C'est donc anormal de prétendre aller en dessous...
  Toutefois, c'est à mon sens plus un problème de conception des outil sig que des utilisateurs. À mon sens la précision géométrique doit être indiquée lors de la création d'une donnée et être un standard, ce qui ne me semble pas être le cas.
  Si je me positionne en tant qu'utilisateur lambda, je fais ma zone en m'accrochant à des sommets. Si l'accroche est bonne, je ne vais pas me soucier du nombre de chiffres après la virgule... et pourtant c'est une règle que l'on apprend à l'école en math et physique...
  En résumé, on fait (trop) confiance aux outils

  Je viens de recevoir une grille de points d'altitude avec un pas de 4m. Je ne sais pas comment il à été créé, mais elle a subit une reprojection pour notre système. En X et Y, il y a 8 chiffres après la virgule et 2 en Z.

  Les données proviennent tant de la DAO (AutoCAD) que du SIG (Parcelle) ou de point GPS direct. L'assemblage des données se fait par différents logiciels (suivant qui est la personne réalisant le transfert). Du coup, à mon avis, cela se retrouve dans la donnée terminale.
  
  Plus particulièrement pour les points qui sont identiques suivant la précision, c'est à mon avis un problème lié à deux points :
  - L'accroche du point lorsque nous voulons séparer une entité. Le(s) logiciel(s) ne prend/prennent pas la coordonnée du point d'accroche mais celle du clic proche de ce point.
  - Le non respect de la topologie de certaines données, pour ma part les parcelles. Puisque comme je te l'avais expliqué, nos parcelles peuvent se superposer ou il peut y avoir des trous (l'erreur est minime, mais quand même), du coup cela peut donner lors de copier/coller des points également identique.

Donc ce que je dis n'est pas totalement farfelu, hein ??


Et ce n'est pas que je pousse un coup de gueule, ou que je n'y connais rien...

Pour les besoins d'un SIG classique, on va dire que nous sommes décimétrique, et donc une précision de 1e-6° !

Tout à fait, c'est bien ce que je dis dans mon message..

Donc pour les besoins d'un SIG classiques, nos coordonnées devraient donc au moins être exprimés au centimètres, et donc en degré décimal 1E-7°.

AJOUTER une décimale ne changera rien du tout si cette décimale n'a pas de sens...

Avoir la bordure de l'asphalte d'une route au millimètre, ou même au centimètre près, est absurde : le camion qui épand le goudron, le rouleau-compresseur, et le gars avec son rateau n'a pas cette précision. A quoi peut donc servir une précision comme ça ? Un pneu de voiture ou de vélo est plus large, et il suffit d'un caillou mal enrobé dans le goudron pour qu'à la première pluie la bordure ait changé.

De même avoir la bordure d'un champ, d'un terrain, ou d'un batiment, ou le délimité d'un sentier au millimètre est stupide. Juste le ciment sur le mur est plus gros...

De même que avoir la côte française au millimètre, si tu n'es pas en train d'étudier le déplacement de telle ou telle dune particulière, bourrée de capteurs..

Passer de 12 à 5 chiffres, je travaillerais plutôt raisonnablement à 7 chiffres après la virgule pour ne pas avoir tous mes utilisateurs sur le dos.

Sans doute, mais c'est justement tout le sens de mon post

Tu es juste en train de te plaindre que tu ne travailles pas avec un SIG topologique (GRASS par exemple), ou bien qu'il n'y a pas de validation topologique dans le cas d'un SIG non topologique (ESRI par exemple). Ne confondons pas les problèmes !

Moi je ne me plains pas du tout.. je me m'en sers pas..

Simplement je lis les docs, et les forums et FAQ, et je constate les problèmes : il y a des questions presque tous les jours sur les auto-intersections, et quand j'ai vu les données (exportées) par ce Service - qui m'a confirmé que c'était bien en interne la même chose chez eux - je regarde ce que ça donne, c'est tout...

Une ligne apparemment droite, par exemple, contient plus de 20 points, dont plusieurs séparés par 10^-13.... ou 10^-12.... Et donc boucle, s'auto-intersecte, etc... et contient nettement plus de points que nécessaire.

Une bibliothèque grand nombre pour un SIG, absurde en effet. Tu as des exemples en SIG ?

J'ai la flemme de chercher, mais il y e eu des posts sur le forum Algo :peut-être que c'était pour l'aéronautique, mais c'est une tendance lourde que j'ai vu aussi sur le forum C...

Je confirme les dire de Jérome, tu passes assez aisément en dessous de 10 cm de précision avec certaines techniques (différentiel, etc.)

Je n'ai pas dit le contraire... Je dis juste qu'en dessous du millimètre, c'est absurde, et souvent en dessous du décimètre.

Les coordonnées sont représentées avec des doubles en base de données

Et alors ???

2.4 est un flottant qui peut-être en interne représenté comme un double, mais le stocker comme 2.4333333333333333333333 est ET absurde ET faux... Soit on lui met des zéro ("zero-padding") soit on le tronque à la précision.

Alors si tu passes sur un 64 bits, tu n'auras plus la même base qu'avec un 32 ??? Et pourtant tes mesures initiales n'ont pas changé ...

Encore une fois, ce n'est pas l'utlisation, c'est le stockage... Et en plus les erreurs s'accumulent...

De nombreux SIG travaillent sur des grilles.

Oui et ?

Comment si on fait 3.5 + 3.6 on peut arriver à 7.123 ????

Ce que je dis c'est que la précision de la fin de l'opération ne doit pas être supérieure à 1 chiffre de plus que la préciison d'entrée suivant le cas :

3.5+3.6 / 2 = 3.55
3.5 + 3.6 = 7.1

Essaye peut-être de comprendre l'approche de la bibliothèque CGAL avec ses "exact predicate exact construction kernel"

T'en fais pas, on m'a déjà fait le coup, et je trouve cela tout aussi aberrant de toutes façons...

Je suis astrophysicien à la base.. Si je calcule la taille de l'Univers en Angstrom je n'ai que 21 (ou 24 je me souviens plus) décimales. Sachant que j'ai une erreur de 100 millions d'annès-lumières, combien dois-je utiliser de décimales réllement ??

C'est tout le problème de l'utilisation de ces biblothèques. Le problème est théorique, mais pour l'instant je n'ai pas vu un seul cas où l'appliquer avait un sens...

Si, il y a un seul cas.. La cryptographie.

En dehors de ça, non...

(d'ailleurs c'était pas toi, l'exemple sur l'aéronautique ??)

[Jérôme_C]

Tout d'abord, je suis ravi que les approximations que je remarquais n'étaient qu'une concision du discours. Je suis désolé si j'ai été blessant dans mes remarques. Loin de moi de prendre pour un souviron pour un idiot qui sort des infos de n'importe où, je dis juste que des expériences particulières sont prises pour tirer une conclusion par forcément totalement pertinente.

Dans le fond je suis vraiment d'accord avec ce message, c'est juste que dans le détail je remets en question la fantastique conclusion :

une part en tant qu'utilisateurs vous diminueriez, avec les 2 effets cumulés, la taille de vos Bases de Données par 75%, et donc doubleriez les vitesses de calcul et/ou d'affichage, en ayant beaucoup moins de problèmes du style auto-intersections ou autres du même style.

Non, j'avais mes propres données, créées depuis plus de 15 ans, et un Service de Géomatique d'une très grande ville française m'en a fourni tout à fait offciellement.

Y compris après vérification chez eux, ce sont donc des données 1) telles qu'elles sont effectivement stockées, et 2) avec les explications du Responsable, y compris alors qu'en entrée des SIGs utilisés il donnait la vraie précision.

Je ne me serais pas permis d'émettre cette remarque auterement..

N'était pas là le sens de ma remarque. Bien sûr que vos remarques sur l'état des données était fondées.

J'ergotais sur le caractère métrique alors qu'on peut avoir du centimétrique facilement dans certains cas, et le millimètre n'est pas absurde. Et donc un rapport de 1 à 1000. Je remarque que tu ne discutes pas cela, que c'est bien dans le sub-millimétrique que le problème se pose. (Et encore même si intégré dans un SIG c'est plutôt rare, des données topographiques sub-millimétriques, ça peut se voir tous les jours dans certaines milieux)

au grand max... Donc au lieu de 2+1+13 caractères par point, seulement 2+1+6... Soit 8 au lieu de 16 par coordonnée... D'après mes calculs ça fait bien environ 50% non ????

2+1+6 = 9, soit 56 % contre 13 caractères, 60 % contre 12 caractères.

Et avec le millimétrique qui n'est pas si absurde, soit 9 caractères, on ne se trouve qu'avec une taille de 80 % contre 12 caractères (ou 75 % contre 13 caractères).

Oui si on est en métrique, qu'on utilise que 5 caractères après la virgule (résolution en latitude de 4 m), on a bien 8 contre 16, et donc ces 50 % de différence. Mais dès qu'on change raisonnablement nos hypothèses, le gain n'est pas si flagrant.

Ma critique de votre message est surtout sur ce point.

Quand je parle de gain en place, c'est parce que stocker un batiment à l'angstrom près, c'est idiot..

Non, tu ne trouves pas ça idiot ??

C'est idiot l'angstrom pour des coordonnées géographiques. C'est moi qui est sorti cette unité car j'ai déjà vu 15 chiffres après la virgule. Dans votre message vous restez sur 12 à 14 chiffres après la virgule, un rapport 1000, du micromètre et plus le nanomètre...

Au micromètre un bâtiment, ça reste idiot, pas la peine d'exagérer inutilement.


D'un côté tu évoques des données marines sur des très grandes distances, où il y a sur l'étendue considérée des altérations linéaires qui pourraient ne pas être négligeable, un système de projection unique ne doit pas être facile à imposer. Oui le système d'information travaillant en coordonnées géographiques est loin d'être idiot.

D'un autre côté, tu évoques la France, le pays de 1000 km de côté avec 10 systèmes de coordonnées projetés applicables légalement, et pour l'application d'une grande ville française. Dans ce dernier cas, la parcelle à 1 cm près n'est pas idiot (oui physiquement ce n'est pas grand chose, mais vu le prix du mètre carré de parcelle, il y a des procès pour un dépassement d'un centimètre). Et surtout le travail dans un seul système de coordonnées projetés n'est surement pas idiot.


Deux cas différents, pas les mêmes ordres de grandeurs, pas la peine de faire d'amalgame.


Surtout, oui c'est idiot, mais est-ce si important ? Les 50 % annoncés sont à prendre avec des pincettes. Oui on gagne toujours, mais c'est un peu moins impressionnant.

AJOUTER une décimale ne changera rien du tout si cette décimale n'a pas de sens...

Avoir la bordure de l'asphalte d'une route au millimètre, ou même au centimètre près, est absurde : le camion qui épand le goudron, le rouleau-compresseur, et le gars avec son rateau n'a pas cette précision. A quoi peut donc servir une précision comme ça ? Un pneu de voiture ou de vélo est plus large, et il suffit d'un caillou mal enrobé dans le goudron pour qu'à la première pluie la bordure ait changé.

De même avoir la bordure d'un champ, d'un terrain, ou d'un batiment au millimètre est stupide. Juste le ciment sur le mur est plus gros...

Quand on parle de la précision de mesure, ce n'est pas exactement une variation continue, instantanée et aléatoire autour de la valeur exacte dans la plage de précision données. Et prendre quatre mesures différentes pour être deux fois plus précis, c'est une réalité. Mais faire la moyenne de valeurs tronquées, ça ne va pas donner grand chose. Tout dépend des données représentées.

Et puis certains engins de travaux publics automatiques sont au centimètre près. Pour étaler l'enrobé sur un coin de rue, ce n'est pas souvent utile, mais quand il s'agit d'étaler des kilomètres d'autoroute ou de voie rapide, c'est utile d'avoir ces précisions sur l'enrobé, ça fait quelques économies.

Aussi, si à cause d'un arrondi un peu trop fort des linéaires supposés être distincts se trouvent intersectés (ou simplement confondus), le système d'information commet une faute. Certes la précision de position du linéaire (câble EDF, téléphone par exemple) est décimétrique, mais il y a une topologie à respecter que permet l'ajout d'une décimale supplémentaire.

Et puis je répète mon exemple d'image raster, où un câble de cinq centimètres de diamètres est visible sur une image de 50 cm de résolution, voir bien plus. Et le câble peut être positionné sur des fractions de pixels.

Ce que je dis c'est que la précision de la fin de l'opération ne doit pas être supérieure à 1 chiffre de plus que la préciison d'entrée :

Je vois qu'en fait nous sommes d'accord.

Une ligne apparemment droite, par exemple, contient plus de 20 points, dont plusieurs séparés par 10-13.... ou 10-12.... Et donc boucle, s'auto-intersecte, etc... et contient nettement plus de points que nécessaire.

Des objets vectoriels avec une densité de points 10, 100 ou 1000 fois supérieures à la précision de saisie, c'est absurde. Avoir une troncature à la précision des données évitera peut-être des auto-intersections, mais il y aura d'autres problèmes, 20 sommets à la même position pour une ligne, c'est tout aussi absurde, et je me demande s'il n'y a pas non plus des problèmes de topologie dans ce cas.


Les auto-intersections sont une plaie, imposer une grille améliore les choses, mais ce n'est pas la panacée.

2.4 est un flottant qui peut-être en interne représenté comme un double, mais le stocker comme 2.4333333333333333333333 est ET absurde ET faux... Soit on lui met des zéro ("zero-padding") soit on le tronque à la précision.

Alors si tu passes sur un 64 bits, tu n'auras plus la même base qu'avec un 32 ??? Et pourtant tes mesures initiales n'ont pas changé ...

Mais si ça n'a pas d'importance, pourquoi y accorder de l'importance ?

Le zéro-padding est autant arbitraire que le trois-padding, ou le huit-six-un-padding.



Tous ces logiciels qui sortent des informations géographiques ne demandent pas forcément des informations très détaillées. Par défaut, vaut mieux donner plus d'information que pas assez.

Bien sûr, vaut mieux optimiser, avoir un stockage adéquat à nos données, mais c'est tellement au cas par cas que je trouve préférable le trop de chiffres significatifs que pas assez.

Bien sûr, éviter les auto-intersections c'est préférable, mais si c'était aussi simplement qu'arrondir à la précision des données, il suffirait d'effectuer ce traitement a posteriori pour se débarrasser de tous les auto-intersections. Or si vraiment c'était le cas, ça se saurait, on s’embêterait bien moins à traiter ces données sans topologie.


Les choses idiotes, il y en a des tas. Quand supprimer la possibilité de réaliser ces choses idiotes n'entraine aucune régression dans l'utilisation du logiciel / système, il ne faut pas hésiter, ça fait partie de l'ergonomie. Par contre, les régressions issues des bonnes intentions, c'est l'enfer de la maintenance logicielle.

[souviron34]

Dans le fond je suis vraiment d'accord avec ce message, c'est juste que dans le détail je remets en question la fantastique conclusion :

Que mes chiffres soient approximés, j'en conviens mais c'est quand même un gain non négligeable - même 30% quand on parle en téra-octets.

De même en vitesse de calcul/d'affichage si on diminue le nombre de points admettons par 20%.

Et finalement en termes d'artefacts et de corrections d'effets indésirables - comme le sont les auto-intersections....

C'était juste le sens de mon post . C'est pour ça que je l'avais initulé "Remarques"...

D'un autre côté, tu évoques la France, le pays de 1000 km de côté avec 10 systèmes de coordonnées projetés applicables légalement, et pour l'application d'une grande ville française. Dans ce dernier cas, la parcelle à 1 cm près n'est pas idiot (oui physiquement ce n'est pas grand chose, mais vu le prix du mètre carré de parcelle, il y a des procès pour un dépassement d'un centimètre).
...
Deux cas différents, pas les mêmes ordres de grandeurs, pas la peine de faire d'amalgame.
...
Surtout, oui c'est idiot, mais est-ce si important ? Les 50 % annoncés sont à prendre avec des pincettes. Oui on gagne toujours, mais c'est un peu moins impressionnant.

Encore une fois, ce n'est pas sur les gains en tant que tels - c'est un à-côté qui est simplement un (parfois gros) bonus...

C'est sur le principe et le sens ... La physique et les maths sous-jacents..

Un des posts cités sur le forum Algo , il y a 3 ou 4 ans, donnait par exemple la ville de Marseille à 12 chifres... Qu'est-ce que ça veut dire ????

Comme le dit mon interlocuteur dans son message :"on se fie trop aux outils"

Ce que cela veut dire, et c'était le sens de mon message, c'est que on utilise de plus en plus des choses toutes faites en oubliant la physique et donc la signifcation et l'ordre de grandeur de ce qu'on manipule...

Quand on parle de la précision de mesure, ce n'est pas exactement une variation continue, instantanée et aléatoire autour de la valeur exacte dans la plage de précision données. Et prendre quatre mesures différentes pour être deux fois plus précis, c'est une réalité. Mais faire la moyenne de valeurs tronquées, ça ne va pas donner grand chose. Tout dépend des données représentées.

Nous sommes bien d'accord. Sauf que là en l'occurence rien n'indique dans un fichier qu'il faut faire la moyenne... Et le nombre des points n'est pas divisible par 4, ce n'est donc pas sytématique.. C'est là où je pose la question, c'est tout..

Mais il y a - et c'était mon point - une question de bon sens. Même si on obtient une précision millimétrique, a-t-elle un sens ????????

Je vois qu'en fait nous sommes d'accord.

Sans doute

Mais ça n'était pas clair du tout d'après ton post hier...

Le zéro-padding est autant arbitraire que le trois-padding, ou le huit-six-un-padding.

Pas vraiment, non, puisqu'il n'introduit pas d'effets de bords cumulatifs...

3.1 + 3.2

Si 3.1 est stocké comme 3.13222234455 et 3.2 comme 3.2432222222, ça donnera 3.4 en arrondi....

Ce que je voulais dire dans mon message, c'est que, que ce soit via l'écriture de données avec des décimales provenant d'un outil de mesure (style GPS) mais sans signifcation, ou que ce soit via l'écriture de données provenant d'un logiciel calculant en flottant, quel que soit le nombre de décimales utulisées dans le calcul, réellement bien moins ont lieu d'être stockées - ou, dit autrement, ont un sens...

Et visiblement d'après les tests faits cette notion n'est pas bien intégrée....

Par défaut, vaut mieux donner plus d'information que pas assez.

Oui SI ELLE EST VRAIE...

Mais lorsqu'on stocke un nombre initialement entré avec 2 chiffres après la virgule avec 8 à 10 chiffres, sur ces 8 à 10 environ 6 à 8 n'ont aucune signification, et sont simplement des artefacts de calculs / répartition des nombres dans la mantisse du nombre, suivant l'ordi et son nombre de bits... Ils n'ont aucun sens réel...

Admettons que l'on ait fait 15 opérations successives sur ces nombres à 2 chiffres en entrée. Si l'on a utilisé des doubles (sur un 32 bits) on aura donc 17 chiffres dans la mantisse... Dont 14 ne signfieront rien, à moins que ces opérations ne soient que des additions...

Les choses idiotes, il y en a des tas. Quand supprimer la possibilité de réaliser ces choses idiotes n'entraine aucune régression dans l'utilisation du logiciel / système, il ne faut pas hésiter, ça fait partie de l'ergonomie. Par contre, les régressions issues des bonnes intentions, c'est l'enfer de la maintenance logicielle.

J'essayais juste de faire prendre conscience du problème, qui visiblement n'est pas identifié par beaucoup de monde....


En gros : nous sommes limités par le sens de ce qu'on manipule, quel que soit la précision que une machine nous donne...

Si on te fais voir un film à 300 images/secondes, de toutes façons ton oeil n'en voit que 25 (ou 30)..... C'est tout...

Bien sûr, éviter les auto-intersections c'est préférable, mais si c'était aussi simplement qu'arrondir à la précision des données, il suffirait d'effectuer ce traitement a posteriori pour se débarrasser de tous les auto-intersections. Or si vraiment c'était le cas, ça se saurait, on s’embêterait bien moins à traiter ces données sans topologie.

J'ai publié un petit algo sur le sujet - simple et de bon gout - sur arXiv, dont je mettrais le lien dans le forum Algo vers la fin de l'été...

[Jérôme_C]

En gros : nous sommes limités par le sens de ce que on manipule, quel que soit la précision que une machine nous donne...

Si on te fais voir un film à 300 images/secondes, de toutes façons ton oeil n'en voit que 25 (ou 30)..... C'est tout...

Même un exemple comme cela est à prendre avec des pincettes, car si l'oeil peut voir 30 images différentes par secondes, ça ne signifie pas qu'il ne verra jamais une image présentée sur une durée inférieure d'1/30 de seconde.

Une impulsion lumineuse très brève dans l'obscurité est captée par l'oeil.

Encore une fois, ce n'est pas sur les gains en tant que tels - c'est un à-côté qui est simplement un (parfois gros) bonus...

C'est sur le principe et le sens ... La physique et les maths sous-jacents..

Malheureusement, si tu n'as pas une remarque précise digne de figurer dans une FAQ, comme "donnée GPS = 5 décimales" (dans tous les cas), la remarque n'est prise en compte que par les gens déjà sensibilisé.

Ce genre de post n'aura à mon avis quasiment aucun effet pour tous ceux qui vont venir avec un problème de données, ils continueront à copier / coller les coordonnées telles qu'elles apparaissent dans le SIG qu'ils ont configuré.

[souviron34]

Ce genre de post n'aura à mon avis quasiment aucun effet pour tous ceux qui vont venir avec un problème de données, ils continueront à copier / coller les coordonnées telles qu'elles apparaissent dans le SIG qu'ils ont configuré.

Possible...

Mais qui ne tente rien n'a rien...

J'ai hésité à le mettre dans Algo, ou dans le sous-forum portail IGN...

Je me souviens plus où j'ai mis mes coordonnées sur GeoRezo, j'essaierais d'y mettre un pointeur, et mon correspondant a compris et je pense déjà le mentionnera dans son milieu - qui est un des premiers concernés...

Mais visiblement, même dans ce milieu dont c'est pourtant et le métier, et pour beaucoup l'historique, comme il le disait, ce n'est pas très répandu....

[bretus]

Mais surtout quand je parle de 50%, c'est que au lieu de stocker :

45.2323232323223 2.22222222222222

On ne devrait stocker que

43.232323 2.222222

au grand max... Donc au lieu de 2+1+13 caractères par point, seulement 2+1+6... Soit 8 au lieu de 16 par coordonnée... D'après mes calculs ça fait bien environ 50% non ????

Vous faites bien de faire les calculs, mais ce sont des doubles spécifiés comme ayant 8 octets : Donc kiff-kiff! Je vous accorde les 50% quand on les représente en hexadécimal ceci dit

Après, par rapport à la précision des données, le plus grave n'est pas dans le stockage : Il est impossible de parler de topologie correcte sans définir la précision des données! (quand est-ce qu'on peut dire qu'un point est trop proche d'un segment sinon? que deux géométries sont suffisamment éloignée l'une de l'autre pour être distinctes?)

Après, la grille de saisie ne résout pas tout : Quand est-ce qu'on considère que des points sont alignés? Un angle de 0.000001 degré à un sens quand il sème la zizanie dans les traitements? L'outil doit peut-être faire le choix de supprimer les alignements et bousiller les partages de géométrie?

Tout ceci : ça ne se règle pas dans le SIG doté d'outils que les utilisateurs n'activent pas, mais dans les specs sur la donnée et les contrôles sur cette dernière!

Avoir la bordure de l'asphalte d'une route au millimètre, ou même au centimètre près, est absurde : le camion qui épand le goudron, le rouleau-compresseur, et le gars avec son rateau n'a pas cette précision. A quoi peut donc servir une précision comme ça ? Un pneu de voiture ou de vélo est plus large, et il suffit d'un caillou mal enrobé dans le goudron pour qu'à la première pluie la bordure ait changé.

Mais il n'y a pas que ça dans les systèmes!

Vous croyez que ça a quelle précision les mesures aux tachéomètres sur des cibles dans un repère local? Vous croyez que ça sert à rien dans surveillance de bâtiment, le calibrage d'appareil photo, etc.?

De même avoir la bordure d'un champ, d'un terrain, ou d'un batiment, ou le délimité d'un sentier au millimètre est stupide. Juste le ciment sur le mur est plus gros...

De même que avoir la côte française au millimètre, si tu n'es pas en train d'étudier le déplacement de telle ou telle dune particulière, bourrée de capteurs..

Encore une fois, à qui la faute? Producteur de données ou éditeur de SIG?

T'en fais pas, on m'a déjà fait le coup, et je trouve cela tout aussi aberrant de toutes façons...

Mode autruche activé? Là, il me semble que vous partez du principe que ces approches sont aberrantes en refusant d'en comprendre les intérêts.

C'est tout le problème de l'utilisation de ces biblothèques. Le problème est théorique, mais pour l'instant je n'ai pas vu un seul cas où l'appliquer avait un sens...

C'est ça l'approche : Il n'y a pas de théorie simple possible sans qu'on puisse faire confiance à :

Des prédicats exacts :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// prédicat exact
if ( orientation(p,ab) == ON_BOUNDED_SIDE ){

}

Des constructions exactes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if ( orientation(intersection(ab,cd),ef) == ON_BOUNDED_SIDE ){

}

Du coup, quand ils tentent de répondre à ces deux éléments pour avoir un cadre théorique confortable dans les algorithmes, qu'ils limitent la casse sur les performances en évitant de faire des calculs en arithmétiques exactes quand la précision sur les flottants suffit : On ne les prend pas pour des c*ns aux approches aberrantes avant même de regarder ce qu'ils font...

[souviron34]

Vous faites bien de faire les calculs, mais ce sont des doubles spécifiés comme ayant 8 octets : Donc kiff-kiff!
Je vous accorde les 50% quand on les représente en hexadécimal ceci dit

Je ne parle pas (et n'ai jamais parlé) de stockage en mémoire, mais en fichier...

ECRIRE dans un fichier un chiffre à 13 décimales alors que la donnée en entrée n'en avait que 2 est tout simplement une aberration..

De même, de manière générale, écrire des données lat/lon avec plus de 6 ou 8 décimales est - mis à part quelques cas très particuliers ayant en général des outils et des senseurs dédiés - aberrant.

Et ça rabote une base de 50%

A mons que vous ne stockiez la base en binaire, ce qui n'est quand même pas très souvent le cas lors d'échanges, et relativement peu en interne quand même...

Après, par rapport à la précision des données, le plus grave n'est pas dans le stockage : Il est impossible de parler de topologie correcte sans définir la précision des données! (quand est-ce qu'on peut dire qu'un point est trop proche d'un segment sinon? que deux géométries sont suffisamment éloignée l'une de l'autre pour être distinctes?)

Mais justement, les remarques de mon interlocuteur donnent à penser que même en précisant la précision en entrée en sortie il obtient toujours entre 8 et 13 décimales....

Après, la grille de saisie ne résout pas tout : Quand est-ce qu'on considère que des points sont alignés? Un angle de 0.000001 degré à un sens quand il sème la zizanie dans les traitements? L'outil doit peut-être faire le choix de supprimer les alignements et bousiller les partages de géométrie?

Non il ne doit pas le faire....

Par contre, il ne doit pas inventer des données là où il n'y en a pas..

Et c'est pourtant ce qui est fait quand on ajoute des décimales à un nombre qui n'en contenait qu'un certain nombre......

Ou comme il le mentionne en "accrochant" un point, mais qui est pris avec toutes ces décimales internes alors que seules celles lues ont une réalité.

Tout ceci : ça ne se règle pas dans le SIG doté d'outils que les utilisateurs n'activent pas, mais dans les specs sur la donnée et les contrôles sur cette dernière!

Voir plus haut : visiblement il y a des cas où ça me marche pas....


[EDIT]

Vous croyez que ça a quelle précision les mesures aux tachéomètres sur des cibles dans un repère local? Vous croyez que ça sert à rien dans surveillance de bâtiment, le calibrage d'appareil photo, etc.?

Je ne sais pas du tout quelle précision les tachéomètres ont, mais une surveillance de batiment en dessous du mm alors qu'un grain de sable dans le ciment du mur fait 2 mm est absurde, c'est tout.... ça n'a pas de sens : ce n'est pas du traitement de signal où on cherche quelque chose dans un bruit.... Là c'est la définition spatiale du mur lui-même qui ne peut pas être physiquement en dessous....

C'est ce que je veux dire...

[/EDIT]

Encore une fois, à qui la faute? Producteur de données ou éditeur de SIG?

Où vois-tu que j'ai parlé de "faute" ?????

Je mentionne simplement un problème que visiblement certains outils "bypassent", que certains utilisateurs assument comme étant pris en compte, et dont d'autres utilisateurs n'imaginent même pas qu'il y a un souci à avoir 12 décimales....

J'ai intitulé mon post "Remarques"... Pas "bouh ces programmeurs"....

Mais visblement il y a "faute", ou plutôt comme on dirait en anglais "sloppiness" des 2 côtés....

Mode autruche activé? Là, il me semble que vous partez du principe que ces approches sont aberrantes en refusant d'en comprendre les intérêts.

J'avais déjà lu les exmplications de la bibliothèque. Je les comprend.

Je ne fais simplement que constater que je ne connais pas de cas où ce serait nécessaire, si on prend en compte l'échelle des phénomènes et une machine "normale" , même juste à 32 bits....

J'attend qu'on m'en montre un, mais au nombre de posts que je vois sur le forum Algo et sur le forum C - c'est surtout en premier trimestre, donc ça doit être un exo de cours - sur le sujet, je crois que c'est surtout un sujet de prédilection pour certains profs, et que ça a tendance à faire oublier - si ils l'ont appris - aux étudiants la notion d'ordre de grandeur et de mise à l'echelle....

Du coup, quand ils tentent de répondre à ces deux éléments pour avoir un cadre théorique confortable dans les algorithmes, qu'ils limitent la casse sur les performances en évitant de faire des calculs en arithmétiques exactes quand la précision sur les flottants suffit : On ne les prend pas pour des c*ns aux approches aberrantes avant même de regarder ce qu'ils font...

Je ne traite pass les auteurs de ces biblothèques de c.ns, je traite les utilisateurs qui s'en servent pour n"importe quoi d'ignorants des notions d'ordre de grandeur et de mise à l'échelle...

Si ces biblothèques ne servaient QUE à faire des mathématiques exactes SEULEMENT LA où c'est NECESSAIRE, leur popularité serait bien moindre que ce qu'elle est. Leur popularité et usage est bien un indicateur de la mauvaise utilisation de ces biblothèques, c'est tout...


Mais j'attend qu'on me fournisse un exemple tellement évident de leur usage naturel et répandu que je ne pourrais que m'incliner