Re: [OSM-talk-fr] Géo-référencement images aérienne

[Stéphane Péneau]

Heu... parce que je ne connais pas Qgis :-)
Si c'est la bonne solution, j'essaierai de regarder de ce côté-là.

Stf

Le 07/11/2015 23:59, Jérôme Seigneuret a écrit :

Bonjour,
Pourquoi ne pas utiliser QGIS pour géorérérencer les images?

Le 7 novembre 2015 19:18, Stéphane Péneau > a écrit :


Bonsoir !

Avant de m'attaquer à plus gros, j'essaie de géo-référencer des
vues aériennes prises pendant l'opération libre à Chéméré.

Premier essai via Mapwarper. Résultat ici :
http://mapwarper.net/layers/419
Ça fonctionne, et je peux récupérer ces images sur une couche Tms
dans Josm.
Problème : Ce n'est pas évident de référencer les images seulement
depuis un fond de carte Osm, et le zoom max est trop faible.

Second essai via Piclayer dans Josm.
C'est beaucoup plus flexible, pas de limite de zoom, et je peux
utiliser plusieurs calques différents pour me repérer (imagerie
aérienne, cadastre, etc...)
Problème : Une fois l'image calée, je ne trouve rien pour
récupérer ces informations dans un format utilisable avec Mapwarper.
La seule chose possible est d'enregistrer le calibrage dans un
fichier .cal, mais ce type de fichier semble propre à Piclayer. Je
ne vois rien pour créer un GeoTiff ou autre.

J'ai loupé quelque chose avec ce fichier .cal ?

Stéphane

___
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


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

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[Stéphane Péneau]

Le 08/11/2015 10:29, pepilepi...@ovh.fr a écrit :

Il y a un moyen simple d'importer un élément du cadastre dans la carte ?


Il existe une possibilité de récupérer le bâti pour l'ouvrir dans Josm, 
le nettoyer, vérifier la concordance avec ce qui est déjà existant, et 
ensuite l'envoyer.

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents
Idem pour les limites communales.

Mais pour la voirie ce n'est pas possible, et pas souhaitable.

Pourquoi cette conversion est-elle déconseillée ? Je pensais que 
c'était à cause du nombre de points qui pourrait surcharger la base 
alors que si je comprends bien Jean-Claude plus il y a de points 
meilleur c'est... 


Un nombre de points élevé n'est pas un problème, au contraire, et ce 
n'est pas ça qui surchargera quoi que ce soit. D'ailleurs, les traces 
gps ne sont pas stockées dans la base Osm.
Ce n'est pas conseillé, car ce n'est pas précis, et plus globalement, un 
tracé de route va souvent avoir besoin de plus de points qu'une trace 
gpx dans une courbe, un giratoire, et au contraire, moins de points sur 
les lignes droites.


Et si elle est déconseillée pourquoi des outils comme JOSM, que je 
pense conçu pour mettre à jour OSM, la proposent-ils ? 


Il y a plein de cas où ce genre de manip est utile.
Dernièrement, je devais géolocaliser des photos à l'aide d'une trace 
gpx, mais j'ai eu besoin de la repréciser au préalable. J'ai donc fait 
gpx->calque de données-> édition -> gpx

C'est un exemple parmi d'autres.


Et donc en résumé, faut-il oui ou non importer des traces de bonne 
qualité ? 


Envoyer les traces gpx sur les serveurs Osm, oui. Les convertir en 
chemin pour les envoyer tels quels dans la base Osm, non.


Merci (tant de vos infos que de votre patience avec un débutant 
totalement inexpérimenté)


On a tous été débutants à un moment ou à un autre :-)

Stf


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

Re: [OSM-talk-fr] Géo-référencement images aérienne

[Jérôme Seigneuret]

Voici un petit cours basé sur une image google mais le principe est le
même. Il faut au moins 3 points (cas ou l'on est sur le système de
projection de la photo donc c'est le cas des plan)  Mais pour rectifier la
mieux c'est au moins 5 points (le plus proche des 4 angles et un au
centre).
Je sais pas comment a été prise la photo ou si elle à subit des
post-traitements pour corriger la déformation optique et angulaire.

Pour la prise en main il y a ça mais c'est sur une version 1.8 donc il peut
y avoir des évolutions sur la barre d'outils. Une fois que tu as compris le
principe il n'y a rien de sorcier.

http://www.sigcours.com/fr/quantum-gis/affichage-des-donnees-dans-qgis/144-georeferencer-une-image-de-google-earth-avec-qgis.html


PS si tu es sous Windows, Il faut que ton nom de session n'ai pas d'accents
ou de caractères non ascii car ça pose des problèmes pour l'exécution de
certains traitements Python (mauvaise gestion des conversion unicode et
encodage local)
La version standelone devrait être adapté à ton besoin.

Jérôme

Le 8 novembre 2015 12:15, Stéphane Péneau  a
écrit :

> Heu... parce que je ne connais pas Qgis :-)
> Si c'est la bonne solution, j'essaierai de regarder de ce côté-là.
>
> Stf
>
>
> Le 07/11/2015 23:59, Jérôme Seigneuret a écrit :
>
> Bonjour,
> Pourquoi ne pas utiliser QGIS pour géorérérencer les images?
>
> Le 7 novembre 2015 19:18, Stéphane Péneau  a
> écrit :
>
>> Bonsoir !
>>
>> Avant de m'attaquer à plus gros, j'essaie de géo-référencer des vues
>> aériennes prises pendant l'opération libre à Chéméré.
>>
>> Premier essai via Mapwarper. Résultat ici :
>> http://mapwarper.net/layers/419
>> Ça fonctionne, et je peux récupérer ces images sur une couche Tms dans
>> Josm.
>> Problème : Ce n'est pas évident de référencer les images seulement depuis
>> un fond de carte Osm, et le zoom max est trop faible.
>>
>> Second essai via Piclayer dans Josm.
>> C'est beaucoup plus flexible, pas de limite de zoom, et je peux utiliser
>> plusieurs calques différents pour me repérer (imagerie aérienne, cadastre,
>> etc...)
>> Problème : Une fois l'image calée, je ne trouve rien pour récupérer ces
>> informations dans un format utilisable avec Mapwarper.
>> La seule chose possible est d'enregistrer le calibrage dans un fichier
>> .cal, mais ce type de fichier semble propre à Piclayer. Je ne vois rien
>> pour créer un GeoTiff ou autre.
>>
>> J'ai loupé quelque chose avec ce fichier .cal ?
>>
>> Stéphane
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> 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

[OSM-talk-fr] OpenSolarMap...

[Donat ROBAUX]

>
> Bonjour à tous,
>

Je souscris entièrement à ce qu'a fait comme remarques Jérôme après avoir
crowsourcé 40 bâtiments:
- le rond d'emprise souvent fantaisiste ou pas assez précis: rond-point
d'une ZI, toits de plusieurs bâtiments industriels, une zone entière de 5
immeubles et 10 pavillons (!)
- des bâtiments multipentes
- des toits orientés ni NS ni EO, mais entre les 2.

