Pour résumer tout ça, la précision nécessaire pour une précision décimtrique nécessite que toutes les coordonnées soient exprimables et calculables avec 10 chiffres significatifs (les mêmes 10 chiffres qu'on trouve dans un entier 32 bits, mais qu'on ne trouve pas dans un flottant 32 bits qui n'a QUE 7 chiffres significatifs)...
Le 25 mars 2012 03:34, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Mercator « sphérique », kesako ? Mercator c'est uniquement **cylindrique**. > > Tu dois confondre avec les projections corrigeant la latitude linéaire > pour rétablir les rapports de surface (comme si on avait un jeu très > fin de projections coniques successives). Pour la géodésie en France, > on n'utilise pas ce genre de projection, mais uniquement un jeu limité > de projections coniques pour corriger en partie les déformations de la > projection cylindrique de Mercator (donc aussi WGS84 qui n'utilise > qu'un seul cylindre et non plusieurs cônes selon les latitudes). > > La base OSM utilise une projection WGS84, basée sur une projection > cylindrique, mais **sans** correction non linéaire de la latitude, une > correction qui serait pourtant nécessaire pour conserver au moins les > surfaces (mais qui ne corrigerait pas pour autant les angles fortement > déformés près des pôles). > > L'interface cartographique d'OSM, en fait celel de son rendu (telle > que Mapnik), ne corrige pas cette projection de représentation, alors > qu'elle devrait être transformée en projection conique pour rétablir > les proportions et les angles: c'est bien pour ça que cette interface > ne permet pas d'afficher les latitudes de plus de 85 degrés (Nord ou > Sud), et que même au delà de 80 degrés, les distortions sont trop > beaucoup trop importantes (pas question de modéliser par exemple un > bâtiment rectangulaire dans cette projection WGS84, car le bâtiment > rectangulaire devient nécessairement un trapézoïde, affiché alors > nettement plus étroit dans la direction du pôle de l'hémisphère où ce > rectangle est situé). > > Il y a une raison à cela: c'est que le rendu se fait actuellement en > images bitmap, et que les navigateurs web ne savent pas encore prendre > en charge les déformations non linéaires de telles images qui seraient > pourtant nécessaires pour rétablie les proportions, les angles et les > surfaces, par triangulation selon le vecteur normal central de > visualisation de la carte: ce vecteur normal devant alors bouger > chaque fois qu'on se déplace en glissant la carte, il faudrait aussi > réajuster toutes les images (donc les redessiner). Les serveurs de > tuiles ne savent pas générer des tuiles bitmap réajustées pour des > projections arbitraires selon le vecteur normal d'observation. > > La solution serait d'avoir des tuiles en format vectoriel, le > navigateur s'occupant lui-même de recalculer les projections et donc > de redessiner aussi les POI et les routes. > > == NOTES == > > WGS84 a le défaut (mineur actuellement) de perdre sa précision selon > les coordonnées quand on s'éloigne du zéro degré (de longitude ou de > latitude), si on utilise une représentation en virgule flottante. Je > m'explique : > > Dans la base OSM la précision est limitée par l'utilisation de > flottants sur 32 bits, on n'a donc que 23 bits de précision. Chaque > fois qu'un angle est multiplié par 2, on perd 1 bit de précision : > > - de >=0° à < 1°, la précision représentable passe de la quasi > exactitude (précision infinitésimale ne dépendant que du plus petit > exposant de 2 représentable par le flottant) à la précision de 0,66 cm > (on stocke donc dans la base des bits de précision inutiles pour cet > intervalle angulaire). > > - de >=1° à <2°, la précision chute brutalement à 4,3 millièmes de > seconde d'arc, soit 1,32 cm (très bien, mais on n'est limité qu'à une > toute petite zone de 2 degrés de large de part et d'autre du méridien > de Greenwich et de part et d'autre de l'équateur, une zone de > l'Atlantique dans le golfe de Guinée) > > - de >=2° à <4°, elle est réduite à 2,65 cm > - de >=4° à <8°, elle est réduite à 5,30 cm > ... > - de >=64° à <128° (y compris les 90° de latitude pour les pôles), > elle n'est plus que 84,77 cm (2,75 centièmes de seconde d'arc) > - de >=128° à <256° (en fait seulement 180°, et seulement pour les > longitudes), la précision est seulement de 1,70 m (5,49 centièmes de > seconde d'arc) !! > > Autrement dit on est encore trop loin de la précision décimétrique > voulue qui n'est atteinte que sur une partie de la Terre proche de > l'équateur et proche du méridien de Greenwich. La base OSM a donc > seulement une précision à peine métrique. L'anomalie d'OSM (non liée à > la projection WGS84 elle-même) c'est d'avoir choisi la représentation > sous forme de flottants 32 bits, avec donc une précision **non > uniforme** pour sa projection WGS84. > > Si la base OSM (ainsi que son API exposant les valeurs stockées, et > les outils de modification comme JOSM) utilisait plutôt des entiers 32 > bits (dans toute leur étendue: les 32 bits couvrant exactement > l'étendue des longitudes ou des latitudes permises) plutôt que des > flottants 32 bits, on aurait offert une précision **uniforme** pour : > > - **toutes** les latitudes (de 0,931 milliardième de degré partout, > soit 9,31 cm partout dans la direction d'un méridien, toujours > meilleure que la représentation actuelle hormis un minuscule rectangle > de 9,31 cm de largeur centré sur le méridien de Greenwich), et > > - **toutes** les longitudes (une précision uniforme seulement deux > fois moindre, de 1,863 millliardièmes de degré, soit 18,63 cm partout > dans la direction d'un parallèle, là encore toujours meilleure que la > représentation actuelle hormis un minuscule rectangle de 18,63 cm de > hauteur centré sur l'équateur !! > > Sans changer l'API (même si le format de stockage dans la base est > modifié pour utiliser des entiers 32 bits au lieu des flottants 32 > bits, ce qui imposerait aussi des changements dans le code SQL > utilisant les extensions cartographiques, ou que la base en fait le > mentionne par une projection WGS84 seulement modifiée par un simple > facteur d'échelle), on peut toutefois exposant des flottants avec une > précision supérieure, même si la base ne stocke que des entiers 32 > bits, à condition que la base OSM expose les coordonnées de longitude > et latitude avec une précision du milliardième de degrés: il faut donc > que l'API permette neuf décimales pour les coordonnées échangées en > degrés. > > Le choix des flottants 32 bits dans la base OSM au lieu des entiers 32 > bits (quitte à ce que les calculs de changement de projection se > fassent avec des doubles 64 bits, ce qui n'est pas non plus un > problème), peut être encore plus gênant si on fait les calculs de > changements de projection avec des flottants 32 bits : la précision > actuelle, bien qu'insuffisante, ne sera conservée QUE si on effectue > tous les calculs de changement de projection (par exemple, une > transformation en projection conique pour rétablir les angles et > surfaces) qu'avec des doubles 64 bits, et sans arrondir les résultats > intermédiaires en flottants 32 bits. > > > Le 25 mars 2012 00:23, Cyrille Giquello <cyrill...@gmail.com> a écrit : >> Bonjour, >> >> Dans spatialite il n'y a pas le SRID 3857 pour le Mercator Sphérique, >> qui est la projection utilisée par OSM. J'en ai besoin pour convertir >> des points dans la projection utilisée par OSM. >> Je pose la question car je trouve ça étrange et je me dis que j'ai dû >> rater quelque chose. >> >> Merci >> -- >> Cyrille. >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
