Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Christian Quest]

Je viens de tomber sur un blog dédié à rtklib...
https://rtklibexplorer.wordpress.com/

Bonne lecture !

Le 30 mars 2016 à 14:27, Christian Quest  a écrit :

> Ce n'est pas un repère de nivellement, mais une borne en granit des années
> 50.
> En principe le X/Y est ok à 10cm.
>
> Voici celle que je vais allez voir:
> http://geodesie.ign.fr/fiches/pdf/8922802.pdf
>
> Facile, d'accès, bien dégagée, récente... et faisant partie du réseau de
> base. Tout pour plaire !
>
>
> Le 30 mars 2016 à 12:32, Frédéric Rodrigo  a
> écrit :
>
>> Le 29/03/2016 22:43, Christian Quest a écrit :
>>
>>> Je vais mettre au propre tout ça pour le wiki... en fait l faut que je
>>> reparte de zéro, puis étape par étape.
>>>
>>> Sur le graphe, la trace verte correspond aux solutions en "float", puis
>>> quand ça passe en "fix" c'est le point à droite au milieu.
>>>
>>> Tant que je ne fournit pas de données de correction cohérents, ça reste
>>> en "simple", c'est à dire ce qui sort du GPS.
>>>
>>>
>>> L'altitude est très stable elle aussi (stable à 1cm près).
>>> La borne IGN ne semble pas contre pas à son emplacement officiel... avec
>>> 2,4m d'écart.
>>>
>> Je suppose que c'est du nivellement ?
>> Les borne de nivellement sont bien calées en élévation, mais pas en x/y,
>> et inversement pour les géodésiques.
>>
>> Frédéric.
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Adrian]

J'ai l'impression que très peu des OSMeurs savent que les positions WGS84 
changent d'une année à l'autre. Le déplacement est de 25mm par an (au 
millimètre près). Ça fait déjà 25cm pendant les dix années d'OSM. C'est à cause 
du mouvement de la plaque tectonique européenne.

Ce changement ne conviendrait pas à ceux qui gèrent le Cadastre, ni aux agences 
nationales de la cartographie comme l'IGN. Donc les agences européennes ont 
fait un accord sur le système ETRS. Elles ont pris les coordonnées WGS84 telles 
qu'elles étaient au 1er janvier 1989. Depuis, les coordonnées ETRS suivent le 
mouvement de la plaque tectonique. Ce qui fait que la différence entre WGS84 et 
ETRS est maintenant presque 70cm.

La version officielle française de ETRS est RGF93. Les fiches IGN donnent 
l'impression que WGS84 et RGF93 sont la même chose mais ce n'est pas vrai. Les 
fiches IGN sont exprimées en RGF93. Comme ça, les chiffres ne changent pas au 
fil du temps. Le Cadastre, quand il est de bonne qualité, est calé sur RGF93. 
Donc OSM en France est forcément calé aussi sur RGF93. Moi aussi, j'ai un GPS 
de haute performance (u-blox NEO-7P avec PPP, pas RTK), et il a fallu déplacer 
les traces 50cm vers l'ouest et 40cm vers le sud pour accorder avec le Cadastre.

Je crois que personne qui a à faire avec OSM, veut penser comment prendre en 
compte le mouvement des plaques tectoniques.

Bien entendu, 70cm n'explique pas un écart de 2,4m. Mais il est clair qu'il y a 
besoin de savoir quelle est la référence des corrections. La référence du 
résultat sera la même que la référence des corrections. Dans le cas de mon 
NEO-7P, les corrections viennent des satellites EGNOS, et la référence est 
ITRF2011 (le même que WGS84 à quelques centimètres près).

L'altitude est toute autre chose parce qu'il y a l'ellipsoïde, puis il y a un 
modèle du géoïde, puis il y a le zéro de l'IGN.

J'ai acheté le NEO-7P chez u-blox https://www.u-blox.com/en/product/evk-7 J'ai 
mis le GPS en mode PPP (positionnement précis des points). L'inconvénient 
principal est qu'il y a besoin d'une bonne vue du ciel pour obtenir la 
meilleure précision, surtout il y a besoin de voir au moins un des satellites 
EGNOS. Ceux-ci sont en orbite géostationnaire, donc ils sont vers le sud à une 
hauteur d'environ 35°. L'avantage est que le récepteur est autonome.