En tout cas un beau projet.
Donat

>
>
> -- Message transféré --
> From: "Jérôme Seigneuret" 
> To: "Discussions sur OSM en français" 
> Cc:
> Date: Sun, 8 Nov 2015 17:08:25 +0100
> Subject: Re: [OSM-talk-fr] OpenSolarMap...
> Bonjour,
> Je viens de faire une centaine de bâtiments.
>
> Voici mes remarques:
> - Les boutons manques de clarté pour un novice.
> - Pas de possibilité de corriger ces dernières éditons c'est dommage. >
> erreur humaine j'ai choisi le bouton d'à coté sur certains batî...
> - Il y a des bâtis intéressant mais à double orientations (j'ai mis ?)
> - Le gros rond d'emprise rend difficile l’identification du bâtiment
> concerné (pour certains j'ai mis ?) > J'invite à mettre le polygone
> concerné plutôt que le centroïde avec un rond d'emprise. Et mieux, mettre
> le contour à l'extérieur du polygone avec peut-être un tampon d'1m.
> - Autre chose pour éviter une mauvaise détection: définir une possibilité
> d'écarter de l'analyse pour des raisons de mauvais calage ou gros décalage
> entre le toit et l'emprise au sol (pour les grands bâtiment et une ortho
> non rectifiée où une partie du toit sera à l'extérieur de la zone de
> reconnaissance).
> - Cas problématique: bâtiment plus à jour grâce au cadastre n'existant pas
> sur l'otho > à écarter de l'analyse ( j'ai mis ?)
>
> Certains bâtiments sont pour parti intéressant mais il n'y a pas de
> building:part... > proposer soit la décomposition du bâtiment soit la
> gestion d'un  building:part
> =yes +
> roof:shape=
>
> roof:shape= me parait indispensable. La reconnaissance pourra aussi
> permettre de remplir en semi auto (voir auto) le type de toiture
>
> Un toit à simple pente si elle est orienté au nord ne sera pas
> intéressante
> roof:shape=skillion + roof:direction
> =north
>
> roof:orientation 
> =along/across
>   > par rapport au coté le plus long
> A savoir que la pente n'est pas forcément sur le coté le plus long surtout
> sur les maison de village
>
> Voici ma petite contribution.
> Jérôme
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[pepilepi...@ovh.fr]

Le 07/11/2015 19:56, Jean-Claude Repetto a écrit :
> Le 07/11/2015 18:38, pepilepi...@ovh.fr a écrit :
>> Le 07/11/2015 17:48, Jérôme Seigneuret a écrit :
>>> Bonjour,
>>> Peux-tu envoyer ton GPX histoire de voir
>>
>> Il y a par exemple
>> http://www.openstreetmap.org/user/Pepilepioux/traces/2063923
>>
>>>
>
> Bonjour,
>
> Cette trace ne me paraît pas utilisable pour tracer le chemin. En
> effet, elle est beaucoup trop simplifiée, il y a des segments de
> droites très longs, et des angles importants entre les segments. 

OK, merci pour ces infos.
Je l'avais en effet bien simplifiée pour ne pas "assommer" la base de
données avec un gros paquet de données pour un si petit chemin. La
trace  originale contient en effet 527 points pour 5 km et fait 80 ko.
Je la supprime donc.

> Il vaut mieux utiliser une trace non simplifiée (un point toutes les
> secondes). Sur la photo aérienne, on voit bien que la trace ne
> correspond pas au terrain.

OK, c'est noté.

> A propos, ce chemin figure en partie sur le cadastre.

Mais pas sur la carte
(https://www.openstreetmap.org/#map=15/44.7939/5.0563), c'est pour ça
que j'ai voulu l'intégrer.
Il y a un moyen simple d'importer un élément du cadastre dans la carte ?

> Et pour répondre à la question initiale, je n'ai eu aucun problème
> pour convertir la trace en calque de données, mais c'est à éviter
> absolument, étant donnée la mauvaise qualité de la trace.


D'autre part :
> Le 07/11/2015 17:44, Stéphane Péneau a écrit :
> Bonjour Jean-Pierre,
>
> Tout d'abord, bienvenu parmi les contributeurs Osm !
>
> La conversion de traces gpx en voirie est quelque chose de fortement
> déconseillé, donc oui, il va falloir dessiner les chemins de randonnée
> à la main, en t'aidant des différentes sources disponibles : imagerie
> aérienne, cadastre, chemin déjà présent, etc...

Pourquoi cette conversion est-elle déconseillée ? Je pensais que c'était
à cause du nombre de points qui pourrait surcharger la base alors que si
je comprends bien Jean-Claude plus il y a de points meilleur c'est...
Et si elle est déconseillée pourquoi des outils comme JOSM, que je pense
conçu pour mettre à jour OSM, la proposent-ils ?

>
> Jean-Claude

Et donc en résumé, faut-il oui ou non importer des traces de bonne qualité ?


Merci (tant de vos infos que de votre patience avec un débutant
totalement inexpérimenté)

Jean-Pierre



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

Re: [OSM-talk-fr] [BANO] bizarreries

[Laurent Combe]

tout est rentré dans l'ordre ce matin

merci

Le 8 novembre 2015 09:27, Vincent de Château-Thierry  a
écrit :

> Bonjour,
>
> Le 07/11/2015 19:49, . ZZ29 a écrit :
>
>>
>> Mêmes symptômes constatés.
>>
>> Le 7 novembre 2015 18:56, Laurent Combe > > a écrit :
>>
>> le rendu BANO ne s'affiche plus pour les zoom >= 17
>> et le mécanisme "/dirty" pour forcer le recalcul d'une tuile semble
>> inopérant
>>
>> quelqu'un peut-il confirmer le pb ? et rétablir la situation ?
>>
>
> Je ne sais pas si ça persiste ce matin. C'est une partie que gère
> Christian, "légèrement occupé" ce week-end avec OpenSolarMap au Hackaton
> C3Challenge :
> https://twitter.com/cq94/status/663258706138816512
>
> De mémoire il avait dû la semaine dernière, pour des raisons de charge du
> serveur, couper certains mécanismes de rafraichissement des tuiles BANO, je
> suppose que c'est la cause du souci. À suivre.
>
> vincent
>
>
> ___
> 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] Extractions du cadastre indisponibles

[Gaël Simon]

Bonjour,
Une source de simplification supplémentaire pourrait être de supprimer les 
points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la base 
avec des points inutiles, générés souvent aux limites de parcelle. 

Gaël

Le 6 nov. 2015 à 23:32, Tyndare  a écrit :

> Le 6 novembre 2015 22:37, David Crochet  a écrit :
> Le 06/11/2015 21:59, Tyndare a écrit :
>> 
>>  - merge (M) des nœuds proches (20 cm)
> 
> 
> En gros :
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> point de l'extraction de la base cadastre, alors c'est le même.
> c'est ca ?

En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
simplification du fichier extrait du cadastre, qui contient souvent
des points beaucoup trop proches les uns des autres pour que sa vaille
la peine de les distinguer.

> 
>>  - join (J) des nœuds au chemin proche (20 cm)
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> chemin de l'extraction de la base cadastre, alors ajoute ce point au chemin,
> comme cela la prochaine fois, ça fera simplement un "merge".
> j'ai bien compris ?

Non, il ne s'agit toujours pas de merge avec les données de la base OSM.
Le merge est un sujet bien plus compliqué qui est traité ici:
- https://github.com/jecor/bati-fusion
ou là:
- https://github.com/sebastien-bugzilla/BatiOsm

Ici je ne parle toujours que d'extraction brute des données du
cadastre, rien de changé par rapport a avant.

> 
>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
> 
> en d'autres termes ?

Je fais juste référence à la fonction JOSM de simplification des
chemins, comme expliqué sur le Wiki d'import semi automatique du bâti:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents

___
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] [BANO] bizarreries

[Vincent de Château-Thierry]

Bonjour,

Le 07/11/2015 19:49, . ZZ29 a écrit :


Mêmes symptômes constatés.

Le 7 novembre 2015 18:56, Laurent Combe > a écrit :

le rendu BANO ne s'affiche plus pour les zoom >= 17
et le mécanisme "/dirty" pour forcer le recalcul d'une tuile semble
inopérant

quelqu'un peut-il confirmer le pb ? et rétablir la situation ?


Je ne sais pas si ça persiste ce matin. C'est une partie que gère 
Christian, "légèrement occupé" ce week-end avec OpenSolarMap au Hackaton 
C3Challenge :

https://twitter.com/cq94/status/663258706138816512

De mémoire il avait dû la semaine dernière, pour des raisons de charge 
du serveur, couper certains mécanismes de rafraichissement des tuiles 
BANO, je suppose que c'est la cause du souci. À suivre.


vincent

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

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[Jérôme Seigneuret]

>
>
> Mais pour la voirie ce n'est pas possible, et pas souhaitable.
>
> Pourquoi cette conversion est-elle déconseillée ? Je pensais que c'était à
>> cause du nombre de points qui pourrait surcharger la base alors que si je
>> comprends bien Jean-Claude plus il y a de points meilleur c'est...
>>
>
> Un nombre de points élevé n'est pas un problème, au contraire, et ce n'est
> pas ça qui surchargera quoi que ce soit. D'ailleurs, les traces gps ne sont
> pas stockées dans la base Osm.
>

Mais dans la pratique la sur-qualité n'est pas utile. En dessin on utilise
des distances de saisie cohérente avec une échelle de référence. Et les
points distant de moins de 2 mètres ne servent à rien à mon avis. Ducoup la
qualité va dépendre de celle des données de fond utilisé. Dans tous les cas
le nombre de points le la trace n'est pas cohérente avec la manière de
dessiné sur OSM mais historiquement il n'y avait que ça.

Ce n'est pas conseillé, car ce n'est pas précis, et plus globalement, un
> tracé de route va souvent avoir besoin de plus de points qu'une trace gpx
> dans une courbe, un giratoire, et au contraire, moins de points sur les
> lignes droites.


Pour ce principe je supprime les points supplémentaires inutiles en ligne
droites. Et comme précisé, contrairement au GPS, la densité de points est
dépendante des courbes et de l'importance des angles et non pas par un pas
de temps et un changement de cap d'où le choix de dessiner sur un trace et
non de l'intégrer.


>
> Et si elle est déconseillée pourquoi des outils comme JOSM, que je pense
>> conçu pour mettre à jour OSM, la proposent-ils ?
>>
>
> Il y a plein de cas où ce genre de manip est utile.
> Dernièrement, je devais géolocaliser des photos à l'aide d'une trace gpx,
> mais j'ai eu besoin de la repréciser au préalable. J'ai donc fait
> gpx->calque de données-> édition -> gpx
> C'est un exemple parmi d'autres.


Oui en effet et la géolocalisation directe des photos comme sur les
smartphones (exemple d'utilisation sous Mapillary) montre des écarts plutôt
important mais le débat sur la qualité n'est pas le sujet. En tout cas je
préfère prendre un GPS séparé et placer les photos avec une synchronisation
temporelle comme tu le fais.


> Et donc en résumé, faut-il oui ou non importer des traces de bonne qualité
>> ?
>
> Envoyer les traces gpx sur les serveurs Osm, oui. Les convertir en chemin
> pour les envoyer tels quels dans la base Osm, non.


Je complète car si l'on regarde au niveau historique le gpx était la seul
source de données. Puis et arrivé l'othophoto et l'accord avec la DGI pour
le cadastre.

Comme dit précédemment, une seule trace GPX n'est pas suffisante pour
définir un placement correcte. On utilise un lot de traces et le
positionnement se fait en fonction d'une la position du plus grand nombre
de points sur les traces pour écarter les effets de bord.
Comprendre les limites du système permet de faire des choix. C'est pareil
avec les autres source de données (BING et Cadastre)

Donc oui il faut pousser les traces sur le serveur et même en pousser
plusieurs. Le serveur de traces n'est pas le même et il faut mettre des
traces qui peuvent être retraité en positionnement (correction et
synchronisation avec un serveur servant à cela mais c'est plus du matos
d'arpenteur) suppression de points aberrants ou coupure de la trace pour
supprimer les zones de trou (pas de point GPS sur une longue période puis
reprise de la position mais genre 500 m plus loin)
Pas de simplification car c'est une dégradation de qualité. Pas de recalage
sur une ortho car l'ortho elle-même peut avoir subit une mauvaise
rectification (surtout en zone montagneuse)


>
> Merci (tant de vos infos que de votre patience avec un débutant totalement
>> inexpérimenté)
>>
>
> On a tous été débutants à un moment ou à un autre :-)
>

Et comme ça évolue on peut dire qu'on en apprend tous les jours ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] OpenSolarMap...

[Christian Quest]

Le projet OpenSolarMap avance à l'occasion du hackathon du C3 (Climate
Change Challenge) en préparation de la COP21.

De quoi s'agit-il ?

Tout simplement identifier les bâtiments les plus propices à
l'installation de panneaux solaires (thermiques ou photovoltaïques),
c'est à dire au toit plat ou orienté le plus possible vers le SUD pour
avoir un rendement optimal.

Pour le concours opendata de la région PACA, j'avais commencé par
sélectionner les bâtiments orientés par rapport aux points cardinaux.
Maintenant il s'agit d'indiquer comment leur toit est orienté à l'aide
des images aériennes ou satellite... et pour cela nous avons travaillé
depuis hier à une interface de crowdsourcing la plus simple possible
(pas encore super sexy mais fonctionnelle).

C'est ici: http://www.opensolarmap.org/

Les bâtiments sont sélectionnés au hasard parmi ceux orientés par
rapport aux points cardinaux ou de surface importante (car
potentiellement au toit plat). Dès que plusieurs contributeurs ont
indiqué la même orientation, on pourra ajouter automatiquement dans OSM
les tags pour décrire l'orientation ou le type de toit (ceci n'est pas
encore codé).

