Trop de décimales pour rien

[solsticedhiver]

Bonjour, Dans les geojson que vous proposez, les coordonnées lat/lon ont jusqu'à 13 décimales !

Je suppose que cela vient de l'import des données de l'IGN mais cela n'a aucun intérêt.

Pour info, une 6ème décimale en latitude donne une précision de l'ordre de 78mm à 45° de latitude; cela veut dire que 13 décimales c'est obtenir une précision de l'ordre du nanomètre voire plus.

En passant à 6 décimales au lieu de 12 ou 13, j'ai fait passer un de vos fichiers de 3.7Mo à 2.4Mo ! J'ai utilisé un simple script python

import geojson

f = open('communes-bretagne.geojson')
g = geojson.loads(f.read())
f.close()

for f in g['features']:
    for u in f['geometry']['coordinates']:
        for v in u:
            try:
                v[0] = float('{:.6f}'.format(v[0]))
                v[1] = float('{:.6f}'.format(v[1]))
            except ValueError:
                for w in v:
                    w[0] = float('{:.6f}'.format(w[0]))
                    w[1] = float('{:.6f}'.format(w[1]))

f = open('communes-bretagne.min.geojson','w')
f.write(geojson.dumps(g).replace(', ',',').replace(': ',':'))
f.close()

cf: https://en.wikipedia.org/wiki/Decimal_degrees désolé c'est en anglais

[gregoiredavid]

Bonjour,

Merci pour ce message @solsticedhiver c'est une très bonne remarque. Toute la difficulté dans ce domaine est que le degré de précision pertinent dépend de chaque projet. L'idée de base du repo était donc de fournir les données les plus précises possibles en laissant à chacun le soin de les simplifier plus ou moins drastiquement (et selon la méthode la plus adaptée) en fonction de ses propres besoins.

Du coups les fichiers sont très lourds, et inutilement précis dans 99% des cas, j'en suis bien conscient. Surtout, ils ne sont pas réellement utilisables "out of the box" comme on pourrait s'y attendre, il faut en passer par une phase de simplification qui n'est pas toujours triviale, via un script comme le vôtre ou d'autres outils (gdal, mapshaper, etc...).

J'ai changé de logique avec la dernière version, en allégeant les fichiers de la branche master et en conservant les fichiers "détaillés" dans une branche séparée. J'ai commencé ce travail "d'allégement" par la simplification des tracés qui permet les économies les plus substantielles et qui est en même temps la plus délicate du fait des nombreuses méthodes possibles et des risques d'incohérences. Il reste effectivement un important "gisement" de simplification dans la limitation du nombre de chiffres après la virgule, autour de 6 il semble effectivement qu'on reste pertinent pour la plupart des cas d'usage.

Je garde l'issue ouverte jusqu'à la prochaine mise à jour. Merci encore !

[DavidBruant]

L'idée de base du repo était donc de fournir les données les plus précises possibles

Cet objectif est noble, mais il pose quand même la question de la précision d'origine. Il est surprenant que la précision d'origine soit au nanomètre. Si j'ai bien compris les données de ce repo viennent de IGN / Geofla. Quelle est leur méthodologie de tracé de référence ? Quelle est leur intention de précision ? (je viens de lire pas mal de docs sur leur site, je n'ai pas trouvé d'info)

Si leur méthode de génération de tracé est un humain qui trace des lignes sur une carte à une échelle où, par exemple, un pixel (granularité minimum d'un humain dessinant sur un écran) vaut 10cm, alors toutes les décimales de précision supplémentaires sont des artefacts générés par un algorithme d'export. Ce qui signifierait que ces décimales sont plus ou moins aléatoires de manière effective et transmettre cette précision n'a pas grand sens.

Celà dit, ce que ça signifie vraiment, c'est que la précision devrait être documentée et/ou corrigée à la source, pas dans ce repo.

[gregoiredavid]

Entièrement d'accord @DavidBruant , je voulais dire : "les données les plus fidèles possibles à la source officielle" (l'IGN) et non pas les plus précises possibles "dans l'absolu". Dans l'absolu justement, détailler jusqu'au nanomètre une frontière entre deux communes paraît assez artificiel, je suis d'accord.

[solsticedhiver]

@gregoiredavid je comprends bien votre réticence voire peur à changer la précision des données après l'import à la source.

Mais on ne demande pas la sacro-sainte précision de l'IGN qui ne correspond d'ailleurs à rien.

Cette extrême précision n'a pas grand sens. Quelque soit le projet. Il faut savoir interpréter les données et la précision vient toujours avec une marge d'erreur.

J'ai creusé un peu les choses parce que je trouvais le fichier avec les tracés simplifiés inutilisable parce que trop simplifié. Alors qu'en enlevant des décimales sans perdre en précision, on fait chuter la taille des fichiers

Je ne vois pas pourquoi c'est choquant de tomber des décimales sans perdre en précision alors que ça ne vous dérange pas de fournir des tracés simplifiés ?

De plus, le standard GeoJSON défini dans la RFC 7946 recommande 6 décimales

11.2. Coordinate Precision

The size of a GeoJSON text in bytes is a major interoperability consideration, and precision of coordinate values has a large impact on the size of texts. A GeoJSON text containing many detailed Polygons can be inflated almost by a factor of two by increasing coordinate precision from 6 to 15 decimal places. For geographic coordinates with units of degrees, 6 decimal places (a default common in, e.g., sprintf) amounts to about 10 centimeters, a precision well within that of current GPS systems. Implementations should consider the cost of using a greater precision than necessary.

Furthermore, the WGS 84 [WGS84] datum is a relatively coarse approximation of the geoid, with the height varying by up to 5 m (but generally between 2 and 3 meters) higher or lower relative to a surface parallel to Earth's mean sea level.

[gregoiredavid]

@solsticedhiver aucune réticence de ma part, je suis convaincu ! Je comptais faire la mise à jour dès que possible et en profiter pour ajuster la simplification des tracés.

Merci encore !