[OSM-talk-fr] spatialite et osm -> EPSG:900913 alias du EPSG:3857

Philippe Verdy verdy_p at wanadoo.fr
Dim 25 Mar 01:34:16 UTC 2012


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 <cyrille37 at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr




Plus d'informations sur la liste de diffusion Talk-fr