N'hésitez pas à faire des remarques, c'est encore très très "bêta",
l'idée est de faire un outil destiné au grand public avec une logique de
gamification... qui pourra par ricochet aussi faire connaître OSM !

La prochaine phase consistera à entrainer un moteur de reconnaissance
d'images (opencv ?) à l'aide de ces contributions pour accélérer voire
totalement automatiser cette détection... mais on n'en est pas encore là ;)

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] OpenSolarMap...

[Jérôme Seigneuret]

Bonjour,
Je viens de faire une centaine de bâtiments.

Voici mes remarques:
- Les boutons manques de clarté pour un novice.
- Pas de possibilité de corriger ces dernières éditons c'est dommage. >
erreur humaine j'ai choisi le bouton d'à coté sur certains batî...
- Il y a des bâtis intéressant mais à double orientations (j'ai mis ?)
- Le gros rond d'emprise rend difficile l’identification du bâtiment
concerné (pour certains j'ai mis ?) > J'invite à mettre le polygone
concerné plutôt que le centroïde avec un rond d'emprise. Et mieux, mettre
le contour à l'extérieur du polygone avec peut-être un tampon d'1m.
- Autre chose pour éviter une mauvaise détection: définir une possibilité
d'écarter de l'analyse pour des raisons de mauvais calage ou gros décalage
entre le toit et l'emprise au sol (pour les grands bâtiment et une ortho
non rectifiée où une partie du toit sera à l'extérieur de la zone de
reconnaissance).
- Cas problématique: bâtiment plus à jour grâce au cadastre n'existant pas
sur l'otho > à écarter de l'analyse ( j'ai mis ?)

Certains bâtiments sont pour parti intéressant mais il n'y a pas de
building:part... > proposer soit la décomposition du bâtiment soit la
gestion d'un  building:part
=yes +
roof:shape=

roof:shape= me parait indispensable. La reconnaissance pourra aussi
permettre de remplir en semi auto (voir auto) le type de toiture

Un toit à simple pente si elle est orienté au nord ne sera pas intéressante
roof:shape=skillion + roof:direction
=north

roof:orientation
=along/across
  > par rapport au coté le plus long
A savoir que la pente n'est pas forcément sur le coté le plus long surtout
sur les maison de village



Voici ma petite contribution.
Jérôme






Le 8 novembre 2015 15:51, Christian Quest  a écrit
:

> Le projet OpenSolarMap avance à l'occasion du hackathon du C3 (Climate
> Change Challenge) en préparation de la COP21.
>
> De quoi s'agit-il ?
>
> Tout simplement identifier les bâtiments les plus propices à
> l'installation de panneaux solaires (thermiques ou photovoltaïques),
> c'est à dire au toit plat ou orienté le plus possible vers le SUD pour
> avoir un rendement optimal.
>
> Pour le concours opendata de la région PACA, j'avais commencé par
> sélectionner les bâtiments orientés par rapport aux points cardinaux.
> Maintenant il s'agit d'indiquer comment leur toit est orienté à l'aide
> des images aériennes ou satellite... et pour cela nous avons travaillé
> depuis hier à une interface de crowdsourcing la plus simple possible
> (pas encore super sexy mais fonctionnelle).
>
> C'est ici: http://www.opensolarmap.org/
>
> Les bâtiments sont sélectionnés au hasard parmi ceux orientés par
> rapport aux points cardinaux ou de surface importante (car
> potentiellement au toit plat). Dès que plusieurs contributeurs ont
> indiqué la même orientation, on pourra ajouter automatiquement dans OSM
> les tags pour décrire l'orientation ou le type de toit (ceci n'est pas
> encore codé).
>
> N'hésitez pas à faire des remarques, c'est encore très très "bêta",
> l'idée est de faire un outil destiné au grand public avec une logique de
> gamification... qui pourra par ricochet aussi faire connaître OSM !
>
> La prochaine phase consistera à entrainer un moteur de reconnaissance
> d'images (opencv ?) à l'aide de ces contributions pour accélérer voire
> totalement automatiser cette détection... mais on n'en est pas encore là ;)
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] OpenSolarMap...

