[OSM-talk-fr] (sans objet)

[g.d]

Sujet "automatisation des tracés gpx vers osm"

Sylvain,
justement tes exemples bien documentés
(http://slyserv.dyndns.org/simplification-osm.png)
montrent,
que l'automatisation de transfert d'un gpx sur osm
est vachement foireuse actuellement,
de par le principe appliqué, "béta"...

Comme quoi,
ce n'est que la personne qui a fait le trajet (humaine, homo sapiens,  
sapiens sa pince au bout des bras)
qui a le trajet en mémoire (en ce cas, toi-même),
qui pourra optimiser de façon raisonnée !
---

Si ce relevé avait été fait
sur un sentier de randonnée de type 'demanding alpine hiking',
avec un gps fiable,
le résultat de l'optimisation par josm serait "le mieux correct" !

Par contre,
si c'était un gpx sur l'autoroute Stuttgart - Lac_de_Constance
à 310 à l'heure,
bhen faudrait "revoir" les critères et coeffs de l'algorithme... ;-)
---

Sur le fond de la question :
Une simple analyse de "ligne droite <-> tracé gpx relevé <-> angularité"
ne suffit point.
Avant de s'attaquer au problème, 'faudrait regrouper
a) de quoi on dispose, comme infos pertinentes, et
b) ce qu'on veut obtenir...
A éclaircir, avant d'attaquer de faire un "optimisateur".

Sans aller plus au fond, en premier 'survol' de la question,
on pourrait s'imaginer un script
avec plusieurs discriminations superposées, utilisant les time-stamps  
du gpx
entre trois, cinq, sept et onze nodes consécutifs,
en égard des accélérations longitudinales (g),
ET des accélérations latérales.

Je ne connais pas les chiffrés réalistes à appliquer.
Mais ça devrait permettre de discriminer les moyens de locomotion  
desquels sont issus les gpx :
à pied, à vélo/cheval, en voiture (et type voie de forêt, autoroute,  
rallye, F1)
ou en avion chasseur...
puis y appliquer les "g" acceptables, maximales ou raisonnables,
afin de pondérer la "rigidité" des divers nodes.

afin de virer des "échappés",
et de pondérer les nodes restants,
"poids" qui désigne leur "incertitude"
et donc leur "possibilité pondérée" d'être ripé par le traitement  
ultérieur,
(optimisation angle/vitesse),
pour arriver au tracé final...

D'après la formule universelle : "(pif * pi) / trouillomètre",
je penserais,
que pour des véhicules terrestres ordinaires
des "g" longitudinaux au-delà de 2
et latéraux au-delà des 1,2
relèvent de la F1, ou d'un crash (->décor), donc à éliminer,

là où pour des piétons, chevaux et autres vélos
des 0,4 g horizontaux sur 3 mètres et plus, relèvent de l'exploit  
d'un record mondial.

Une telle approche pourrait rendre "plus raisonnable" une  
optimisation des nodes,
Mais franchement,
je ne me sens pas de taille, aujourd'hui,
de traduire cela en un script ! On se fait vieux... :-(
---

Trop-long
------

P.s. :
Dans les années '71,
j'avais participé au développement d'une démarche semblable,
mais inverse, sous Fortran :
Optimisation de tracés routiers,
en fonction des impératifs topographiques,
du delta de l'accélération latérale "convenable",
la vitesse avec laquelle le conducteur tourne le guidon
avec variation "douce" du delta
(le traditionnelles courbes "clothoïdes" ne convenaient plus,
en plaine dès les 90 km/h, et en collines parfois déjà dès 50 km/h...),
calcul des champs de vision, de visibilité des obstacles
(on n'avait pas de "modèles 3d" comme aujourd'hui, juste les données  
sur bande,
extrayait sur staple,
et calculait la "fenêtre de visibilité" du coup-le-coup, inv arcsin,  
arctan...),
calcul des profils, des masses, et optimisation déblai/remblai.
C'est tellement loiin, tout ça... :-(
---

Mais,
s'il y avait un informaticien vdr/"routier" ;-) actif dans la bande,
sur cette liste,
il pourrait certainement aider un peu.
Je pense qu'ils ont ces algorithmes/matrices_itératives sous la main,
il "suffirait" que quelqu'un (pas moi...) les assemble dans l'autre  
sens,
"analytique", au lieu de "constructif",

pour aider à une optimisation raisonnée des tracés gpx...
---

Amicalement
Gerhard
------

Le 19 nov. 08 à 19:28, sylvain letuffe a écrit :

>
> On Wednesday 19 November 2008 19:03, Pieren wrote:
>> 2008/11/19 sylvain letuffe <sylvain at letuffe.org>:
>>> http://slyserv.dyndns.org/simplification.png
>>
>> Jolie image ;-)
>
> J'ai fais plusieurs essais avec gpsbabel pour finir par tomber sur  
> 20 mètres
> de déviance en voiture et plutôt 10 mètres en rando, mais j'aurais  
> rêvé d'un
> cumul de déviance métrique ET angulaire (bon, comme c'est déjà pas  
> clair dans
> ma tête ça ne le sera sûrement pas pour les autres, mais bon ) avec  
> moulte
> courage je pondrais peut-être un algo, mais faudrait d'abord que je  
> fasse de
> java un copain... ;-)
>
>> Je trouve la version de droite parfaite (josm). Celle de gauche est
>> beaucoup trop simplifiée.
>
> Tu n'as pas regardé l'échelle ;-)
>
> C'était un "piège", il s'agit d'une ballade en rando à pieds avec  
> mon vieux
> GPS pourri. Et la plupart des formes bizarre sont bien des erreurs  
> de capture
> GPS qu'il aurait fallu gommer et qu'aucun algo pré-cité n'arrive à  
> gérer (il
> faudrait coupler à la "qualité signal GPS" pour faire bien )
>
> Voilà l'image final, cette fois avec mon "choix" pour OSM :
> de gauche à droite :
> - gpsbabel 20m max de déviance
> - JOSM (50m déviance, très louche, un autre algo est à l'oeuvre je  
> pense)
> - La trace source
> - Mon choix "humain" importé dans OSM
> http://slyserv.dyndns.org/simplification-osm.png
>
> Évidement, je n'ai pas noté avec un papier, durant ma rando, la  
> "vérité vrai"
> et d'ailleurs, je ne suis pas géomètre ! Mais une sous couche photo  
> satellite
> serait du plus bel effet "pour savoir"
>
> Le petit triangle vert que j'ai rentré dans OSM, je  
> l'interpréterais comme "je
> me suis moi même fait avoir car je pense qu'il n'a jamais eu lieu
>
>
> -- 
> Sylvain Letuffe sylvain at letuffe.org
> qui suis-je : http://slyserv.dyndns.org
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>