Comme antenne, j'ai utilisé le Tallysman TW2710 acheté chez Digi-Key. Je trouve 
cette antenne (et le TW2410) très bonne, elle est très sensible et elle rejette 
très bien les échos à un nombre impair de reflets. On dit que l'antenne marche 
mieux montée sur un disque en métal d'un diamètre de 10cm 
https://www.optimalsystem.de/os.aspx?x=4113 et c'est vrai - j'ai vérifié. 
L'antenne est montée par un aimant très fort, qui va démagnétiser les pistes 
magnétiques des cartes bancaires et des tickets de métro, et qui va magnétiser, 
même peut-être détruire les boussoles électroniques comme dans les smartphones. 
Je conseillerais d'acheter la version non-magnétique de l'antenne, avec NM dans 
le numéro du modèle. Celle-ci est montée avec des vis d'un type américain; ce 
sont les mêmes vis que celles employées pour monter les disques durs 3,5 pouces.

Avec une bonne vue du ciel, j'ai obtenu un ECP (CEP en anglais) de 35cm. Et les 
traces sont belles.

Adrian

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Multipolygons cassés ?

[Philippe Verdy]

Attention le rendu ne se fait pas toujours immédiatement (ou pas sur tous
les niveaux de zooms en même temps).
Je ne vois pas de problème actuellement dans le rendu, il y a bien les
champs et forêts, même sans regarder le détail des relations.

Si tu ne vois toujours rien, c'est peut-être un problème de cache de ton
navigateur (ton PC est-il passé correctement à l'heure d'été? Est-il
configuré dans le bon fuseau horaire? Est-il à la bonne date? Cela peut
provoquer des problèmes de persistance inattendue des anciennes données que
ton navigateur ne va pas recharger)
Si tu n'arrives pas à voir les changements, et si ton cache est corrompu,
dans ce cas vide ton cache.

Le 30 mars 2016 à 13:43,  a écrit :

> Bonjour,
>
> Hier j'ai dû casser quelque chose au niveau des multipolygons autour de
> Tigeaux, mais impossible de retrouver mon erreur...
> http://www.openstreetmap.org/#map=14/48.8273/2.9020
> Mes tentatives de correction n'ont pas suffi.
>
> Les polygones ont l'air continus, avec des outer et des inner, mais rien
> n'y fait, le rendu de la page principale fournit toujours une zone bien
> grise à la place de la forêt et des champs.
> https://www.openstreetmap.org/relation/1728908
> https://www.openstreetmap.org/relation/1728914
> https://www.openstreetmap.org/relation/2001400
>
> Pouvez-vous SVP vérifier et me dire l'erreur que je n'ai pas identifié ?
> Par la même occasion, des astuces pour valider ce genre de configurations
> (outils online) ? http://ra.osmsurround.org/analyzeRelation ne fournit
> pas de réponse (pas claire en tout cas) à mon problème.
>
> Merci,
> Teuxe
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Christian Quest]

Ce n'est pas un repère de nivellement, mais une borne en granit des années
50.
En principe le X/Y est ok à 10cm.

Voici celle que je vais allez voir:
http://geodesie.ign.fr/fiches/pdf/8922802.pdf

Facile, d'accès, bien dégagée, récente... et faisant partie du réseau de
base. Tout pour plaire !


Le 30 mars 2016 à 12:32, Frédéric Rodrigo  a écrit :

> Le 29/03/2016 22:43, Christian Quest a écrit :
>
>> Je vais mettre au propre tout ça pour le wiki... en fait l faut que je
>> reparte de zéro, puis étape par étape.
>>
>> Sur le graphe, la trace verte correspond aux solutions en "float", puis
>> quand ça passe en "fix" c'est le point à droite au milieu.
>>
>> Tant que je ne fournit pas de données de correction cohérents, ça reste
>> en "simple", c'est à dire ce qui sort du GPS.
>>
>>
>> L'altitude est très stable elle aussi (stable à 1cm près).
>> La borne IGN ne semble pas contre pas à son emplacement officiel... avec
>> 2,4m d'écart.
>>
> Je suppose que c'est du nivellement ?
> Les borne de nivellement sont bien calées en élévation, mais pas en x/y,
> et inversement pour les géodésiques.
>
> Frédéric.
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Multipolygons cassés ?