[Christian Quest]

On 08/11/2015 17:08, Jérôme Seigneuret wrote:
> Bonjour,
> Je viens de faire une centaine de bâtiments.
>
> Voici mes remarques:
> - Les boutons manques de clarté pour un novice.

Il manque toujours des graphistes et designers dans les hackathon ;)
On va refaire ça plus propre et clair...

> - Pas de possibilité de corriger ces dernières éditons c'est dommage.
> > erreur humaine j'ai choisi le bouton d'à coté sur certains batî...

C'est pas grave, quand ça arrive, tant qu'on n'a pas 2 réponses
identiques le bâtiment ressortira pour d'autres contributeurs.

> - Il y a des bâtis intéressant mais à double orientations (j'ai mis ?)

Oui, c'est prévu comme ça.

> - Le gros rond d'emprise rend difficile l’identification du bâtiment
> concerné (pour certains j'ai mis ?) > J'invite à mettre le polygone
> concerné plutôt que le centroïde avec un rond d'emprise. Et mieux,
> mettre le contour à l'extérieur du polygone avec peut-être un tampon d'1m.

On avait essayé avec le polygone du bâtiment, mais ça rendait la lecture
de l'ortho peut lisible.
Pas con l'idée du buffer autour, ça devrait permettre de mieux
identifier la bâtiment (par la forme) sans pour autant le masquer...

> - Autre chose pour éviter une mauvaise détection: définir une
> possibilité d'écarter de l'analyse pour des raisons de mauvais calage
> ou gros décalage entre le toit et l'emprise au sol (pour les grands
> bâtiment et une ortho non rectifiée où une partie du toit sera à
> l'extérieur de la zone de reconnaissance).

En gros un bouton "bug" ?

> - Cas problématique: bâtiment plus à jour grâce au cadastre n'existant
> pas sur l'otho > à écarter de l'analyse ( j'ai mis ?)
>

Oui, le ? c'est pour tout les cas autre que les 3 cas simples...

> Certains bâtiments sont pour parti intéressant mais il n'y a pas de
> building:part... > proposer soit la décomposition du bâtiment soit la
> gestion d'un  building:part
> =yes +
> roof:shape=
>

Euh... sur une interface grand public ça va être délicat... en fait ce
sont les cas de toits multiples donc "?"

> roof:shape= me parait indispensable. La reconnaissance pourra
> aussi permettre de remplir en semi auto (voir auto) le type de toiture
>
> Un toit à simple pente si elle est orienté au nord ne sera pas
> intéressante 
> roof:shape=skillion + roof:direction
> =north
>
> roof:orientation
> =along/across
>   > par rapport au coté le plus long
> A savoir que la pente n'est pas forcément sur le coté le plus long
> surtout sur les maison de village
>

Ce sont ces tags que je pensais reporter dans OSM...

>
>
> Voici ma petite contribution.

Y'a pas de petite contribution ;)
Merci beaucoup !

-- 
Christian Quest - OpenStreetMap France

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

[OSM-talk-fr] tag source:maxspeed=:zone:30

[lenny]

Bonjour
Je viens de découvrir, sur un highway, le tag "/source:maxspeed=FR:zone30"/
Je l'ai cherché sur le wiki.
Autant je comprend par exemple : "/maxspeed=50/" avec 
"/source:maxspeed=FR:urban"/ ou "/source:maxspeed=sign"/ ; par contre, 
AMHA, je ne vois pas la valeur ajouté de "/source:maxspeed=FR:zone30"/ 
car, dans ce cas, la vitesse limite est toujours explicite.


Mais je suis encore plus étonné par les valeurs :
le wiki anglais propose deux possibilités (avec ou sans ":" entre "zone" 
et "30")
"maxspeed=30 and zone:maxspeed=DE:zone30 - Most used value (used 21k 
times in June 2015)"
"maxspeed=30 and source:maxspeed=DE:zone:30 - Second most used value 
(used 18k times in June 2015)"


pareil en Allemand
"maxspeed=30 und source:maxspeed=DE:zone30 oder DE:zone oder DE:zone:30"

en Français, une seule valeur est indiquée
"Pour taguer une zone 30, ajoutez les tags maxspeed=30 et 
source:maxspeed=:zone:30"

et quand je vais voir taginfo, pour environ 9000  "/zone:maxspeed=FR:30/"
"/source:maxspeed=FR:zone30/">3911
"/source:maxspeed=FR:zone:30/">  32
et là, la valeur proposée par le wiki est la moins utilisée ! déjà que 
je ne voyais pas ce que ce tag apportait !!!


Cordialement
Lenny

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

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[pepilepi...@ovh.fr]

  
  
Le 08/11/2015 12:54, Jérôme Seigneuret
  a écrit :


  

  

  Mais pour la voirie ce n'est pas possible, et pas
  souhaitable.


  Pourquoi cette conversion est-elle déconseillée ? Je
  pensais que c'était à cause du nombre de points qui
  pourrait surcharger la base alors que si je comprends
  bien Jean-Claude plus il y a de points meilleur
  c'est... 


  
  Un nombre de points élevé n'est pas un problème, au
  contraire, et ce n'est pas ça qui surchargera quoi que ce
  soit. D'ailleurs, les traces gps ne sont pas stockées dans
  la base Osm.



Mais dans la pratique la sur-qualité n'est pas utile.
  En dessin on utilise des distances de saisie cohérente
  avec une échelle de référence. Et les points distant de
  moins de 2 mètres ne servent à rien à mon avis. Ducoup la
  qualité va dépendre de celle des données de fond utilisé.
  Dans tous les cas le nombre de points le la trace n'est
  pas cohérente avec la manière de dessiné sur OSM mais
  historiquement il n'y avait que ça.



  Ce n'est pas conseillé, car ce n'est pas précis, et plus
  globalement, un tracé de route va souvent avoir besoin de
  plus de points qu'une trace gpx dans une courbe, un
  giratoire, et au contraire, moins de points sur les lignes
  droites.
 
Pour ce principe je supprime les points supplémentaires
  inutiles en ligne droites. Et comme précisé, contrairement
  au GPS, la densité de points est dépendante des courbes et
  de l'importance des angles et non pas par un pas de temps
  et un changement de cap d'où le choix de dessiner sur un
  trace et non de l'intégrer.





  Et si elle est déconseillée pourquoi des outils comme
  JOSM, que je pense conçu pour mettre à jour OSM, la
  proposent-ils ? 


  
  Il y a plein de cas où ce genre de manip est utile.
  Dernièrement, je devais géolocaliser des photos à l'aide
  d'une trace gpx, mais j'ai eu besoin de la repréciser au
  préalable. J'ai donc fait gpx->calque de données->
  édition -> gpx
  C'est un exemple parmi d'autres.


Oui en effet et la géolocalisation directe des photos
  comme sur les smartphones (exemple d'utilisation sous
  Mapillary) montre des écarts plutôt important mais le
  débat sur la qualité n'est pas le sujet. En tout cas je
  préfère prendre un GPS séparé et placer les photos avec
  une synchronisation temporelle comme tu le fais.




  Et donc en résumé, faut-il oui ou non importer des
  traces de bonne qualité ?
  
  Envoyer les traces gpx sur les serveurs Osm, oui. Les
  convertir en chemin pour les envoyer tels quels dans la
  base Osm, non.


Je complète car si l'on regarde au niveau historique le
  gpx était la seul source de données. Puis et arrivé
  l'othophoto et l'accord avec la DGI pour le cadastre.


Comme dit précédemment, une seule trace GPX n'est pas
  suffisante pour définir un placement correcte. On utilise
  un lot de traces et le positionnement se fait en fonction
  d'une la position du plus grand nombre de points sur les
  traces pour écarter les effets de bord. 
Comprendre les limites du système permet de faire des
  choix. C'est pareil avec les autres source de données
  (BING et Cadastre)


Donc oui il faut pousser les traces sur le serveur et
  même en pousser plusieurs. Le serveur de traces n'est pas
  le même et il faut mettre des traces qui peuvent être
  retraité en positionnement (correction et synchronisation
  avec un serveur servant à cela mais c'est plus du matos
  d'arpenteur) suppression de points aberrants ou coupure de
  la trace pour supprimer les zones de trou (pas de point
  GPS sur une longue période puis reprise de la position
  mais genre 500 m plus loin)
Pas 

Re: [OSM-talk-fr] OpenSolarMap...

[Jérôme Seigneuret]

Le 8 novembre 2015 17:26, Christian Quest  a écrit
:

>
>
> On 08/11/2015 17:08, Jérôme Seigneuret wrote:
>
> Bonjour,
> Je viens de faire une centaine de bâtiments.
>
> Voici mes remarques:
> - Les boutons manques de clarté pour un novice.
>
>
> Il manque toujours des graphistes et designers dans les hackathon ;)
> On va refaire ça plus propre et clair...
>

Ok Je peux aussi faire une propo au besoin


>
>
> - Pas de possibilité de corriger ces dernières éditons c'est dommage. >
> erreur humaine j'ai choisi le bouton d'à coté sur certains batî...
>
>
> C'est pas grave, quand ça arrive, tant qu'on n'a pas 2 réponses identiques
> le bâtiment ressortira pour d'autres contributeurs.
>

J'aurai mis trois pour valider (c'est mais base de stat ;-) )

