<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 06/09/2019 05:42,
<a class="moz-txt-link-abbreviated" href="mailto:osm.sanspourriel@spamgourmet.com">osm.sanspourriel@spamgourmet.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:608b0ae8-de91-cfa8-d946-a72c2f25798e@gmx.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Le 06/09/2019 à 12:04, Stéphane Péneau - <a
class="moz-txt-link-abbreviated"
href="mailto:stephane.peneau@wanadoo.fr"
moz-do-not-send="true">stephane.peneau@wanadoo.fr</a> a
écrit :<br>
</p>
<blockquote type="cite"
cite="mid:5cfec039-bb60-db01-be17-7074e7ba3f65@wanadoo.fr">Le
06/09/2019 à 11:14, Eric SIBERT via Talk-fr a écrit : <br>
<blockquote type="cite">Pour le fond du problème, mon avis est
que OSM est un projet mondial et qu'il faut rester avec une
référence globale, à savoir WGS84 mais en précisant bien que
c'est dans sa réalisation actuelle. Les données dans des
références locales doivent alors être converties en
WGS84(réalisation actuelle). Quand il y a un changement de
réalisation de WGS84, il faut convertir les coordonnées dans
la base OSM de l'ancienne à la nouvelle réalisation de WGS84
(ou au moins le faire dans les zones où la dérive des plaques
est plus grande que l'incertitude sur les données sources du
coin). <br>
<br>
</blockquote>
Les nouvelles réalisations du WGS84 n'ont pas de rapport avec le
déplacement des plaques. <br>
<br>
Si entre 2 réalisations, ma plaque s'est déplacée de 10 mètres
(c'est un exemple irréaliste), transformer les coordonnées de
l'ancienne à la nouvelle réalisation ne corrigera pas le
décalage de 10 mètres. <br>
<br>
Stf <br>
</blockquote>
<p>Je suppose qu'Eric veut dire que les "anciennes" données
étaient de facto mettons en GDA94 et qu'elles doivent être
reprojetées en GDA2020.</p>
<p>Ce qui revient à dire qu'on travaille en coordonnées locales...</p>
<p>Jean-Yvon<br>
</p>
</blockquote>
<br>
<p>Merci pour vos réponses!</p>
<p>Petit complément, pour y voir plus clair :p (ça me fait des
nœuds dans la tête depuis quelques temps)<br>
</p>
<p>Imaginons que je transforme les données dans la dernière
réalisation du WGS84 (G1762). Cette réalisation date de 2013 et
est basée sur l'ITRF2008, qui se lock à l'époque 2005. Sachant que
la plaque polynésienne a bougé de 2m depuis le début du système
RGPF (en 93 à peu près) , ça nous fait un décalage déjà d'un peu
plus d'1m depuis 2005 (ça rejoint les 7cm/an de wikipédia). Donc
une simple reprojection dans la dernière réalisation du WGS84 me
parait pas suffisante. Il faudrait ajouter les translations de
plaques / associer à l'époque courante. Et la...imaginons que je
le fasse (et que je trouve les vrais bons paramètres.. :o) , qui
dans les collectivités locales et utilisateurs de la donnée qui en
ont besoin en référentiel local, va faire la bonne transformation
inverse? Notamment car la transfo de base WGS84 qu'on trouve dans
QGis et autres outils SIG (4326) est décalé du RGPF de 30 à 50cm
uniquement. Ca voudrait dire -toujours pour moi, je peux me
tromper- que si les gens font la transfo inverse avec cette
définition du WGS84 il seront dans les 1.5m à côté (de la
plaque!!).<br>
</p>
<p>Donc si on va plus loin et qu'on veut les données issues de
plusieurs contributeurs à différentes époques... Qui va vraiment
reprojeter en récupérant les époques des dates de contribution?
J'ai des grosgros doutes la dessus. Après yen a qui diront qu'on
n'a pas besoin de ce niveau de précision, mais pour moi c'est un
sujet et surtout l'intérêt de garder la précision des données de
base. Ce serait dommage de perdre du décimètre de précision pour
des questions de projection.<br>
</p>
<p>Mon autre problème pour simplifier les choses, ici en Polynésie
française le système local (RGPF) est basé sur l'ITRF92 mais il ya
des différences en local en fonction des iles (toutes les iles ne
sont pas directement associées à l'itrf 92)</p>
<p>Après je suis daccord avec toi Eric, que ce serait mieux de
rester dans un système global commun, mais la c'est comme si on en
a tout pleins avec toutes les époques du WGS84. Donc c'est pas bon
pour moi non plus.<br>
</p>
<p>Donc pourquoi pas rester en local? On pourrait avoir une base de
données de systèmes locaux utilisée dans OSM, ça me paraîtrait
plus juste, et moins source d'erreurs. Les applis n'auraient "<i>qu</i>"'à
récupérer les données et les reprojeter en fonction de la zone ou
l'on se trouve, l'époque... \o/<br>
</p>
<p>Ensuite il y a quelque chose que je ne comprends pas, c'est la
relation entre le systeme wgs84 dispo sous qgis et la dernière
révision du wgs84... je vois pas le lien, je comprends pas de
quelle révision on parle dans qgis... :/ <br>
</p>
@+
<blockquote type="cite"
cite="mid:608b0ae8-de91-cfa8-d946-a72c2f25798e@gmx.net">
<p> </p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Talk-fr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Violaine_Do</pre>
</body>
</html>