[teuxe]

Bonjour,

Hier j'ai dû casser quelque chose au niveau des multipolygons autour de 
Tigeaux, mais impossible de retrouver mon erreur...
http://www.openstreetmap.org/#map=14/48.8273/2.9020
Mes tentatives de correction n'ont pas suffi.

Les polygones ont l'air continus, avec des outer et des inner, mais rien n'y 
fait, le rendu de la page principale fournit toujours une zone bien grise à la 
place de la forêt et des champs.
https://www.openstreetmap.org/relation/1728908
https://www.openstreetmap.org/relation/1728914
https://www.openstreetmap.org/relation/2001400

Pouvez-vous SVP vérifier et me dire l'erreur que je n'ai pas identifié ? Par la 
même occasion, des astuces pour valider ce genre de configurations (outils 
online) ? http://ra.osmsurround.org/analyzeRelation ne fournit pas de réponse 
(pas claire en tout cas) à mon problème.

Merci,
Teuxe

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Frédéric Rodrigo]

Le 29/03/2016 22:43, Christian Quest a écrit :
Je vais mettre au propre tout ça pour le wiki... en fait l faut que je 
reparte de zéro, puis étape par étape.


Sur le graphe, la trace verte correspond aux solutions en "float", 
puis quand ça passe en "fix" c'est le point à droite au milieu.


Tant que je ne fournit pas de données de correction cohérents, ça 
reste en "simple", c'est à dire ce qui sort du GPS.



L'altitude est très stable elle aussi (stable à 1cm près).
La borne IGN ne semble pas contre pas à son emplacement officiel... 
avec 2,4m d'écart.

Je suppose que c'est du nivellement ?
Les borne de nivellement sont bien calées en élévation, mais pas en x/y, 
et inversement pour les géodésiques.


Frédéric.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rencontre contributeurs de Paris-IdF 31/03/2016

[Donat ROBAUX]

Bonjour à tous,

Nous nous retrouvons jeudi 31 mars 2016 à partir de 19h30 à la FPH 38 rue
Saint Sabin, Paris 11.

Le reste des informations est sur le forum:
*http://forum.openstreetmap.fr/viewtopic.php?f=18=4603
*
ou sur l'agenda du libre http://www.agendadulibre.org/events?region=12
quand l'événement sera validé.

Donat
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Christian Quest]

Oui, GLONASS est bien utilisé. Si je ne donne que les infos de navigation
GPS ou GLONASS ou les deux, j'ai des résultats différents et un nombre de
satellites utilisés pour le calcul de la solution qui n'est pas le même.
GPS+GLONASS ça donne 14 satellites utilisables et pour l'un ou l'autre seul
j'ai 8 et 6.

Cet après-midi, je vais aller faire un tour sur une borne IGN récente
(1995) et facile d'accès pour y refaire une mesure de contrôle.

Mise en charge aussi de ma tablette Android pour y tester les applis RTK
que j'ai repéré... histoire d'enregistrer une trace sur le chemin.



Le 30 mars 2016 à 10:26, Stéphane Péneau  a
écrit :

> Le 30/03/2016 08:52, Ab_fab a écrit :
>
>> Il me tarde d'en savoir plus sur ce petit projet de GUI pour RTKLib
>> adaptée aux écrans tactiles conçus pour la Raspberry.
>> Cela m'aiderait bien pour jouer un petit peu quand je vais à la campagne.
>>
>> Christian, je suis preneur de tes trouvailles futures ^^.
>> Notamment la liaison entre la base et le rover.
>> Via une liaison locale (wifi / bluetooth) à courte distance ?
>> Ou directement par les réseaux mobiles ?
>>
>> Pour ma part, je me dirige vers les réseaux mobiles.
> Je récupère les données de la base via un port série -> serial-to-tcp ->
> réseau mobile
> L'autre solution est d'intégrer ça dans un flux ntrip, mais je ne suis pas
> sûr que ça soit plus simple.
>
> Pour l'instant je n'en suis qu'à la théorie.
>
> Christian,
>
> As-tu regardé si rtklib utilisait effectivement les satellites glonass ? A
> priori ça ne fonctionne pas souvent lorsqu'on utilise du matériel différent
> pour la base et le rover.
>
>
> Stf
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Yves Pratter]