>
>
> - Il y a des bâtis intéressant mais à double orientations (j'ai mis ?)
>
>
> Oui, c'est prévu comme ça.
>
Ok

>
>

> - Autre chose pour éviter une mauvaise détection: définir une possibilité
> d'écarter de l'analyse pour des raisons de mauvais calage ou gros décalage
> entre le toit et l'emprise au sol (pour les grands bâtiment et une ortho
> non rectifiée où une partie du toit sera à l'extérieur de la zone de
> reconnaissance).
>
> Oui mais c'est plutôt un système de gestion et de déclaration d'
"Anomalies". Le terme Bug se rapporte à un problème sur l'application. La
c'est plutôt une sorte de formulaire avec des propositions:
- bâtiment mal calé (décalage faible ou de 200m > erreur osm suite à import
du cadastre en zone de montagne ou de l'ortho...)
- bâtiment non visible sur l'imagerie
- bâtiment en construction sur l'imagerie
-... autre cas ce qui permettra de compléter le formulaire au besoin

Tu as :
- un bouton "?" qui doit correspondre à un problème d'identification de
type de pente et donc de choix
- un bouton "Anomalie" pour écarter un bâtiment avec du détail à ajouter
pour expliquer la raison de cette mise à l'écart


> - Cas problématique: bâtiment plus à jour grâce au cadastre n'existant pas
> sur l'otho > à écarter de l'analyse ( j'ai mis ?)
>
>
> Oui, le ? c'est pour tout les cas autre que les 3 cas simples...
>
décomposer sera plus utile par la suite

>
>
> Certains bâtiments sont pour parti intéressant mais il n'y a pas de
> building:part... > proposer soit la décomposition du bâtiment soit la
> gestion d'un  building:part
> =yes +
> roof:shape=
>
>
> Euh... sur une interface grand public ça va être délicat... en fait ce
> sont les cas de toits multiples donc "?"
>
Peut-être dans ce cas mettre en place deux niveaux dont l'un permettrait de
gérer des cas plus complexes par des gens du métier car les maison (et
résidences) en U et en L représente une gros lot de données


>
>

>
> roof:shape= me parait indispensable. La reconnaissance pourra aussi
> permettre de remplir en semi auto (voir auto) le type de toiture
>
> Un toit à simple pente si elle est orienté au nord ne sera pas
> intéressante
> roof:shape=skillion + roof:direction
> =north
>
> roof:orientation 
> =along/across
>   > par rapport au coté le plus long
> A savoir que la pente n'est pas forcément sur le coté le plus long surtout
> sur les maison de village
>
>
> Ce sont ces tags que je pensais reporter dans OSM...
>
Ok
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[osm . sanspourriel]

Pour le cadastre, sous JOSM, il y a un greffon qui te permet d'afficher 
le cadastre en fond de plan.
Vérifie le calage par rapport à des éléments existants dans OSM ou des 
orthophotographies.


Sur le côté "aider un nouveau", c'est toi qui va nous aider ;-).

Et on est toujours nouveau sur certains sujets.
Cette liste permet même de se poser des questions sur des sujets dont on 
ignorait même l'existence ! Et de progresser sur des sujets que l'on 
pensait bien connaître.


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

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[Jérôme Seigneuret]

Ca résume bien.
Jérôme

Le 8 novembre 2015 21:34, pepilepi...@ovh.fr  a écrit :

> Le 08/11/2015 12:54, Jérôme Seigneuret a écrit :
>
>
>> Mais pour la voirie ce n'est pas possible, et pas souhaitable.
>>
>> Pourquoi cette conversion est-elle déconseillée ? Je pensais que c'était
>>> à cause du nombre de points qui pourrait surcharger la base alors que si je
>>> comprends bien Jean-Claude plus il y a de points meilleur c'est...
>>>
>>
>> Un nombre de points élevé n'est pas un problème, au contraire, et ce
>> n'est pas ça qui surchargera quoi que ce soit. D'ailleurs, les traces gps
>> ne sont pas stockées dans la base Osm.
>>
>
> Mais dans la pratique la sur-qualité n'est pas utile. En dessin on utilise
> des distances de saisie cohérente avec une échelle de référence. Et les
> points distant de moins de 2 mètres ne servent à rien à mon avis. Ducoup la
> qualité va dépendre de celle des données de fond utilisé. Dans tous les cas
> le nombre de points le la trace n'est pas cohérente avec la manière de
> dessiné sur OSM mais historiquement il n'y avait que ça.
>
> Ce n'est pas conseillé, car ce n'est pas précis, et plus globalement, un
>> tracé de route va souvent avoir besoin de plus de points qu'une trace gpx
>> dans une courbe, un giratoire, et au contraire, moins de points sur les
>> lignes droites.
>
>
> Pour ce principe je supprime les points supplémentaires inutiles en ligne
> droites. Et comme précisé, contrairement au GPS, la densité de points est
> dépendante des courbes et de l'importance des angles et non pas par un pas
> de temps et un changement de cap d'où le choix de dessiner sur un trace et
> non de l'intégrer.
>
>
>>
>> Et si elle est déconseillée pourquoi des outils comme JOSM, que je pense
>>> conçu pour mettre à jour OSM, la proposent-ils ?
>>>
>>
>> Il y a plein de cas où ce genre de manip est utile.
>> Dernièrement, je devais géolocaliser des photos à l'aide d'une trace gpx,
>> mais j'ai eu besoin de la repréciser au préalable. J'ai donc fait
>> gpx->calque de données-> édition -> gpx
>> C'est un exemple parmi d'autres.
>
>
> Oui en effet et la géolocalisation directe des photos comme sur les
> smartphones (exemple d'utilisation sous Mapillary) montre des écarts plutôt
> important mais le débat sur la qualité n'est pas le sujet. En tout cas je
> préfère prendre un GPS séparé et placer les photos avec une synchronisation
> temporelle comme tu le fais.
>
>
>> Et donc en résumé, faut-il oui ou non importer des traces de bonne
>>> qualité ?
>>
>> Envoyer les traces gpx sur les serveurs Osm, oui. Les convertir en chemin
>> pour les envoyer tels quels dans la base Osm, non.
>
>
> Je complète car si l'on regarde au niveau historique le gpx était la seul
> source de données. Puis et arrivé l'othophoto et l'accord avec la DGI pour
> le cadastre.
>
> Comme dit précédemment, une seule trace GPX n'est pas suffisante pour
> définir un placement correcte. On utilise un lot de traces et le
> positionnement se fait en fonction d'une la position du plus grand nombre
> de points sur les traces pour écarter les effets de bord.
> Comprendre les limites du système permet de faire des choix. C'est pareil
> avec les autres source de données (BING et Cadastre)
>
> Donc oui il faut pousser les traces sur le serveur et même en pousser
> plusieurs. Le serveur de traces n'est pas le même et il faut mettre des
> traces qui peuvent être retraité en positionnement (correction et
> synchronisation avec un serveur servant à cela mais c'est plus du matos
> d'arpenteur) suppression de points aberrants ou coupure de la trace pour
> supprimer les zones de trou (pas de point GPS sur une longue période puis
> reprise de la position mais genre 500 m plus loin)
> Pas de simplification car c'est une dégradation de qualité. Pas de
> recalage sur une ortho car l'ortho elle-même peut avoir subit une mauvaise
> rectification (surtout en zone montagneuse)
>
>
>>
>> Merci (tant de vos infos que de votre patience avec un débutant
>>> totalement inexpérimenté)
>>>
>>
>> On a tous été débutants à un moment ou à un autre :-)
>>
>
> Et comme ça évolue on peut dire qu'on en apprend tous les jours ;-)
>
>
>
>
> En résumé je dois envoyer mes traces, je peux les convertir pour avoir une
> base MAIS il faut les retravailler manuellement pour les faire coller à la
> réalité en s'appuyant sur les vues aériennes ?
>
> Et peut-être les laisser telles quelles dans les zones boisées où on ne
> distingue pas le sentier sur les photos ?
>
> Merci,
>
> JP
>
>
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> 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] tag source:maxspeed=:zone:30

[Jérôme Seigneuret]

Je suis en parti en cause pour la France. Mais bon sur le wiki il y a
plusieurs forme (et différentes suivant les pays et même les contributeurs)

http://wiki.openstreetmap.org/wiki/Key:zone:maxspeed
http://wiki.openstreetmap.org/wiki/Key:source:maxspeed

source:maxspeed=*sign *pour les panneaux rond de vitesse (B14 pour le début
de limitation, B33 pour la fin de limitation)

source:maxspeed=*markings* pour les vitesses marquées au sol

source:maxspeed=*urban*,*rural,motorway *pour des vitesses réglementaires.

Visible sur ce panneau
http://routes.wikia.com/wiki/Limitations_de_vitesse_en_France_et_%C3%A0_l'%C3%A9tranger?file=C25a.gif

Les suisses et les belges ont un *trunk *défini sur le même type de panneau

Tous est clair sur ces points

Mais il y a un passage qui ne statut par sur le tag à utiliser pour les
zones au pas, 20, 30


   - *maxspeed
   =30 and zone:maxspeed
   =DE:zone30 - Most
   used value (used 21k times in June 2015)*

Sauf que depuis tout a été corrigé en zone:maxspeed=DE:30 > 26439 ou c'est
une erreur sur le wiki...
zone30 ne représente que 7 valeurs

Chez nous : zone:maxspeed=FR:30 > 9004



   - *maxspeed
   =30 and
source:maxspeed=DE:zone:30 -
   Second most used value (used 18k times in June 2015)*
   - *maxspeed
   =30 and
source:maxspeed=DE:zone -
   Proposed by a discussion on a mailing list citisation needed (used *


source:maxspeed=DE:zone30 > 24439
source:maxspeed=DE:zone:30 > 19631

source:maxspeed=FR:zone30 > 3911
source:maxspeed=FR:zone:30 > 32


On a ça aussi =
source:maxspeed=http://www.service-public.*fr*/actualites/007904.html


On pourrait bien avoir pour :

   - *les zones 30*

maxspeed=30
source:maxspeed=FR:zone30
zone:maxspeed=FR:30


   - *les zones de rencontre*

maxspeed=20
source:maxspeed=FR:living_street
zone:maxspeed=FR:20



   - *les aires piétonnes*

maxspeed=6
source:maxspeed=FR:walk
zone:maxspeed=FR:6

Les zones étant encadrées par des panneaux (entrée;sortie):
- zone30 : B30;B51
- living_street : B52;B53
- pedestrian : B54;B55

zone:maxspeed sert à identifier des zones et la vitesse dans la zone. La
zone n'étant pas forcément lié à une source réglemantaire comme pour les
parkings où l'on est souvent sur des zones 10km/h
source:maxspeed sert à déterminer le contexte réglementaire lié à la
vitesse en question (Si je me trompe que l'on me corrige).

Maintenant il faut choisir quoi mettre et bien le détailler dans le wiki.
On peut aussi faire comme sur les autres page en indiquant les tags à
éviter.

Bonne soirée
Jérôme


Le 8 novembre 2015 20:29, lenny  a écrit :

> Bonjour
> Je viens de découvrir, sur un highway, le tag "
> *source:maxspeed=FR:zone30"*
> Je l'ai cherché sur le wiki.
> Autant je comprend par exemple : "*maxspeed=50*" avec "
> *source:maxspeed=FR:urban"* ou "*source:maxspeed=sign"* ; par contre,
> AMHA, je ne vois pas la valeur ajouté de "*source:maxspeed=FR:zone30"*
> car, dans ce cas, la vitesse limite est toujours explicite.
>
> Mais je suis encore plus étonné par les valeurs :
> le wiki anglais propose deux possibilités (avec ou sans ":" entre "zone"
> et "30")
> "maxspeed=30 and zone:maxspeed=DE:zone30 - Most used value (used 21k times
> in June 2015)"
> "maxspeed=30 and source:maxspeed=DE:zone:30 - Second most used value (used
> 18k times in June 2015)"
>
> pareil en Allemand
> "maxspeed=30 und source:maxspeed=DE:zone30 oder DE:zone oder DE:zone:30"
>
> en Français, une seule valeur est indiquée
> "Pour taguer une zone 30, ajoutez les tags maxspeed=30 et
> source:maxspeed=:zone:30"
> et quand je vais voir taginfo, pour environ 9000  "*zone:maxspeed=FR:30*"
> "*source:maxspeed=FR:zone30*">3911
> "*source:maxspeed=FR:zone:30*">  32
> et là, la valeur proposée par le wiki est la moins utilisée ! déjà que je
> ne voyais pas ce que ce tag apportait !!!
>
> Cordialement
> Lenny
>
>
> ___
> 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] tag source:maxspeed=:zone:30

[Jérôme Amagat]

(on va dire que je dis des conneries :P)
On s'en fout des source:maxspeed= et des zone:maxspeed= ce qu'on veux c'est
savoir quelle vitesse est autorisé sur la portion de route donc le seul
truc utile c'est *maxspeed=*

Le 9 novembre 2015 00:12, Jérôme Seigneuret  a
écrit :

> Je suis en parti en cause pour la France. Mais bon sur le wiki il y a
> plusieurs forme (et différentes suivant les pays et même les contributeurs)
>
> http://wiki.openstreetmap.org/wiki/Key:zone:maxspeed
> http://wiki.openstreetmap.org/wiki/Key:source:maxspeed
>
> source:maxspeed=*sign *pour les panneaux rond de vitesse (B14 pour le
> début de limitation, B33 pour la fin de limitation)
>
> source:maxspeed=*markings* pour les vitesses marquées au sol
>
> source:maxspeed=*urban*,*rural,motorway *pour des vitesses
> réglementaires.
>
> Visible sur ce panneau
> http://routes.wikia.com/wiki/Limitations_de_vitesse_en_France_et_%C3%A0_l'%C3%A9tranger?file=C25a.gif
>
> Les suisses et les belges ont un *trunk *défini sur le même type de
> panneau
>
> Tous est clair sur ces points
>
> Mais il y a un passage qui ne statut par sur le tag à utiliser pour les
> zones au pas, 20, 30
>
>
>- *maxspeed
>=30 and zone:maxspeed
>=DE:zone30 - Most
>used value (used 21k times in June 2015)*
>
> Sauf que depuis tout a été corrigé en zone:maxspeed=DE:30 > 26439 ou
> c'est une erreur sur le wiki...
> zone30 ne représente que 7 valeurs
>
> Chez nous : zone:maxspeed=FR:30 > 9004
>
>
>
>- *maxspeed
>=30 and 
> source:maxspeed=DE:zone:30 -
>Second most used value (used 18k times in June 2015)*
>- *maxspeed
>=30 and 
> source:maxspeed=DE:zone -
>Proposed by a discussion on a mailing list citisation needed (used *
>
>
> source:maxspeed=DE:zone30 > 24439
> source:maxspeed=DE:zone:30 > 19631
>
> source:maxspeed=FR:zone30 > 3911
> source:maxspeed=FR:zone:30 > 32
>
>
> On a ça aussi =
> source:maxspeed=http://www.service-public.*fr*/actualites/007904.html
> 
>
> On pourrait bien avoir pour :
>
>- *les zones 30*
>
> maxspeed=30
> source:maxspeed=FR:zone30
> zone:maxspeed=FR:30
>
>
>- *les zones de rencontre*
>
> maxspeed=20
> source:maxspeed=FR:living_street
> zone:maxspeed=FR:20
>
>
>
>- *les aires piétonnes*
>
> maxspeed=6
> source:maxspeed=FR:walk
> zone:maxspeed=FR:6
>
> Les zones étant encadrées par des panneaux (entrée;sortie):
> - zone30 : B30;B51
> - living_street : B52;B53
> - pedestrian : B54;B55
>
> zone:maxspeed sert à identifier des zones et la vitesse dans la zone. La
> zone n'étant pas forcément lié à une source réglemantaire comme pour les
> parkings où l'on est souvent sur des zones 10km/h
> source:maxspeed sert à déterminer le contexte réglementaire lié à la
> vitesse en question (Si je me trompe que l'on me corrige).
>
> Maintenant il faut choisir quoi mettre et bien le détailler dans le wiki.
> On peut aussi faire comme sur les autres page en indiquant les tags à
> éviter.
>
> Bonne soirée
> Jérôme
>
>
> Le 8 novembre 2015 20:29, lenny  a écrit :
>
>> Bonjour
>> Je viens de découvrir, sur un highway, le tag "
>> *source:maxspeed=FR:zone30"*
>> Je l'ai cherché sur le wiki.
>> Autant je comprend par exemple : "*maxspeed=50*" avec "
>> *source:maxspeed=FR:urban"* ou "*source:maxspeed=sign"* ; par contre,
>> AMHA, je ne vois pas la valeur ajouté de "*source:maxspeed=FR:zone30"*
>> car, dans ce cas, la vitesse limite est toujours explicite.
>>
>> Mais je suis encore plus étonné par les valeurs :
>> le wiki anglais propose deux possibilités (avec ou sans ":" entre "zone"
>> et "30")
>> "maxspeed=30 and zone:maxspeed=DE:zone30 - Most used value (used 21k
>> times in June 2015)"
>> "maxspeed=30 and source:maxspeed=DE:zone:30 - Second most used value
>> (used 18k times in June 2015)"
>>
>> pareil en Allemand
>> "maxspeed=30 und source:maxspeed=DE:zone30 oder DE:zone oder DE:zone:30"
>>
>> en Français, une seule valeur est indiquée
>> "Pour taguer une zone 30, ajoutez les tags maxspeed=30 et
>> source:maxspeed=:zone:30"
>> et quand je vais voir taginfo, pour environ 9000  "*zone:maxspeed=FR:30*"
>> "*source:maxspeed=FR:zone30*">3911
>> "*source:maxspeed=FR:zone:30*">  32
>> et là, la valeur proposée par le wiki est la moins utilisée ! déjà que je
>> ne voyais pas ce que ce tag apportait !!!
>>
>> Cordialement
>> Lenny
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Tyndare]

Normalement s'ils sont alignés il sont supprimés lors de la
simplification des chemins des bâtiments, je n'ai pas tout compris à
l'algorithme de simplification de JOSM que je me suis contenté de
recopier, mais je crois que le paramètre 0.2 doit aussi correspondre à
une distance de 20cm.
J'ai corrigé quelques pb depuis vendredi (problème de projection, bug
empêchant la génération du fichier -houses-simplifie.osm pour
certaines villes),
mais n'hésitez pas a remonter ceux que vous rencontrez par un message ici ou là:
http://trac.openstreetmap.fr/newticket?component=export%20cadastre=tyndare


Le 8 novembre 2015 12:09, Gaël Simon  a écrit :
> Bonjour,
> Une source de simplification supplémentaire pourrait être de supprimer les 
> points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la 
> base avec des points inutiles, générés souvent aux limites de parcelle.
>
> Gaël


Le 8 novembre 2015 12:09, Gaël Simon  a écrit :
> Bonjour,
> Une source de simplification supplémentaire pourrait être de supprimer les 
> points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la 
> base avec des points inutiles, générés souvent aux limites de parcelle.
>
> Gaël
>
> Le 6 nov. 2015 à 23:32, Tyndare  a écrit :
>
>> Le 6 novembre 2015 22:37, David Crochet  a écrit :
>> Le 06/11/2015 21:59, Tyndare a écrit :
>>>
>>>  - merge (M) des nœuds proches (20 cm)
>>
>>
>> En gros :
>>
>> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
>> point de l'extraction de la base cadastre, alors c'est le même.
>> c'est ca ?
>
> En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
> simplification du fichier extrait du cadastre, qui contient souvent
> des points beaucoup trop proches les uns des autres pour que sa vaille
> la peine de les distinguer.
>
>>
>>>  - join (J) des nœuds au chemin proche (20 cm)
>>
>> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
>> chemin de l'extraction de la base cadastre, alors ajoute ce point au chemin,
>> comme cela la prochaine fois, ça fera simplement un "merge".
>> j'ai bien compris ?
>
> Non, il ne s'agit toujours pas de merge avec les données de la base OSM.
> Le merge est un sujet bien plus compliqué qui est traité ici:
> - https://github.com/jecor/bati-fusion
> ou là:
> - https://github.com/sebastien-bugzilla/BatiOsm
>
> Ici je ne parle toujours que d'extraction brute des données du
> cadastre, rien de changé par rapport a avant.
>
>>
>>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
>>
>> en d'autres termes ?
>
> Je fais juste référence à la fonction JOSM de simplification des
> chemins, comme expliqué sur le Wiki d'import semi automatique du bâti:
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents
>
> ___
> 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

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