> Le 19 févr. 2016 à 19:18, Jean-Michel Pouré  a écrit :
> 
> J'ai l'impression qu'on doit prévoir une petite station météo capable
> de logger température, pression atmosphérique et détecteur de pluie
> (pluviométrie). Ces données ont un impact sur la réception GPS
Bonjour,

Quels sont tes sources ?

Les perturbations « atmosphériques »  qui dégradent beaucoup la précision GPS 
se situent dans la ionosphère…
Pour une précision cartographique (5m à 10 cm), les perturbations 
troposhériques ont peu d’effet.
Source : http://www.montana.edu/gps/slides/2GPSAccuracy.pdf 


Les mesures de la pression atmosphériques, le taux d’hygrométrie, la 
température… sont destinées à des applications météorologiques.
https://fr.wikipedia.org/wiki/Application_du_GPS_en_météorologie 



—
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Ab_fab]

Christian,

As-tu envisagé cette application Android pour tes essais ?
https://play.google.com/store/apps/details?id=gpsplus.rtkgps=fr

ça peut être pratique côté rover



Le 29 mars 2016 à 19:52, Christian Quest  a écrit :

> Retour sur RTKLIB... et grand pas en avant pour moi aujourd'hui !
>
> J'ai commandé il y a quelques semaines 2 GPS chez csgshop basés sur le M8T
> à environ 100 euros pièce.
> J'ai profité de quelques jours de congé pour m'y mettre et tester ces
> bestiaux.
>
> Première galère: compiler RTKLIB pour ubuntu... on sent que c'est codé
> avant tout pour Windows et les fichiers makefile sont incomplets pour
> linux. Il y a heureusement des pull-request sur github qui proposent les
> corrections nécessaires: https://github.com/tomojitakasu/RTKLIB/pull/142
>
> Une fois compilé, la doc est assez peu intuitive et comme tout se fait en
> ligne de commande ce n'est pas des plus user friendly.
>
> rtkrcv permet de collecter les données provenant du GPS et de les stocker
> dans un fichier, encore faut-il correctement renseigne le fichier de
> configuration... trouver le /dev/tty??? derrière lequel se cache le GPS
> connecté en USB (pour moi c'est /dev/ttyACM0 ou /dev/ttyACM1).
>
> Ensuite il faut indiquer au GPS qu'on veut récupérer les données brutes
> (raw)... donc lui envoyer des commandes pour ça.
>
> Finalement, j'ai pu enregistrer les données provenant du GPS dans le but
> de faire du post-processing, c'est à dire d'appliquer la correction après
> coup en utilisant les données d'une station de base fixe par trop éloignée.
>
> Une fois le fichier de log enregistré, il faut le convertir en fichiers en
> format RINEX, et la commande convbin de RTKLIB est faite pour ça... on
> obtient des fichier .obs, .nav et .gnav qui contiennent les données brutes
> (obs), les données des satellites GPS visibles (nav) et celles des
> satellites GLONAS (gnav).
>
> Maintenant les données de la base... et j'ai de la chance d'en avoir une à
> proximité (4km).
> Les données sont disponibles sur un serveur FTP de l'IGN, avec une heure
> de décallage (d'où le post-processing). Encore faut-il comprendre le
> nommage de ces fichiers... et comprendre aussi que ce ne sont pas des
> fichiers RINEX mais CRINEX, c'est à dire compressés (alors qu'ils sont
> aussi compressés en .Z).
>
> Donc recherche de cet outil de compression/décompression crx2rnx...
>
> Une fois le fichier CRINEX décompressé, on le passe à rnx2rtkp pour faire
> le post-processing et là... miracle après quelques tâtonnements, je passe
> d'une erreur de quelques mètres à une erreur de l'ordre du centimètre !
>
> Ma mesure a été faite sur une borne IGN pendant 20mn. Au bout de 90s
> environ, le post-processing converge et sort une position très précise.
>
> Voir: https://twitter.com/cq94/status/714867234762584064
>
> La grille fait 5cm de côté. En rouge on a les points mesurés sans
> correction.
> En vert, la correction est appliquée... ça fait une trace flottante en bas
> à gauche, puis ça converge sur un point à droite au milieu et ça ne bouge
> plus :)
>
> Prochain test: utiliser mon deuxième GPS pour faire de la correction en
> temps-réel...
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Stéphane Péneau]

Le 30/03/2016 08:52, Ab_fab a écrit :
Il me tarde d'en savoir plus sur ce petit projet de GUI pour RTKLib 
adaptée aux écrans tactiles conçus pour la Raspberry.

Cela m'aiderait bien pour jouer un petit peu quand je vais à la campagne.

Christian, je suis preneur de tes trouvailles futures ^^.
Notamment la liaison entre la base et le rover.
Via une liaison locale (wifi / bluetooth) à courte distance ?
Ou directement par les réseaux mobiles ?


Pour ma part, je me dirige vers les réseaux mobiles.
Je récupère les données de la base via un port série -> serial-to-tcp -> 
réseau mobile
L'autre solution est d'intégrer ça dans un flux ntrip, mais je ne suis 
pas sûr que ça soit plus simple.


Pour l'instant je n'en suis qu'à la théorie.

Christian,

As-tu regardé si rtklib utilisait effectivement les satellites glonass ? 
A priori ça ne fonctionne pas souvent lorsqu'on utilise du matériel 
différent pour la base et le rover.


Stf

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Ab_fab]

Il me tarde d'en savoir plus sur ce petit projet de GUI pour RTKLib adaptée
aux écrans tactiles conçus pour la Raspberry.
Cela m'aiderait bien pour jouer un petit peu quand je vais à la campagne.

Christian, je suis preneur de tes trouvailles futures ^^.
Notamment la liaison entre la base et le rover.
Via une liaison locale (wifi / bluetooth) à courte distance ?
Ou directement par les réseaux mobiles ?

Le 29 mars 2016 à 22:43, Christian Quest  a écrit :

> Je vais mettre au propre tout ça pour le wiki... en fait l faut que je
> reparte de zéro, puis étape par étape.
>
> Sur le graphe, la trace verte correspond aux solutions en "float", puis
> quand ça passe en "fix" c'est le point à droite au milieu.
>
> Tant que je ne fournit pas de données de correction cohérents, ça reste en
> "simple", c'est à dire ce qui sort du GPS.
>
>
> L'altitude est très stable elle aussi (stable à 1cm près).
> La borne IGN ne semble pas contre pas à son emplacement officiel... avec
> 2,4m d'écart.
>
> Il faut que j'en trouve une autre accessible et moins martyrisée que
> celle-ci car coincée entre une départementale et un champ, elle a
> visiblement subit quelques dommages (y compris la base en béton).
>
> Pour l'altitude, ça s'est stabilisé à 207,63m. La fiche IGN annonce 208.84
> mais sur une ellipsoïde différente que celle du WGS84.
>
>
> Le 29 mars 2016 à 21:27, Stéphane Péneau  a
> écrit :
>
>> Le 29/03/2016 19:52, Christian Quest a écrit :
>>
>>> Retour sur RTKLIB... et grand pas en avant pour moi aujourd'hui !
>>>
>>>
>>>
>>> Maintenant les données de la base... et j'ai de la chance d'en avoir une
>>> à proximité (4km).
>>> Les données sont disponibles sur un serveur FTP de l'IGN, avec une heure
>>> de décallage (d'où le post-processing). Encore faut-il comprendre le
>>> nommage de ces fichiers... et comprendre aussi que ce ne sont pas des
>>> fichiers RINEX mais CRINEX, c'est à dire compressés (alors qu'ils sont
>>> aussi compressés en .Z).
>>>
>>
>> La dernière fois que j'ai essayé, j'ai galéré pour retrouver le lieu où
>> télécharger ces données. Et oui, le nommage est..
>> Si tu as tout ça en tête, et puisque tu as réussi le postprocessing (ce
>> ne fut pas mon cas), tu penses que tu pourrais mettre tout ça sur le wiki ?
>>
>>
>>
>>
>>> La grille fait 5cm de côté. En rouge on a les points mesurés sans
>>> correction.
>>> En vert, la correction est appliquée... ça fait une trace flottante en
>>> bas à gauche, puis ça converge sur un point à droite au milieu et ça ne
>>> bouge plus :)
>>>
>>>
>> Super !!
>>
>> Tu n'as pas eu de passage en "float" entre le mode standard et le fix ?
>> Tu étais correct aussi sur l'altitude ?
>>
>>
>> Stf
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr