Re: [OSM-talk-fr] Import massif dans OSM

[Jérôme Seigneuret]

Oui c'est faisable sous Josm et en important les données osm existante avec
overpass. Le plugin conflate est ton ami

Le sam. 1 févr. 2020 à 10:12, Cédric Frayssinet  a
écrit :

> Bonjour à tous,
>
> Les 2 associations lyonnaises Pleinlavue et RAP ont obtenu de la part de
> la Métropole de Lyon, le fichier des implantations des panneaux
> publicitaires (joliment appelé mobilier urbain), notamment JCDecaux :
> https://data.grandlyon.com/jeux-de-donnees/mobilier-urbain-metropole-lyon/donnees
>
> C'est très complet. Actuellement, nous en sommes là au niveau cartographie
> : https://openadvertmap.pavie.info/#15/45.7649/4.8400 (que nous réalisons
> avec MapContrib).
>
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.
>
> Question 1 : est-ce faisable ?
>
> Question 2 : qui aurait une expertise là dessus pour nous aider ?
>
> Merci d'avance,
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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 massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[marc marc]

ce sont 2 questions séparéees :)
avoir conflate qui fait le taf, ne te met pas à l'abri de quelqu'un
qui estimerait que 2700 objets dans une aglo est un import.
autant une 100aine d'objets, bah, ca passe.
autant pour des milliers, franchement autant faire les choses bien.
surtout qu'avant cela, ce ne serrait pas du luxe de passer les tags en
revue (je dis cela en venant de voir un mapcontrib... améliorable)

Le 02.02.20 à 14:11, Cédric Frayssinet a écrit :
> 
> Merci pour vos différentes réponses. Il semble donc que conflate puisse
> faire le taf' correctement, sans nécessairement avertir la liste import :)
> 
> Je vais me rapprocher des experts JOSM lyonnais !
> 
> Cédric
> 
> 
> 
> Le 01/02/2020 à 11:35, Vincent Bergeot a écrit :
>> Le 01/02/2020 à 11:11, Christian Quest a écrit :
>>> Le 01/02/2020 à 11:03, marc marc a écrit :
 Bonjour,

 Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.
 de combien d'objet parle-t-on environ ?
>>>
>>>
>>> Quelques centaines à ce que j'ai rapidement vu... pas de quoi
>>> déballer la grosse artillerie ou réveiller les troll de la liste
>>> imports ;)
>>
>>
>> 2700 objets si qgis compte bien
>>
>>>
>>> 1) Vérifier la qualité en comparant avec l'existant, et aussi en
>>> comparant un peu avec le terrain.
>>
>> c'était l'idée avec osmose, car cela peut permettre de comparer et
>> comme ce travail dans osm a été mené dans plusieurs villes, cela
>> pourrait "s'étendre"plus facilement !
>>
>>
>>>
>>> Ceci peut éventuellement l'occasion de faire une cartopartie thématique.
>>
>> +1, j'ai l'impression que les RAP sont bien partants et motivés en
>> plus ! (d'ailleurs Cédric, tu pourrais me mettre en lien avec une
>> personne sur Bordeaux ? par de réponse par leur page de contact !)
>>
>>>
>>> 2) Un bon coup de conflate dans JOSM
>>
>> oui, peut permettre d'aller plus vite
>>
>> oserai-je dire que la question de la ref est à poser ?
>>
>> à plus
>>
>>
> 
> -- 
> 
> Sur Mastodon : @bristow...@framapiaf.org 
> 
> Promouvoir et soutenir le logiciel libre 
> 
> 
> ___
> 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 massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[Cédric Frayssinet]

Merci pour vos différentes réponses. Il semble donc que conflate puisse
faire le taf' correctement, sans nécessairement avertir la liste import :)

Je vais me rapprocher des experts JOSM lyonnais !

Cédric



Le 01/02/2020 à 11:35, Vincent Bergeot a écrit :
> Le 01/02/2020 à 11:11, Christian Quest a écrit :
>> Le 01/02/2020 à 11:03, marc marc a écrit :
>>> Bonjour,
>>>
>>> Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :
 Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
 tout en n'écrasant par les différents POI qui pourraient exister.
>>> de combien d'objet parle-t-on environ ?
>>
>>
>> Quelques centaines à ce que j'ai rapidement vu... pas de quoi
>> déballer la grosse artillerie ou réveiller les troll de la liste
>> imports ;)
>
>
> 2700 objets si qgis compte bien
>
>>
>> 1) Vérifier la qualité en comparant avec l'existant, et aussi en
>> comparant un peu avec le terrain.
>
> c'était l'idée avec osmose, car cela peut permettre de comparer et
> comme ce travail dans osm a été mené dans plusieurs villes, cela
> pourrait "s'étendre"plus facilement !
>
>
>>
>> Ceci peut éventuellement l'occasion de faire une cartopartie thématique.
>
> +1, j'ai l'impression que les RAP sont bien partants et motivés en
> plus ! (d'ailleurs Cédric, tu pourrais me mettre en lien avec une
> personne sur Bordeaux ? par de réponse par leur page de contact !)
>
>>
>> 2) Un bon coup de conflate dans JOSM
>
> oui, peut permettre d'aller plus vite
>
> oserai-je dire que la question de la ref est à poser ?
>
> à plus
>
>

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[Vincent Bergeot]

Le 01/02/2020 à 11:11, Christian Quest a écrit :

Le 01/02/2020 à 11:03, marc marc a écrit :

Bonjour,

Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :

Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
tout en n'écrasant par les différents POI qui pourraient exister.

de combien d'objet parle-t-on environ ?



Quelques centaines à ce que j'ai rapidement vu... pas de quoi déballer 
la grosse artillerie ou réveiller les troll de la liste imports ;)



2700 objets si qgis compte bien



1) Vérifier la qualité en comparant avec l'existant, et aussi en 
comparant un peu avec le terrain.


c'était l'idée avec osmose, car cela peut permettre de comparer et comme 
ce travail dans osm a été mené dans plusieurs villes, cela pourrait 
"s'étendre"plus facilement !





Ceci peut éventuellement l'occasion de faire une cartopartie thématique.


+1, j'ai l'impression que les RAP sont bien partants et motivés en plus 
! (d'ailleurs Cédric, tu pourrais me mettre en lien avec une personne 
sur Bordeaux ? par de réponse par leur page de contact !)




2) Un bon coup de conflate dans JOSM


oui, peut permettre d'aller plus vite

oserai-je dire que la question de la ref est à poser ?

à plus


--
Vincent Bergeot


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

Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[Christian Quest]

Le 01/02/2020 à 11:03, marc marc a écrit :

Bonjour,

Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :

Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
tout en n'écrasant par les différents POI qui pourraient exister.

de combien d'objet parle-t-on environ ?



Quelques centaines à ce que j'ai rapidement vu... pas de quoi déballer 
la grosse artillerie ou réveiller les troll de la liste imports ;)


1) Vérifier la qualité en comparant avec l'existant, et aussi en 
comparant un peu avec le terrain.


Ceci peut éventuellement l'occasion de faire une cartopartie thématique.

2) Un bon coup de conflate dans JOSM


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[Vincent Bergeot]

Le 01/02/2020 à 11:03, marc marc a écrit :

Bonjour,

Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :

Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
tout en n'écrasant par les différents POI qui pourraient exister.

de combien d'objet parle-t-on environ ?


Question 1 : est-ce faisable ?

oui.
il y 2 pistes :
- soit josm avec l'outil conflate. il permet de rapprocher des objets
présent dans une source externe de ceux existant dans osm selon des
critères et la distance.
- soit il faut un outil plus spécialisé. certains ici en ont écrit pour
l'import d'arbres. il y a aussi celui de Zverik + prévu pour qu'un
groupe passe en revue les données avec l'aide de l'imagerie (mais
ce n'est adapté que si on voit les gros panneaux sur l'imagerie).

avant tout import proprement dit, il faut :
- vérifier la qualité de positionnement de l'opendata en comparant
les objets existant dans osm et ceux correspondant en opendata.
le plugin josm conflate le permet. il permettra d'avoir facilement
une idée de la qualité (distance osm<>opendata)
- il faudra obtenir l'accord de la communauté locale (ici cela
convient sans doute aussi) et de la liste import.
pour ce derrnier point, je te conseille de ne le faire que
quand tout est tip-top (tag passé en revue, accord local,
test de qualité, ...) parce qu'il y a des champions des cheveux coupés
en 4 là-bas, alors autant ne pas leur donner des raisons de critiquer :)


Question 2 : qui aurait une expertise là dessus pour nous aider ?

avec conflate oui (même si j'utilise souvent les valeurs par défaut)
avec d'autres outils : d'autres plus d'expérience que moi là dessus.



selon les réponses à ces questions, ne pas oublier osmoseOD. Cela peut 
permettre de faire les rapprochements avec l'existant, l'intégration de 
nouveaux POI et de suivre la mise à jour les données.


Il y a un travail préalable à faire de rapprochement entre les données 
ouvertes et les données osm pour qu'osmose-OD bosse derrière.


à plus


--
Vincent Bergeot


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

Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

[marc marc]

Bonjour,

Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.

de combien d'objet parle-t-on environ ?

> Question 1 : est-ce faisable ?

oui.
il y 2 pistes :
- soit josm avec l'outil conflate. il permet de rapprocher des objets
présent dans une source externe de ceux existant dans osm selon des
critères et la distance.
- soit il faut un outil plus spécialisé. certains ici en ont écrit pour
l'import d'arbres. il y a aussi celui de Zverik + prévu pour qu'un
groupe passe en revue les données avec l'aide de l'imagerie (mais
ce n'est adapté que si on voit les gros panneaux sur l'imagerie).

avant tout import proprement dit, il faut :
- vérifier la qualité de positionnement de l'opendata en comparant
les objets existant dans osm et ceux correspondant en opendata.
le plugin josm conflate le permet. il permettra d'avoir facilement
une idée de la qualité (distance osm<>opendata)
- il faudra obtenir l'accord de la communauté locale (ici cela
convient sans doute aussi) et de la liste import.
pour ce derrnier point, je te conseille de ne le faire que
quand tout est tip-top (tag passé en revue, accord local,
test de qualité, ...) parce qu'il y a des champions des cheveux coupés
en 4 là-bas, alors autant ne pas leur donner des raisons de critiquer :)

> Question 2 : qui aurait une expertise là dessus pour nous aider ?

avec conflate oui (même si j'utilise souvent les valeurs par défaut)
avec d'autres outils : d'autres plus d'expérience que moi là dessus.

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

Re: [OSM-talk-fr] Import massif Canada

[Philippe Verdy]

Apparemment ce sont des noeuds destinés à tracer des landuse. Mais 19000+
noeuds importés pour l'instant sans aucun way pour les connecter. Ca va
être des polygones géants, ou alors les ways arrivent tout à la fin et non
au fur et à mesure de la progression...
Regarde ce qui s'est fait déjà à Thunder Bay.


Le 7 octobre 2013 17:01, Simon Miniou simon.min...@gmail.com a écrit :

 Bonjour, avis au expert ;

 en regardant le live,
 je suis tombé sur un import massif Importing Canvec 052B12.0.2
 http://www.openstreetmap.org/browse/changeset/18230862
 http://www.openstreetmap.org/user/Sanjak
 ça vous dis quelque chose ; les canadiens à contacter?
 pour l'instant que des points sans tag on été importés c'est peut être une
 erreur?

 ++
 Simon

 ___
 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 massif Canada

[V de Chateau-Thierry]

 De : Simon Miniou

je suis tombé sur un import massif Importing Canvec 052B12.0.2
 http://www.openstreetmap.org/browse/changeset/18230862
 http://www.openstreetmap.org/user/Sanjak

ça vous dis quelque chose ; les canadiens à contacter?


Le changeset que tu pointes n'était pas encore complet, il l'est désormais : il 
y a
de quoi fabriquer de gros multipolygons d'occupation du sol.
Si tu regarde ses précédentes contributions, elles sont de même nature (gros 
volume, même
source citée en commentaire). 

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] Import Massif

[sly (sylvain letuffe)]

 à mon avis, le plus important c'est de respecter le travail des autres. 
+1
 - évitons d'importer massivement si ça risque de créer des doublons : ça 
 dévalorise le travail déjà fait
+1

Avant un import massif quel qu'il soit, je pense que la première chose c'est 
d'obtenir un échantillon (ou mieux la totalité) de la donnée à importer, 
venir le présenter ici pour que tout le monde se fasse un avis de sa qualité, 
le comparer aux choses qu'il connaît dans son coin (je peux mettre en oeuvre 
une visualisation des données en sur-couches à OSM pour mieux se rendre 
compte) et de là prendre une décision sur la manière d'importer, où pas.

J'ai vu moulte données qui font référence (il paraît) s'avérer plutôt 
médiocre, et, bien que plus exhaustives, ne pas mériter remplacer les données 
déjà dans OSM
(Je pense aux réserves naturelles distribuées sur le site de l'inpn par 
exemple)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Import Massif

[Guillaume Allegre]

Le sam. 05 nov. 2011 à 00:22 +0100, Eric SIBERT a ecrit :
 ahh et donc concrètement, ca se passerait comment?
 Voilà, imaginons que j'ai 1000 traces GPS de randonneurs et que la license
 est ok...j'en fais quoi, je les donne à qui, je les upload où, qui peut les
 utiliser et comment?
 
 Manuellement, sur le site web d'osm, il y a un onglet Traces GPS.
 Dans l'onglet, un lien Envoyer une trace. Ça peut aussi se faire
 avec l'outil JOSM. Il y a sans doute un moyen de le faire en plus
 automatisé avec l'API d'OSM.

Oui, et d'ailleurs, dans la pratique si Pascal trouve vraiment 1000 traces GPS à
importer en bloc avec une licence compatible ODbL, on trouvera bien quelqu'un
ici pour se charger d'écrire la moulinette.


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr

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

Re: [OSM-talk-fr] Import Massif

[Romain MEHUT]

Bonsoir Pascal,

Importer des traces GPS brutes seraient effectivement une très bonne idée.
En soit, cela ne crée pas de la données dans OSM mais c'est un support non
négligeable (en plus de l'imagerie satellitaire) pour tracer des chemins...

Perso, en pratique, quand j'enregistre une trace GPS, je fais un aller puis
un retour afin de pouvoir faire une moyenne. Avoir d'autres traces GPS
diminuerait encore le niveau d'erreur. Néanmoins, dans mon coin l'imagerie
Bing est de qualité donc ça facilite beaucoup le travail en terrain
découvert.

Quant aux tags sac_scale et mtb, ils ne définissent pas un parcours
pédestre ou VTT mais son niveau de difficulté pour ces usages. Voici un
exemple http://openmtbmap.org/ qui exploite ces tags.

Pour définir un parcours VTT ou pédestre, il faut passer par une relation
comme dans ce cas: http://www.openstreetmap.org/browse/relation/1830503

Romain

Le 5 novembre 2011 00:46, darrepac pascal.da...@laposte.net a écrit :


 ahmster wrote:
 
  dans JOSM quand tu charge les donnees d'une zone t'a une case a cocher
  pour charger aussi les traces GPS
 
 Merci pour toutes ces précisions et aussi pour cette info (car c'est le
 même
 principe dans Merkaator)

 Pascal

 --
 View this message in context:
 http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964559.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] Import Massif

[Etienne Trimaille]

Le 5 novembre 2011 22:29, Guillaume Allegre allegre.guilla...@free.fr a
écrit :

 on trouvera bien quelqu'un ici pour se charger d'écrire la moulinette.


J'ai déjà vu une moulinette tourner sur l'import de traces gps dans osm. Il
faut peut-être aller voir du côté des allemands d'après mes souvenirs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import Massif

[Eric SIBERT]

Tient, d'ailleurs, à propos des traces GPS stockées dans OSM, il y a un 
truc pas pratique quand on veut récupérer les traces d'une zone. Le 
résultat de la requête sur le serveur est un fichier GPX. Sauf que dans 
ce fichier, toutes les traces en visibilité Public se retrouvent 
concaténées en une seule trace. On peut d'ailleurs le voir dans Potlatch 
ou Josm. Sur une autoroute, en bord d'écran, il y a des segments qui 
rejoignent les deux sens de circulation. Ce n'est pas pratique pour 
faire des traitements. Je ne sais pas si ça peut faire partie des 
demandes pour la future API ou ailleurs.


Éric

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Sur Merkaartor, je crois avoir vu que les traces arrivaient separées.

Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6966812.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Bon je relance un peu le sujet après avoir fait pas mal (à mon niveau) de
modifs OSM aujourd'hui et notamment rentrer des sentiers (beau bordel je
trouve pour bien définir un sentier et notamment son usage à la fois rando
et à la fois vtt mais passons).
J'ai aussi comparé avec la BDTopo de l'IGN pour voir à quel point OSM en est
loin ou pas.

Cela m'a fait penser à un point qui mélange quantité et qualité.
- Si je passe sur un sentier avec un GPS et que je veux vérifier son état
dans OSM. Même si le sentier existe déjà, forcément les 2 tracés ne vont pas
parfaitement se superposer (erreur du GPS) même si les 2 traces sont de
qualités (ce qui déjà n'est pas toujours le cas dans ce que j'ai pu voir).
Comment faites-vous dans ce cas? Vous êtes obligés soit de garder la trace
courante soit la remplacer par la nouvelle soit faire une sorte de moyenne
visuelle et de rentrer les points entre les 2 tracés (why not)...dans tous
les cas, pas très satisfaisant (qualitativement parlant).
- Les sentiers, chemins, routes sont avant tout des highways et
finalement, à mon avis, il serait bon d'avoir une base riche et qualitative
(au sens précision du tracé) de ces voies et ensuite d'enrichir les
attributs au fur et à mesure (et c'est déjà le cas actuellement où plein de
voies ont des attributs incomplets).

Des 2 aspects précédents, je me dis que si je récupère une base de données
très riche de trace GPS de sentiers (donc utilisateur randonneur ou
VTTiste), je peux grâce à la quantité de donnée et donc au moyennage de ces
traces (y a qu'à voir sur le site vttrack.fr pour voir comment sur certaines
zones 10 traces d'utilisateur passent au même endroit) avoir un maillage
quantitatif (car milliers de traces) et qualitatif (car bien meilleur que le
passage d'un seul GPS).
J'ai fait le test sur une sortie avec 17 GPS (!) dans les Alpes Maritimes,
le résultat du maillage est époustouflant: fini les points d'errement, fini
l'impossibilité de savoir exactement ou le sentier fait ses lacés etc...le
rendu était très très net et d'ailleurs quasi superposable sur le sentier de
la carte IGN.
Comment faire le maillage/moyenne? J'ai utilise Topofusion perso
(http://www.topofusion.com/) mais l'algorithme de moyennage ne semble pas
compliquer à refaire dans n'importe quel langage
(http://www.topofusion.com/network.php)

Je suis encore à l'ouest par rapport à la philosophie OSM?
Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964370.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[hamster]

Le 04/11/2011 23:18, darrepac a écrit :

Bon je relance un peu le sujet après avoir fait pas mal (à mon niveau) de
modifs OSM aujourd'hui et notamment rentrer des sentiers (beau bordel je
trouve pour bien définir un sentier et notamment son usage à la fois rando
et à la fois vtt mais passons).


une regle dans OSM est de decrire le terrain au mieux, mais pas son usage
une piste de kart, qui est par essence construite et reservee pour les 
karts, on va mettre que c'est une piste de kart, mais un chemin on va 
pas mettre si c'est un chemin de VTT ou de rando, on va mettre que c'est 
un chemin, avec eventuellement une description de son etat de surface


si des gens veulent faire des traces de chemins avec dans l'idee l'usage 
VTT, ils peuvent le faire dans une base de donnees separee


si on veut decrire dans OSM des itineraires pietons, et des itineraires 
VTT, ou meme des itineraires de lignes de bus, on le fait en faisant des 
relations qui contiennent tous les bouts de chemins par ou passe 
l'itineraire


mais dans OSM ca n'a de sens que si l'itineraire existe sur le terrain, 
par exemple avec une signalisation qui le balise



J'ai aussi comparé avec la BDTopo de l'IGN pour voir à quel point OSM en est
loin ou pas.

Cela m'a fait penser à un point qui mélange quantité et qualité.
- Si je passe sur un sentier avec un GPS et que je veux vérifier son état
dans OSM. Même si le sentier existe déjà, forcément les 2 tracés ne vont pas
parfaitement se superposer (erreur du GPS) même si les 2 traces sont de
qualités (ce qui déjà n'est pas toujours le cas dans ce que j'ai pu voir).
Comment faites-vous dans ce cas? Vous êtes obligés soit de garder la trace
courante soit la remplacer par la nouvelle soit faire une sorte de moyenne
visuelle et de rentrer les points entre les 2 tracés (why not)...dans tous
les cas, pas très satisfaisant (qualitativement parlant).


un chemin dans OSM n'est jamais l'importation brute d'une trace GPS : 
c'est trop imprecis


si on n'a qu'une trace GPS, on dessine a la main un chemin qui passe 
dessus au mieux en lissant les aleas dus a l'iprecision du GPS


si il y a deja plusieurs traces et qu'on en rajoute une, on dessine a la 
main un chemin qui passe au mieux dans le gros du paquet de traces, en 
ignorant les aleas des GPS et les traces erratiques


si il y a deja un chemin trace et qu'on rajoute une trace, la flemme 
commande de ne modifier le chemin existant que la ou la trace montre 
qu'on peut l'ameliorer


dans tous les cas c'est pas plus mal de recouper plusieurs sources 
d'infos, par exemple tracer un chemin sur une trace GPS avec une photo 
satellite en fond d'ecran



- Les sentiers, chemins, routes sont avant tout des highways et
finalement, à mon avis, il serait bon d'avoir une base riche et qualitative
(au sens précision du tracé) de ces voies et ensuite d'enrichir les
attributs au fur et à mesure (et c'est déjà le cas actuellement où plein de
voies ont des attributs incomplets).


la je comprend pas de quoi tu parle

les grosses routes sont des highway=primary, les petites sont des 
highway=unclassified, les chemins sont des highway=path, etc...


que veux tu dire par base des voies et par enrichir les attributs au 
fur et a mesure ?



Des 2 aspects précédents, je me dis que si je récupère une base de données
très riche de trace GPS de sentiers (donc utilisateur randonneur ou
VTTiste), je peux grâce à la quantité de donnée et donc au moyennage de ces
traces (y a qu'à voir sur le site vttrack.fr pour voir comment sur certaines
zones 10 traces d'utilisateur passent au même endroit) avoir un maillage
quantitatif (car milliers de traces) et qualitatif (car bien meilleur que le
passage d'un seul GPS).
J'ai fait le test sur une sortie avec 17 GPS (!) dans les Alpes Maritimes,
le résultat du maillage est époustouflant: fini les points d'errement, fini
l'impossibilité de savoir exactement ou le sentier fait ses lacés etc...le
rendu était très très net et d'ailleurs quasi superposable sur le sentier de
la carte IGN.
Comment faire le maillage/moyenne?


a la main, en dessinant un chemin qui passe au mieux sur le troupeau de 
traces


OSM est un travail de fourmis, qui n'est possible que parce que les 
fourmis sont nombreuses


si on a une grande quantite de traces GPS disponibles et donc pas le 
temps de les tracer toutes une a une, on les uploade dans OSM, ca permet 
a d'autres de les voir et de tracer les chemins en se servant de ces traces


du coup peut etre que je comprend mieux la question precedente : 
importer un grand nombre de traces de facon automatique sans y mettre de 
tags ou un tag generique (il y a highway=road pour ca) en se disant 
qu'on mettra bien les bons tags plus tard, ca c'est clairement pas dans 
les us et coutumes



J'ai utilise Topofusion perso
(http://www.topofusion.com/) mais l'algorithme de moyennage ne semble pas
compliquer à refaire dans n'importe quel langage
(http://www.topofusion.com/network.php)

Je suis encore à l'ouest par rapport à la 

Re: [OSM-talk-fr] Import Massif

[Eric SIBERT]

- Les sentiers, chemins, routes sont avant tout des highways et
finalement, à mon avis, il serait bon d'avoir une base riche et qualitative
(au sens précision du tracé) de ces voies et ensuite d'enrichir les
attributs au fur et à mesure (et c'est déjà le cas actuellement où plein de
voies ont des attributs incomplets).


Ce concept d'incomplet/complet ne colle pas du tout avec OSM en tant que 
projet ouvert. Chacun a sa propre notion de complétude qu'elle soit en 
terme de précision ou en terme de tag. Et il n'y a pas de référentiel 
global à atteindre. Moi, par exemple, j'aimerais bien avoir toute la 
voirie en France avec connectivité, nom, ref et restrictions diverses. 
D'autre vont surtout être intéressé par l'état de cette voirie pour 
faire du vélo ou du roller, sa dangerosité... Donc dire qu'on finit 
quelque chose (les tracés avec un niveau de précision donné dans ton 
cas) avant de passer aux tags n'a pas de sens du point de vue OSM.


Par contre, chacun particulier ou entreprise peut de fixer des objectifs 
d'exhaustivité sur un aspect. Les allemands (entre autre) ont atteint 
exhaustivité pour la voirie.




Des 2 aspects précédents, je me dis que si je récupère une base de données
très riche de trace GPS de sentiers (donc utilisateur randonneur ou
VTTiste), je peux grâce à la quantité de donnée et donc au moyennage de ces
traces [...] avoir un maillage
quantitatif (car milliers de traces) et qualitatif (car bien meilleur que le
passage d'un seul GPS).


Oui. Beaucoup de traces GPS peuvent aider le travail des mappeurs. Si tu 
trouves un ou plusieurs site de randonneurs, vttistes et autres qui 
veulent verser leurs traces à OSM dans une licence compatible, ça sera 
toujours bienvenu.




Comment faire le maillage/moyenne? J'ai utilise Topofusion perso
(http://www.topofusion.com/) mais l'algorithme de moyennage ne semble pas
compliquer à refaire dans n'importe quel langage
(http://www.topofusion.com/network.php)


Des outils pour faire des moyennes de trace GPS seraient intéressants 
même pour les traces déjà disponibles dans le projet. J'avais déjà 
regardé des algorithmes pour faire des moyennes. Même si en première 
lecture, ça paraissait simple, dans les détails, ça se compliquait et je 
ne me suis pas lancé dans la programmation.


http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.5216

Éric

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

ahmster wrote:
 
 Le 04/11/2011 23:18, darrepac a écrit :
 Bon je relance un peu le sujet après avoir fait pas mal (à mon niveau) de
 modifs OSM aujourd'hui et notamment rentrer des sentiers (beau bordel je
 trouve pour bien définir un sentier et notamment son usage à la fois
 rando
 et à la fois vtt mais passons).
 
 une regle dans OSM est de decrire le terrain au mieux, mais pas son usage
 une piste de kart, qui est par essence construite et reservee pour les 
 karts, on va mettre que c'est une piste de kart, mais un chemin on va 
 pas mettre si c'est un chemin de VTT ou de rando, on va mettre que c'est 
 un chemin, avec eventuellement une description de son etat de surface
 
Euh, c'est pas moi qui est inventé le tag sac_scale et mtb ...du coup, toi
tu dis qu'il faut pas les utiliser? je mets juste highway=path et basta?



 un chemin dans OSM n'est jamais l'importation brute d'une trace GPS : 
 c'est trop imprecis
 
Je veux bien te croire mais dans la réalité de ce que j'ai vu aujourd'hui,
ma trace GPS était bien plus précise que certains sentiers marqués...et
globalement, une trace GPS de qualité (fréquence d'échantillonage suffisant
etc) me semble être tout à fait une bonne référence pour des sentiers




 si on a une grande quantite de traces GPS disponibles et donc pas le 
 temps de les tracer toutes une a une, on les uploade dans OSM, ca permet 
 a d'autres de les voir et de tracer les chemins en se servant de ces
 traces
 
ok donc j'ai loupé ca: on peut mettre plein de trace GPS et tout le monde
peut les voir sans que ce soit rentré dans la carte? comment ca marche?

Pascal


--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964503.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Eric Sibert wrote:
 
 Des 2 aspects précédents, je me dis que si je récupère une base de
 données
 très riche de trace GPS de sentiers (donc utilisateur randonneur ou
 VTTiste), je peux grâce à la quantité de donnée et donc au moyennage de
 ces
 traces [...] avoir un maillage
 quantitatif (car milliers de traces) et qualitatif (car bien meilleur que
 le
 passage d'un seul GPS).
 
 Oui. Beaucoup de traces GPS peuvent aider le travail des mappeurs. Si tu 
 trouves un ou plusieurs site de randonneurs, vttistes et autres qui 
 veulent verser leurs traces à OSM dans une licence compatible, ça sera 
 toujours bienvenu.
 
ahh et donc concrètement, ca se passerait comment?
Voilà, imaginons que j'ai 1000 traces GPS de randonneurs et que la license
est ok...j'en fais quoi, je les donne à qui, je les upload où, qui peut les
utiliser et comment?

Pascal


--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964511.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[Jean-Marc Liotier]

On 11/05/2011 12:15 AM, darrepac wrote:
 on peut mettre plein de trace GPS et tout le monde
 peut les voir sans que ce soit rentré dans la carte ?
 comment ca marche ?

http://www.openstreetmap.org/traces

On charge une trace sur le site, on choisit si elle est privée ou
publique, anonyme ou pas, on l'étiquette et on la décrit... Et elle
devient disponible dans le calque des traces GPS dans tous les bons
éditeurs. On peut ainsi voir toutes les traces publiques ainsi que ses
propres traces privées et s'en servir pour mieux positionner les
éléments de la carte.

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

Re: [OSM-talk-fr] Import Massif

[Eric SIBERT]

ahh et donc concrètement, ca se passerait comment?
Voilà, imaginons que j'ai 1000 traces GPS de randonneurs et que la license
est ok...j'en fais quoi, je les donne à qui, je les upload où, qui peut les
utiliser et comment?


Manuellement, sur le site web d'osm, il y a un onglet Traces GPS. Dans 
l'onglet, un lien Envoyer une trace. Ça peut aussi se faire avec l'outil 
JOSM. Il y a sans doute un moyen de le faire en plus automatisé avec 
l'API d'OSM.


Eric

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Jean-Marc Liotier wrote:
 
 
 http://www.openstreetmap.org/traces
 
 On charge une trace sur le site, on choisit si elle est privée ou
 publique, anonyme ou pas, on l'étiquette et on la décrit... Et elle
 devient disponible dans le calque des traces GPS dans tous les bons
 éditeurs. On peut ainsi voir toutes les traces publiques ainsi que ses
 propres traces privées et s'en servir pour mieux positionner les
 éléments de la carte.
 
 
Ben voilà, j'avais pas vu qu'on pouvait avoir un calque avec toutes les
traces publiquesd'ailleurs j'ai pas trouvé comment dans Merkaartor mais
je vais chercher!

Pascal


--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964532.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[hamster]

Le 05/11/2011 00:15, darrepac a écrit :


ahmster wrote:


Le 04/11/2011 23:18, darrepac a écrit :

Bon je relance un peu le sujet après avoir fait pas mal (à mon niveau) de
modifs OSM aujourd'hui et notamment rentrer des sentiers (beau bordel je
trouve pour bien définir un sentier et notamment son usage à la fois
rando
et à la fois vtt mais passons).


une regle dans OSM est de decrire le terrain au mieux, mais pas son usage
une piste de kart, qui est par essence construite et reservee pour les
karts, on va mettre que c'est une piste de kart, mais un chemin on va
pas mettre si c'est un chemin de VTT ou de rando, on va mettre que c'est
un chemin, avec eventuellement une description de son etat de surface


Euh, c'est pas moi qui est inventé le tag sac_scale et mtb ...du coup, toi
tu dis qu'il faut pas les utiliser? je mets juste highway=path et basta?


ces tags sont des descriptions de la difficulte du chemin ou de 
l'itineraire, exprimes selon divers criteres, c'est donc bien des 
descriptions du terrain et non pas de l'usage qui en est fait

ces tags ne signifient pas qu'il s'agit de chemins pour VTT ou pour la rando

par exemple il n'est pas du tout interdit de mettre un tag mtb-scale sur 
un escalier (on pourrait meme en mettre sur les autoroutes mais j'ai des 
doutes sur l'interet de le faire)



un chemin dans OSM n'est jamais l'importation brute d'une trace GPS :
c'est trop imprecis


Je veux bien te croire mais dans la réalité de ce que j'ai vu aujourd'hui,
ma trace GPS était bien plus précise que certains sentiers marqués...et
globalement, une trace GPS de qualité (fréquence d'échantillonage suffisant
etc) me semble être tout à fait une bonne référence pour des sentiers


je disais cela non pas a cause de la precision mais a cause des tags a 
mettre, de la connexion avec les autres chemins, etc... difficle a faire 
de facon automatique


maintenant si tu utilise un algorythme pour faire des moyennes de traces 
GPS et que tu reprend les chemins ainsi dessines pour rajouter les bons 
tags, les connecter aux croisements, leur mettre bridge=yes et layer=1 
quand ils passent au dessus d'un ruisseau, les fusionner avec les 
chemins preexistants quand y'en a et regler tous les petits details de 
ce genre, tant mieux, publie ton soft il servira a d'autres



si on a une grande quantite de traces GPS disponibles et donc pas le
temps de les tracer toutes une a une, on les uploade dans OSM, ca permet
a d'autres de les voir et de tracer les chemins en se servant de ces
traces


ok donc j'ai loupé ca: on peut mettre plein de trace GPS et tout le monde
peut les voir sans que ce soit rentré dans la carte? comment ca marche?


dans JOSM quand tu charge les donnees d'une zone t'a une case a cocher 
pour charger aussi les traces GPS

pour envoyer tes traces dans OSM je sait pas, j'ai jamais fait

de facon generale une carte (et pas LA carte) est un rendu graphique 
fait a partir d'une selection d'infos, mais la base de donnees est bien 
plus riche que ce qui est dessine sur la carte, trop riche pour qu'on 
puisse raisonnablement esperer faire une carte qui represente toutes ces 
infos


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

Re: [OSM-talk-fr] Import Massif

[hamster]

Le 05/11/2011 00:07, Eric SIBERT a écrit :

Donc dire qu'on finit
quelque chose (les tracés avec un niveau de précision donné dans ton
cas) avant de passer aux tags n'a pas de sens du point de vue OSM.


et j'ajoute que planifier la realisation de travaux dans un certain 
ordre est totalement orthogonal au fonctionnement d'OSM : chaque mappeur 
fait ce qu'il lui plait de faire quand il est motive pour le faire


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

Re: [OSM-talk-fr] Import Massif

[f . dos . santos]

Selon darrepac pascal.da...@laposte.net:

 
 Ben voilà, j'avais pas vu qu'on pouvait avoir un calque avec toutes les
 traces publiquesd'ailleurs j'ai pas trouvé comment dans Merkaartor mais
 je vais chercher!

 Pascal

Dans Merkaartor : Telecharger - cocher Télécharger aussi les traces GPS brutes

Autre point à vérifier aussi dans Merkaartor : Outils - Préférences - onglet
Données - case à cocher Couches de traces en lecture seule par défaut
Sinon les points de traces sont selectionnable ce qui est assez emmerdant pour
selectionner la voirie quand on a beaucoup de traces.

Francisco

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

ahmster wrote:
 
 dans JOSM quand tu charge les donnees d'une zone t'a une case a cocher 
 pour charger aussi les traces GPS
 
Merci pour toutes ces précisions et aussi pour cette info (car c'est le même
principe dans Merkaator)

Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6964559.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[Vincent Pottier]

Le 02/11/2011 14:55, darrepac a écrit :
Bien le bonjour,

Comment avez-vous fait pour les données Corinne Land Cover ou pour les
données des bâtiments? bâtiments par bâtiment ou un import global avec
post-vérification?
La post-vérification, c'est une vision de l'esprit. On n'aime pas 
beaucoup... Dans OSM, on met des données qui sont bonnes (même si elles 
peuvent gagner en qualité par la suite, comme les polygones Corine). Si 
les données ne sont pas bonnes, on les corrige avant.


Pour Corine, ce fut des pré-vérifications... et quand ce fut prêt, ce 
fut bon.
Pour le bâti du cadastre, c'est de l'import manuel assisté. On 
regrette que beaucoup trop pensent post-vérification (si possible par 
d'autres que par moi-même) et non pas pré-vérification : doublons, 
superposition...

Merci pour vos lumières
Pascal


De Rien
--
FrViPofm

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

Re: [OSM-talk-fr] Import Massif

[Ab_fab]

Bonjour,

Les données disponibles peuvent être en accès libre sur le net, mais non
libérées explicitement pour une réutilisation et en particulier pour une
réutilisation commerciale.
La restriction de réutilisation pour un usage commercial est souvent ce qui
empèche l'import dans OSM. Il faut faire preuve de beaucoup de pédagogie
pour faire comprendre que ce n'est pas un risque inconsidéré d'autoriser ce
genre de choses.
Comme tu le dis, l'opendata est une lame de fond et il faut espérer que
l'initiative Etalab porte ses fruits en mettant en avant une licence
vraiment ouverte.

L'import massif de données doit être pris avec le plus de précautions
possibles.
_ L'import des bâtiments du cadastre est semi-manuel et demande (au
mieux) beaucoup de préparation en amont de l'import et (au pire) beaucoup
de corrections (cas des bâtiments se chevauchant)
_ L'import des données Corine est décrit de façon détaillée sur la page
suivante :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover

Pour les circuits de randonnée à pied et en vélo, il y a deux aspects :
le substrat, c'est à dire le sentier ou la route eux-mêmes, et la
relation qui va mettre bout à bout tous les sentiers et / ou routes du
circuit.
Beaucoup de personnes vont tracer des routes et des sentiers à l'aide du
cadastre, de Bing, ou de leur GPS, sans vraiment savoir qu'il sera emprunté
par un itinéraire cycliste ou de randonneur.

Si lorsque tu récupères un itinéraire les éléments physiques du parcours
sont déjà cartographiés, il te suffit de créer une relation s'appuyant
sur ceux-ci, décrivant l'itinéraire en tant que tel.
Dans le cas contraire, un des risques serait que le tracé récupéré s'appuie
sur une cartographie non libre (Google, Géoportail ...), ce qui est un
souci juridique pour la base OSM.

Concernant la FFCT, il faut s'attendre au même genre d'attitude que pour la
fédération de randonnée (FFRP) :
des adhérents de base facilement conquis (mon père est cyclotouriste et
il trouve le principe d'OSM excellent)
mais des considérations plus marketing en haut de la pyramide, qui font
qu'OSM ne sera très probablement pas mis en avant au travers des magazines
et des manifestations (semaine fédérale).

La FFCT a mis en place un site http://www.veloenfrance.fr dévelopé par
Geoconcept (qui participe au développement du site Geo, sur la base de
données IGN. A première vue ce ne sont pas les partenaires les plus moteurs
pour une coopération avec OSM. Mais je ne veux pas être mauvaise langue !

Pour le reste, sans aller jusqu'à un stand à la Semaine Fédérale, rien de
tel que le bouche à oreille pour présenter le projet aux autres cyclistes,
aux clubs, aux comités départementaux, pour qui le marketing passe
légitimement au dessus de la tête.


Le 2 novembre 2011 14:55, darrepac pascal.da...@laposte.net a écrit :

 Bonjour,

 Nouveau sur cette liste et aussi nouveau dans une rélexion plus approfondie
 d'OSM (que je connais depuis longtemps et j'ai même fait des
 micro-contributions mais que j'essaye de re-découvrir).
 Je me pose une question. Il y a de plus en plus une lame de fond vers de
 l'Open Data et je voudrais savoir comment vous gérez l'import massif de
 données.
 Exemples:
 1) Trouvant que pas mal de sentiers étaient manquants sur OSM pour la
 pratique de la randonnée ou du VTT (par exemple), et connaissant
 l'existence
 des PDIPR (Plan départemental d'itinéraires de promenades et de
 randonnées),
 je me suis demandé si ces PDIPR étaient d'accés libre (j'ai d'ailleurs vu
 la
 même question sur cette mailing list).
 En cherchant PDIPR et Opendata sur google, le premier lien donne:
 http://www.opendata71.fr/ ou en effet on peut accés à plus de 300 (!)
 circuits de randonnée à pieds, cheval et ou vtt. Les traces sont fournies,
 la précision inconnue.
 Que faire de cela? est-ce qu'il faudrait regarder un par un chaque circuit
 et rentrer presque point par point dans OSM ces sentiers?
 Cela me semble un boulot énorme, d'autant plus énorme si ce genre
 d'exemples
 se multiplie... Y a t-il une autre solution?

 2) Etant vététiste et trouvant que les données VTT sont pratiquement
 inexistantes (par exemple je n'ai trouvé aucun des prés de 300 centres de
 VTT FFC / FFCT), je me pose la même questions. Si on arrive à récupérer de
 la donnée, faudra t-il faire tout à la main...cela peut-être tellement
 fastidieux que personne ne saura réellement motivé et qu'il vaudra mieux
 continuer à rentrer ses sorties dominicales petit à petit.

 Comment avez-vous fait pour les données Corinne Land Cover ou pour les
 données des bâtiments? bâtiments par bâtiment ou un import global avec
 post-vérification?

 Merci pour vos lumières
 Pascal

 --
 View this message in context:
 http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955301.html
 Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

FrViPofm wrote:
 
 La post-vérification, c'est une vision de l'esprit. On n'aime pas 
 beaucoup... Dans OSM, on met des données qui sont bonnes (même si elles 
 peuvent gagner en qualité par la suite, comme les polygones Corine). Si 
 les données ne sont pas bonnes, on les corrige avant.
 
Oui, je suis d'accord...mais admettons que les données soient bonnes (après
vérification) pour les sentiers dont je parlais. Si j'importe ces données
dans OSM, il risque y avoir des doublons...car même si la plupart des
sentiers sont nouveaux, certains seront déjà présents, au moins en partie.
Que faire dans ce cas? nettoyer préalablement les données en les expurgeant
de données qui sont déjà dans OSM?? ca me semble difficile...
En gros, admettons que le 71 ou la FFC ou tartampion file plein de données à
la communauté, quel est le process pour intégration dans OSM?

Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955579.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[Pieren]

2011/11/2 darrepac pascal.da...@laposte.net:
 En gros, admettons que le 71 ou la FFC ou tartampion file plein de données à
 la communauté, quel est le process pour intégration dans OSM?

 Pascal

Le processus est soit automatisé si tu es un crack, soit communautaire
(crowdsourcing). Automatisé si tu es capable de fusionner les données
nouvelles avec les données existantes. Communautaire si tu n'es pas
capable de le faire automatiquement et en mettant à disposition des
fichiers au format le plus aisé à importer dans OSM par d'autres et en
demandant à chaque contributeur de faire l'intégration manuellement et
sous sa responsabilité. C'est comme ça que c'est fait pour le bâti du
cadastre ou les landuses CLC.

Maintenant, il y a plusieurs bémols aux imports de masse automatiques :
- bien se préparer. Les bourdes génèrent trop de travail pour les
corrections manuelles et le risque est de déclencher une annulation
elle-aussi massive...
- être vraiment sûr de la compatibilité de la license. Nous migrons
vers ODBL et ces données doivent être compatible ODBL.
- être sûr de pouvoir apporter quelque chose à OSM. C'est bête comme
remarque mais si tes données externes ne précisent pas que le passage
est un sentier, un petit chemin carrossable ou une route, ça ne va pas
le faire. C'est pourquoi en général, on préfère les contributions de
visu. Pire, il y a aussi des données trop vieilles et obsolètes qui,
comme le cadastre parfois, polluent la base. Ou importer massivement
des lignes tagguées uniquement en highway=road qui n'apportent pas
grand chose.

Et plus on avance dans le temps, plus compliqué sera l'intégration et
la mise à jour de données externes. A moins de développer des outils
particuliers, cela sera de plus en plus réservé à une petite élite
d'experts sur des zones ou des thèmes de plus en plus restreints.

Pieren

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

Re: [OSM-talk-fr] Import Massif

[Ab_fab]

Je vais dans le même sens que Pieren.

Il ne faut pas négliger la valeur ajoutée du processus communautaire.
Obtenir un tracé de parcours et l'adapter pour l'utiliser comme fond de
plan dans JOSM, c'est déjà beaucoup.
Cela permet de combiner les informations avec les autres sources
disponibles (photos aériennes, cadastre, connaissances personnelles ...)
pour préciser le tracé et la nature de la voirie (route, sentier, qualité
du revêtement)

Le 2 novembre 2011 16:32, Pieren pier...@gmail.com a écrit :

 2011/11/2 darrepac pascal.da...@laposte.net:
  En gros, admettons que le 71 ou la FFC ou tartampion file plein de
 données à
  la communauté, quel est le process pour intégration dans OSM?
 
  Pascal

 Le processus est soit automatisé si tu es un crack, soit communautaire
 (crowdsourcing). Automatisé si tu es capable de fusionner les données
 nouvelles avec les données existantes. Communautaire si tu n'es pas
 capable de le faire automatiquement et en mettant à disposition des
 fichiers au format le plus aisé à importer dans OSM par d'autres et en
 demandant à chaque contributeur de faire l'intégration manuellement et
 sous sa responsabilité. C'est comme ça que c'est fait pour le bâti du
 cadastre ou les landuses CLC.

 Maintenant, il y a plusieurs bémols aux imports de masse automatiques :
 - bien se préparer. Les bourdes génèrent trop de travail pour les
 corrections manuelles et le risque est de déclencher une annulation
 elle-aussi massive...
 - être vraiment sûr de la compatibilité de la license. Nous migrons
 vers ODBL et ces données doivent être compatible ODBL.
 - être sûr de pouvoir apporter quelque chose à OSM. C'est bête comme
 remarque mais si tes données externes ne précisent pas que le passage
 est un sentier, un petit chemin carrossable ou une route, ça ne va pas
 le faire. C'est pourquoi en général, on préfère les contributions de
 visu. Pire, il y a aussi des données trop vieilles et obsolètes qui,
 comme le cadastre parfois, polluent la base. Ou importer massivement
 des lignes tagguées uniquement en highway=road qui n'apportent pas
 grand chose.

 Et plus on avance dans le temps, plus compliqué sera l'intégration et
 la mise à jour de données externes. A moins de développer des outils
 particuliers, cela sera de plus en plus réservé à une petite élite
 d'experts sur des zones ou des thèmes de plus en plus restreints.

 Pieren

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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import Massif

[darrepac]

Je n'écarte pas les problèmes juridiques qui sont réels mais ce n'était pas
forcément le propos de ma question qui se placait plus sur le terrain
technique (même si, pour reprendre de l'open data dans le 71, la license
sembleopen: http://www.opendata71.fr/licence/)

je comprends le besoin de données de qualité et il est vrai, si je prends
toujours mon exemple du 71 (où je n'habite pas mais un exemple concret me
semble plus simple pour comprendre), que les informations sur la voie
empruntée ne sont pas connues. Donc il vaut mieux peu de qualité que
beaucoup de générique?
Je pensais qu'il pourrait y avoir un intérêt à avoir 3000km de chemins
accessibles à la randonnée par exemple sans forcément savoir partout si
c'est de l'asphalte, des cailloux, large, étroit, accessible aussi au
voiture etc.
plutôt que ne pas prendre une source.

Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955747.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Ab_fab wrote:
 
 Je vais dans le même sens que Pieren.
 
 Il ne faut pas négliger la valeur ajoutée du processus communautaire.
 Obtenir un tracé de parcours et l'adapter pour l'utiliser comme fond de
 plan dans JOSM, c'est déjà beaucoup.
 Cela permet de combiner les informations avec les autres sources
 disponibles (photos aériennes, cadastre, connaissances personnelles ...)
 pour préciser le tracé et la nature de la voirie (route, sentier, qualité
 du revêtement)
 
 
J'avais compris son message dans l'autre sens: il vaut mieux pas prendre car
la quantité d'attributs est faible (je schématise!).
Alors que moi en effet, je m'étais plutôt dit comme toi il me semble, qu'une
donnée de relativement bonne qualité est déjà une bonne base pour aller plus
loin...

Pascal


--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955753.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[Thomas Clavier]

Le 02/11/2011 16:44, darrepac a écrit :

Je pensais qu'il pourrait y avoir un intérêt à avoir 3000km de chemins
accessibles à la randonnée par exemple sans forcément savoir partout si
c'est de l'asphalte, des cailloux, large, étroit, accessible aussi au
voiture etc.
plutôt que ne pas prendre une source.


à mon avis, le plus important c'est de respecter le travail des autres. 
Donc que la réponse à la question soit : je prends ces données de 
qualité médiocre à défaut de mieux ou je préfère laisser les centaines 
de fourmis qui oeuvrent dans leur coin pour enrichir la carte, dans tous 
les cas, le travail doit être fait dans le respect du travail des 
autres. Donc :
- évitons d'importer massivement si ça risque de créer des doublons : ça 
dévalorise le travail déjà fait
- ne pas supprimer pour remplacer : on perd l'historique et ça détruit 
le travail d'au moins une fourmis


Pour le reste j'ai pas d'avis, enfin si mais je le garde pour moi, 
chacun étant libre d'enrichir la carte comme il le souhaite. Avec un 
seul but commun : améliorer les données cartographique libre !


--
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783


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

Re: [OSM-talk-fr] Import Massif

[darrepac]

je comprends et adhère assez à ta philosophie...bon j'ai été un peu trop
loin dans ma schématisation: je ne crois pas que des données de PDIPR soient
des données médiocres car ce sont elles qui font références chez beaucoup de
gens...Par contre, il est vrai que des données attributaires peuvent
manquer, c'est clair.
Dans tous les cas, au vu des échanges, tout ceci doit rester très
manuel...et donc chronophage et donc prendre du temps à intégrerLes
routes c'est beaucoup plus simples à dessiner que les sentiers (bcp plus de
kilomètres de sentiers et bcp moins de personne qui vont dessus)

Pascal

--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955845.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import Massif

[Pieren]

2011/11/2 darrepac pascal.da...@laposte.net:
 J'avais compris son message dans l'autre sens: il vaut mieux pas prendre car
 la quantité d'attributs est faible (je schématise!).
 Alors que moi en effet, je m'étais plutôt dit comme toi il me semble, qu'une
 donnée de relativement bonne qualité est déjà une bonne base pour aller plus
 loin...

C'est difficile d'avoir une réponse noir ou blanc. Les imports
existants sont intéressants  sur ce point :
- le bâti cadastral est assez précis, surtout vrai en ville , mais
pauvre en attributs. Et plus on s'éloigne des centres-villes, plus la
qualité de positionnement se dégrade. Cependant, personne n'imagine
que tracer soi-même à partir des images Bing donneront un résultat
aussi bon et aussi rapide.
- les landuses de Corine Land Cover sont mauvais du point de vue du
positionnement (sauf si on les considère pour l'échelle 1/100.000e)
mais avaient de bons attributs qui ont presque tous trouvés leur
équivalent dans OSM. C'était un moyen rapide de couvrir une grande
partie du territoire tout en sachant qu'il faudrait améliorer leur
qualité par des contributions individuelles ultérieures (à l'époque,
on ne disposait pas des images de Bing donc il n'existait aucune
source pour les landuses en dehors de quelques zones bien couvertes
par Yahoo).

Je suis d'accord avec Thomas lorsqu'il dit qu'il faut que ça a aille
dans le sens d'une amélioration. Moins lorsqu'il demande de ne pas
supprimer l'existant. L'historique des mes contributions, je m'en f...
Le but, c'est d'avoir la meilleure carte possible et les fourmis
doivent savoir se sacrifier pour ça. De toute façon, même supprimées,
les contributions sont encore dans la base et on peut toujours les
retrouver si nécessaire.

Pieren

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

Re: [OSM-talk-fr] Import Massif

[Emilie Laffray]

2011/11/2 darrepac pascal.da...@laposte.net

 je comprends et adhère assez à ta philosophie...bon j'ai été un peu trop
 loin dans ma schématisation: je ne crois pas que des données de PDIPR
 soient
 des données médiocres car ce sont elles qui font références chez beaucoup
 de
 gens...Par contre, il est vrai que des données attributaires peuvent
 manquer, c'est clair.
 Dans tous les cas, au vu des échanges, tout ceci doit rester très
 manuel...et donc chronophage et donc prendre du temps à intégrerLes
 routes c'est beaucoup plus simples à dessiner que les sentiers (bcp plus de
 kilomètres de sentiers et bcp moins de personne qui vont dessus)


Il est possible de faire dans l'automatique mais c'est quand même la aussi
chronophage et ça demande pas mal de travail. Corine a été fait grâce au
travail des gens qui ont regardé dans leurs régions l'impact de tels ou
tels polygones. Pour Corine, ce n'était pas un énorme problème. Si tu veux
voir l'impact d'un import semi automatisé de routes, il faut que tu
regardes l'import BMO.
L'import manuel est faisable mais encore plus chronophage puisqu'il faut
aller vérifier sur le terrain.
Pour l'import automatisé, sans les informations adéquates, on a le problème
de mettre highway=road ce qui n'est pas génial et même s'il y a des chemins
qui seront vite corrigés, a terme, on risque de remplir la base avec des
chemins qui ne seront pas vérifiées ce qui est plus gênant d'à mes yeux.
Donc oui pour un import mais d'à condition qu'il soit bien réfléchi
(analyse préalable des données, être sur que la communauté suive par
derrière) et bien conçu.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import Massif

[Jean-François Gigand]

Bonsoir,

 Comme tu le dis, l'opendata est une lame de fond et il faut espérer que
 l'initiative Etalab porte ses fruits en mettant en avant une licence
 vraiment ouverte.

L'Etalab a publié sa licence (version 1.0) en octobre :
http://www.etalab.gouv.fr/pages/licence-ouverte-open-licence-5899923.html

D'après ce que j'en comprends c'est vraiment ouvert, utilisation
commerciale comprise.


Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/

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

Re: [OSM-talk-fr] Import Massif

[Sébastien Dinot]

Jean-François Gigand a écrit :
 D'après ce que j'en comprends c'est vraiment ouvert, utilisation
 commerciale comprise.

Oui, c'est une licence libre permissive que l'on peut rapprocher, dans
le domaine du logiciel, des licences Apache V2, BSD ou X/MIT et, dans le
domaine des œuvres littéraires et artistiques, de la licence Creative
Commons Attribution (CC By).

Bref, les données publiées sous la licence ouverte Étalab sont
compatibles avec le projet OSM.

Ceux d'entre vous qui démarchent des collectivités territoriales peuvent
donc leur suggérer deux licences désormais :

* la licence libre permissive d'Étalab ;

* la licence libre diffusive ODbL.

Pour information, même si la licence ouverte Étalab avait existé lorsque
nous avons approché la communauté urbaine du Grand Toulouse, je pense
que cette dernière aurait quand même opté pour la licence ODbL car nos
interlocuteurs en ont apprécié le caractère diffusif.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [OSM-talk-fr] Import Massif

[Romain MEHUT]

Le 2 novembre 2011 14:55, darrepac pascal.da...@laposte.net a écrit :

 Bonjour,

 Nouveau sur cette liste et aussi nouveau dans une rélexion plus approfondie
 d'OSM (que je connais depuis longtemps et j'ai même fait des
 micro-contributions mais que j'essaye de re-découvrir).
 Je me pose une question. Il y a de plus en plus une lame de fond vers de
 l'Open Data et je voudrais savoir comment vous gérez l'import massif de
 données.
 Exemples:
 1) Trouvant que pas mal de sentiers étaient manquants sur OSM pour la
 pratique de la randonnée ou du VTT (par exemple), et connaissant
 l'existence
 des PDIPR (Plan départemental d'itinéraires de promenades et de
 randonnées),
 je me suis demandé si ces PDIPR étaient d'accés libre (j'ai d'ailleurs vu
 la
 même question sur cette mailing list).
 En cherchant PDIPR et Opendata sur google, le premier lien donne:
 http://www.opendata71.fr/ ou en effet on peut accés à plus de 300 (!)
 circuits de randonnée à pieds, cheval et ou vtt. Les traces sont fournies,
 la précision inconnue.
 Que faire de cela? est-ce qu'il faudrait regarder un par un chaque circuit
 et rentrer presque point par point dans OSM ces sentiers?
 Cela me semble un boulot énorme, d'autant plus énorme si ce genre
 d'exemples
 se multiplie... Y a t-il une autre solution?

 2) Etant vététiste et trouvant que les données VTT sont pratiquement
 inexistantes (par exemple je n'ai trouvé aucun des prés de 300 centres de
 VTT FFC / FFCT), je me pose la même questions. Si on arrive à récupérer de
 la donnée, faudra t-il faire tout à la main...cela peut-être tellement
 fastidieux que personne ne saura réellement motivé et qu'il vaudra mieux
 continuer à rentrer ses sorties dominicales petit à petit.


Avant de vouloir réaliser un tel import, as-tu déjà tenté une prise de
contact avec des clubs VTT ou autres associations de randonnée? Il y a là
un vaste potentiel de personnes en mesure de qualifier les chemins
empruntés. Reste à les motiver ce qui n'est pas gagné d'avance...



 Comment avez-vous fait pour les données Corinne Land Cover ou pour les
 données des bâtiments? bâtiments par bâtiment ou un import global avec
 post-vérification?

 Merci pour vos lumières
 Pascal
  --
 View this message in context:
 http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6955301.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] Import Massif

[darrepac]

Romain MEHUT wrote:
 
 Avant de vouloir réaliser un tel import, as-tu déjà tenté une prise de
 contact avec des clubs VTT ou autres associations de randonnée? Il y a là
 un vaste potentiel de personnes en mesure de qualifier les chemins
 empruntés. Reste à les motiver ce qui n'est pas gagné d'avance...
 
Si je pose la question c'est bien que j'ai quelques idées derrière la tête
oui...mais au delà de ces idées, encore une fois, l'exemple du PDIPR 71 que
je donne est extra concret, difficile de faire mieux.
Pour assos, fédé, pour avoir été (et être encore) consultant pour la FFRP
sur tous les aspects GPS, c'est pas gagné pour récupérer des traces chez
eux...mais à l'heure actuelle leurs traces viennent pas mal de PDIPR, donc
la boucle est bouclée.
Etant responsable des GPS Magellan en France, c'est aussi une piste pour
faire des trucs mais trop flous pour le moment (si vous avez des idées?). Ca
serait bien de proposer une carte OSM France sur ces GPS déjà...ca peut
aussi entrainer des gens à améliorer la carte.
Motiver des gens est en effet pas facile surtout que l'interface, l'édition
de la carte OSM mériterait d'être grandement facilité (quitte à faire des
profiles vététiste, randonneur etc) pour que des gens (presque) lambda
puissent contribuer. Car je pense que c'est bien la complexité qui est un
des plus gros freins.
Ensuite, motivé des fédés, assos etc...on se heurte ensuite à une quantité
de données, qui, on vient de le voir ,n'est pas évidente à intégrer
(attributs?, source?...)

Pas simple tout ca, mais c'est ca qui est intéressant! :)
Pascal




--
View this message in context: 
http://gis.638310.n2.nabble.com/Import-Massif-tp6955301p6956898.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] import massif du cadastre et license

[Vincent Pottier]

Le 04/07/2010 21:32, hamster a écrit :
je m'interroge sur le respect des regles d'import du cadastre dans OSM 
avec l'import massif en cours


il nous est demande de ne pas redistruibuer le cadastre tel qu'el mais 
sous forme de produit composite, et de citer la source avec l'annee de 
mise a jour

Il y a deux questions


pour l'annee de mise a jour je constate que le script de conversion 
met systematiquement 2010, ce qui est souvent faux : comment faites 
vous pour remettre la bonne annee sur un aussi grand nombre d'objets 
sans y passer des jours ?
Seule l'année est mise. La question a déjà été soulevée pour le plugin. 
On a conclu que de mettre automatiquement l'année de la date de 
consultation valait pour la mise à jour.

On veillera à faire une mise à jour des pdf au premier janvier 2011 ;-)


pour le produit composite, certains d'entre nous ont telecharge a peu 
pres toute la france et fait des fichiers .osm qu'ils ont mis en ligne
il s'agit la d'une publication du cadastre qui n'est pas du tout un 
produit composite !
mettre tout cela sur le wiki accessible uniquement aux contributeurs 
apres authentification serait peut-etre une solution pour eviter ce 
probleme : ca ne serait plus de la publication vu qu'il faudrait 
s'identifier pour y avoir acces
Je pense que des outils à la CLC sont en cours d'élaboration pour 
charger en vectoriel les extracts. Je pense aussi qu'ils ne seront 
accessibles qu'après authentification qui vaudra accord d'utilisation 
exclusive pour traitement et import dans OSM.

--
FrViPofm


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

Re: [OSM-talk-fr] Import massif Guipel

[Guillaume Allegre]

Le Tue 15 Jun 2010 à 22:35 +0200, Rodolphe Quiedeville a ecrit :
 Salut,
 
 Je viens de finir l'import des données de Guipel, ref :
 http://www.openstreetmap.org/browse/changeset/4995345

Désolé, j'ai dû louper des messages, mais quelle était la source ?

 Bon j'espère ne pas avoir trop mal interpété les données fournies, je
 n'ai jamais mis les pieds à Guipel mais j'ai préféré laisser quelques
 voies ( 5) non raccordées plutôt que de le faire du mauvais coté.

Par rapport aux tags utilisés, il me semble me souvenir suite à une
discussion ici que les noms du type Voie communale n°101 dite de La Polletière
devraient normalement se baliser en :
name = Chemin (ou Route) de La Polletière
ref = VC 101
Bien sûr, pour un import massif, ce n'est pas évident à faire automatiquement.

Au passage, on trouve souvent des Voies communales et des Chemins ruraux,
qui partagent le même pool de numéros. 
Perso j'utilise toujours VC NNN comme ref. 
En revanche, pour les types de routes associées, on n'a que 'unclassified', 
et c'est dommage.



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Import massif Guipel

[Sébastien Dinot]

Salut,

- Guillaume Allegre allegre.guilla...@free.fr a écrit :
 Désolé, j'ai dû louper des messages, mais quelle était la source ?

Guillaume, ça, c'était ma question, tu n'avais pas le droit de me la piquer ! ;)

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [OSM-talk-fr] Import massif Guipel

[Lionel Van Aertryck]

Bonjour,

2010/6/16 Guillaume Allegre allegre.guilla...@free.fr:
 Le Tue 15 Jun 2010 à 22:35 +0200, Rodolphe Quiedeville a ecrit :

 Je viens de finir l'import des données de Guipel, ref :
 http://www.openstreetmap.org/browse/changeset/4995345

Un grand merci à Rodolphe et Steven pour ce premier import de filaire
de la communauté de communes du Val d'Ille. La première cartopartie
que nous allons organiser samedi prochain permettra aux contributeurs
de se concentrer sur tout ce que l'on ne peut pas importer
automagiquement ;-)


 Désolé, j'ai dû louper des messages, mais quelle était la source ?

La source est la même que pour l'import du bâti qui a été réalisé par
Steven en décembre 2009 : le cadastre numérisé dont nous (la
communauté de communes) disposons.

 Bon j'espère ne pas avoir trop mal interpété les données fournies, je
 n'ai jamais mis les pieds à Guipel mais j'ai préféré laisser quelques
 voies ( 5) non raccordées plutôt que de le faire du mauvais coté.

De ce que j'en ai vu, le résultat paraît très satisfaisant, on va
maintenant passer la main aux locaux pour ajuster ce qui aura besoin
de l'être, la contribution du terrain ;-)

Quelques liens sur le wiki :
- http://wiki.openstreetmap.org/wiki/Communaut%C3%A9_de_communes_du_Val_d%27Ille

- 
http://wiki.openstreetmap.org/wiki/Import_cadastral_de_la_communaut%C3%A9_de_communes_du_Val_d%27Ille

-- 
Lionel Van Aertryck (vice-pdt de la communauté de communes du Val d'Ille).
http://wiki.openstreetmap.org/wiki/User:Lionel.VA

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

Re: [OSM-talk-fr] Import massif Guipel

[François Van Der Biest]

2010/6/15 Rodolphe Quiedeville rodol...@quiedeville.org:

 J'ai lu sur http://wiki.openstreetmap.org/wiki/Guipel qu'une
 Carto-partie était organisée ce samedi, cela tombe bien ils pourront
 peaufiner et compléter mon import.

... Et c'est bien le but annoncé lors de la libération de ces données...

Merci Rodolphe pour le travail accompli !

F.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Lionel Van Aertryck]

Bonjour,

2009/12/11 Jérémy Garniaux jeremy@gmail.com:
 Le vendredi 11 décembre 2009 à 10:16 +0100, Steven Le Roux a écrit :
 2009/12/11 Jérémy Garniaux jeremy@gmail.com
 Si ça peut aider, la projection est indiquée dans les MIF/MID (MIF
 précisément), troisième ligne en l'ouvrant avec un éditeur de texte :

 Version 300
 Delimiter  
 CoordSys Earth Projection 1, 104
 #...(suivi des noms de champs)


  CoordSys Earth Projection 3, 33, 7, 3, 48, 47.25, 48.75, 170, 720
 Bounds (100, 700) (240, 740)

 Donc Lambert 93 à priori ?

Voici ce qu'il y a dans les fichiers .geo (qui ont été utilisés pour
produire les fichiers MIF/MID :

BOMT 12:E000ABSE.GEO
CSET 03:IRV

RTYSA03:GEO
RIDSA15:GEODESIE_E000AB

RETSA03:MAP
RENST00:
RELSA09:RGF93CC48
DIMSN01:2
ALSSN01:2
UNHST01:m

EOMT 00:


Le RGF93 fait bien référence à la représentation plane Lambert 93.
-- 
Lionel Van Aertryck

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Denis]

Lionel Van Aertryck a écrit :

 Voici ce qu'il y a dans les fichiers .geo (qui ont été utilisés pour
 produire les fichiers MIF/MID :
 
 BOMT 12:E000ABSE.GEO
 CSET 03:IRV
 
 RTYSA03:GEO
 RIDSA15:GEODESIE_E000AB
 
 RETSA03:MAP
 RENST00:
 RELSA09:RGF93CC48
 DIMSN01:2
 ALSSN01:2
 UNHST01:m
 
 EOMT 00:
 
 
 Le RGF93 fait bien référence à la représentation plane Lambert 93.

Oui, mais un Lambert 93 zone 7 (CC48 - conforme conique centré sur le 48°).
Pour les outils ogr/gdal, QGIS, etc. le code EPSG est le 3948 (voir 
http://georezo.net/wiki/main:dico:epsg).

Denis

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Steven Le Roux]

2009/12/12 Denis dhel...@free.fr

  
  Le RGF93 fait bien référence à la représentation plane Lambert 93.


 Oui, mais un Lambert 93 zone 7 (CC48 - conforme conique centré sur le
 48°).
 Pour les outils ogr/gdal, QGIS, etc. le code EPSG est le 3948 (voir
 http://georezo.net/wiki/main:dico:epsg).


C'est bon alors, c'est la même projection que les données de Plouarzel.


 Denis

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




-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Steven Le Roux]

2009/12/11 Jérémy Garniaux jeremy@gmail.com

  Bonjour,

 Si ça peut aider, la projection est indiquée dans les MIF/MID (MIF
 précisément), troisième ligne en l'ouvrant avec un éditeur de texte :

 Version 300
 Delimiter  
 CoordSys Earth Projection 1, 104
 #...(suivi des noms de champs)


 CoordSys Earth Projection 3, 33, 7, 3, 48, 47.25, 48.75, 170, 720
Bounds (100, 700) (240, 740)

Donc Lambert 93 à priori ?




 Mais il n'est pas conseillé de changer la projection à la main...
 La référence des projections (1, 104 par ex) est à trouver dans le manuel
 Mapinfo, que je n'ai pas sous la main.

 Jeremy

 Le jeudi 10 décembre 2009 à 14:50 +0100, HELFER Denis a écrit :

 Steven Le Roux ste...@le-roux.info a écrit:
  Sur ce sujet, une autre communauté de commune bretonne souhaite
  pousser ses données vectorielles.

 Toujours à la pointe ces Bretons

  Je regarde ça en détail ce week end car le format des données m'est
  inconnu pour le moment (EDIGEO et MIF/MID) et je n'ai pas la
  projection d'origine, donc il va falloir tatonner.

 Dans l'échange EDIGEO, il y a des indications sur la projection utilisée. 
 Normalement c'est dans les fichiers *.GEO
 Exemple (réel de données fournies par la DGI) :
 ***
 BOMT 12:ED0101SE.GEO
 CSET 03:IRV

 RTYSA03:GEO
 RIDSA15:GEODESIE_ED0101

 RETSA03:MAP
 RENST00:
 RELSA05:LAMB1
 DIMSN01:2
 ALSSN01:2
 UNHST01:m

 EOMT 00:
 ***
 ici c'est du Lambert 1  (LAMB1)
 Sinon pour passer d'EDIGEO à MIF/MID, il y a un script perl edi2mif.pl [1] 
 qui fonctionne bien. Il me semble qu'on en a déjà parlé sur cette liste.
 Pour les fanas de Perl, il doit y avoir moyen de passer directement de 
 l'EDIGEO à du OSM (cela permettrait d'éviter une chaîne longue et inutile de 
 changement de formats).

 Denis

 1 : http://adullact.net/projects/edi2mif/
 ___
 Talk-fr mailing 
 listtalk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr



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




-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Jérémy Garniaux]

Le vendredi 11 décembre 2009 à 10:16 +0100, Steven Le Roux a écrit :

 
 
 
 2009/12/11 Jérémy Garniaux jeremy@gmail.com
 
 Bonjour,
 
 Si ça peut aider, la projection est indiquée dans les MIF/MID
 (MIF précisément), troisième ligne en l'ouvrant avec un
 éditeur de texte :
 
 Version 300
 Delimiter  
 CoordSys Earth Projection 1, 104
 #...(suivi des noms de champs)
 
 
  CoordSys Earth Projection 3, 33, 7, 3, 48, 47.25, 48.75, 170,
 720 Bounds (100, 700) (240, 740)
 
 Donc Lambert 93 à priori ?
 


Oui ça y ressemble selon les définitions de projection mapinfo. Au
choix :

French Lambert-93, 3, 33, 7, 3, 46.5, 44, 49, 70, 660
Bounded French Lambert-93, 2003, 33, 7, 3, 46.5, 44, 49, 70,
660, 75000, 600, 1275000, 720

La syntaxe : 

[ Projection type, datum, unitname
   [ , origin_longitude ] [ , origin_latitude ]
   [ , standard_parallel_1 [ , standard_parallel_2 ] ]
   [ , azimuth ] [ , scale_factor ]
   [ , false_easting ] [ , false_northing ]
   [ , range ] ]

(J'en profite pour apprendre :) )

Jérémy
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[David MENTRE]

Bonjour,

Le 9 décembre 2009 22:55, Pierre Touzard pierretouz...@yahoo.fr a écrit :
 OSM France propose t-il (ou réfléchit-il à) des modèles de convention pour
 l'accès au cadastre vecteur détenu par le collectivités ?

Il n'y a pas d'« OSM France » (pour l'instant). Pas de modèle de
convention non plus.

 Il existe nombre de collectivités qui souhaite mettre en place des
 conventions de numérisation du plan cadastral sur leur territoire (par
 exemple sur la moité d'un département)...
 Dans l'hypothèse où ces mêmes collectivités accepteraient de citer OSM dans
 leurs convention... Comment faire concrètement ?

Si la commune a déjà un accord de numérisation du cadastre, lire
l'accord et voir si ça colle avec OSM[2]. C'est ce qui est fait par
Lionel Van Aertryck[1], élu de la Communauté de Communes du Val d'Ille
(en Ille-et-Vilaine, 35).

Si pas d'accord, c'est à ma connaissance un terrain vierge.

 En somme : dispose-t-on d'exemples, de modèles ?

Non, il faut les faire.

 si la réponse est négative ne faudrait-il pas y réfléchir ?

Pas réfléchir : faire. Trouver une commune, rédiger un brouillon
d'accord, vérifier sur cette liste qu'il n'y a pas de soucis, etc.
Après les autres copieront.

Comme d'habitude dans le Libre, c'est ceux qui font qui font avancer les choses.

Amicalement,
david

[1] Lionel a déjà posté sur cette liste, cf. les archives.

[2] Il faudrait voir avec Lionel si on peut documenter ça une fois fini.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Steven Le Roux]

Sur ce sujet, une autre communauté de commune bretonne souhaite pousser ses
données vectorielles.

Je regarde ça en détail ce week end car le format des données m'est inconnu
pour le moment (EDIGEO et MIF/MID) et je n'ai pas la projection d'origine,
donc il va falloir tatonner.

C'est dans ce coin là :
http://nominatim.openstreetmap.org/?q=Saint+M%C3%A9dard+sur+Ille.viewbox=-2.18%2C48.47%2C-1.16%2C48.07polygon=1

-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Lionel Van Aertryck]

Bonjour à tous

Vous pouvez fusionner communaute bretonne et projet de Lionel ;-)

J'adhere completement au point de vue sur le partage de données  
financées par des fonds publiques et je participerai volontier à  
toute initiative en ce sens, en particulier pour Osm, et à la  
diffusion de la methode suivie.


La question commence à être posée à d'autres échelons  
(département par exemple) et on devrait voir fleurir ce type  
d'initiative, d'autant plus qu'osm est tres bien accueilli au niveau  
des élus à qui nous le présentons ( la communauté de commune pour  
le moment), qui y voient un formidable outil pour de nombreuses  
initiatives, y compris pour faire du lien social sur un territoire.




Lionel Van Aertryck

Le 10 déc. 2009 à 11:58, Steven Le Roux ste...@le-roux.info a  
écrit :




Sur ce sujet, une autre communauté de commune bretonne souhaite pous 
ser ses données vectorielles.


Je regarde ça en détail ce week end car le format des données  
m'est inconnu pour le moment (EDIGEO et MIF/MID) et je n'ai pas la p 
rojection d'origine, donc il va falloir tatonner.


C'est dans ce coin là : http://nominatim.openstreetmap.org/?q=Saint+M%C3%A9dard+sur+Ille.viewbox=-2.18%2C48.47%2C-1.16%2C48.07polygon= 
1


--
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[HELFER Denis]

Steven Le Roux ste...@le-roux.info a écrit:
 Sur ce sujet, une autre communauté de commune bretonne souhaite
 pousser ses données vectorielles.

Toujours à la pointe ces Bretons

 Je regarde ça en détail ce week end car le format des données m'est
 inconnu pour le moment (EDIGEO et MIF/MID) et je n'ai pas la
 projection d'origine, donc il va falloir tatonner.

Dans l'échange EDIGEO, il y a des indications sur la projection utilisée. 
Normalement c'est dans les fichiers *.GEO
Exemple (réel de données fournies par la DGI) :
***
BOMT 12:ED0101SE.GEO
CSET 03:IRV

RTYSA03:GEO
RIDSA15:GEODESIE_ED0101

RETSA03:MAP
RENST00:
RELSA05:LAMB1
DIMSN01:2
ALSSN01:2
UNHST01:m

EOMT 00:
***
ici c'est du Lambert 1  (LAMB1)
Sinon pour passer d'EDIGEO à MIF/MID, il y a un script perl edi2mif.pl [1] qui 
fonctionne bien. Il me semble qu'on en a déjà parlé sur cette liste.
Pour les fanas de Perl, il doit y avoir moyen de passer directement de l'EDIGEO 
à du OSM (cela permettrait d'éviter une chaîne longue et inutile de changement 
de formats).

Denis

1 : http://adullact.net/projects/edi2mif/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pierre Touzard]

Remarque 1: La DGI est morte vive la DGFiP ! (Direction Générale des Finances
Publiques)... et son projet de vrai WMS (d'après Laurent PATTE c'est dans
les tuyaux mais aucune date ni de certitude quant à la garantie de qualité
de service).

Remarque 2: Il faut FAIRE !  mettre en place un service analyse des
conventions pour savoir si elles sont compatibles avec ... OSM et, dans la
négative, proposer des aveneants.
Ca pourrait heurter certaines sensibilités mais il me semble qu'un service
juridique ne ferait pas de mal au projet OSM. A quant un numéro vert ?

Cela me semble nécessaire du fait du contexte disons... particulier de
l'information Géographique en France.
-- 
View this message in context: 
http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4147032.html
Sent from the French OSM list mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Denis]

Pierre Touzard a écrit :
 Remarque 1: La DGI est morte vive la DGFiP ! (Direction Générale des Finances
 Publiques)... et son projet de vrai WMS (d'après Laurent PATTE c'est dans
 les tuyaux mais aucune date ni de certitude quant à la garantie de qualité
 de service).

Non la DGI n'est pas morte, mais la DGFiP a du mal à prendre la relève 
(notamment dans les soures des objets digitalisés à partir du PCI ;-).
Oui, Laurent Patte avait annoncé une mise en service du WMS pour la 
mi-2009. Peu importe l'échéance, je ne voudrais pas être à leur place et 
préfère la mienne qui constate que les données cadastrales ont le vent 
en poupe ces derniers jours.

 
 Remarque 2: Il faut FAIRE !  mettre en place un service analyse des
 conventions pour savoir si elles sont compatibles avec ... OSM et, dans la
 négative, proposer des aveneants.
 Ca pourrait heurter certaines sensibilités mais il me semble qu'un service
 juridique ne ferait pas de mal au projet OSM. A quant un numéro vert ?
 
 Cela me semble nécessaire du fait du contexte disons... particulier de
 l'information Géographique en France.

Je sais (pour en avoir lu d'anciennes) que les conventions 
Collectivités/DGI-DGFiP sur la numérisation du cadastre n'ont pas été 
toujours aussi équitables que les versions en vigueur actuellement. 
Soit, il n'y a qu'à commencer par les plus chauds (les conventions et 
les acteurs ;-).
Ces conventions affirment clairement la coproprité des données et une 
pleine liberté (et donc un choix, une responsabilité) de diffuser 
(comprendre réutiliser) par les collectivités locales sur le PCI vecteur.

La balle est dans le camp des plus gros producteurs d'informations 
géolocalisées (à part nous ;-) pour la mise à disposition du cadastre 
(du moins les composants qui nous intéressent particulièrement).

La balle est aussi dans notre camp, sur un plan plutôt de communication 
(quels sont les avantages pour la collectivité de permettre à OSM 
(comprendre le citoyen lambda) de réutiliser les données déjà payées). 
J'ai beaucoup aimé l'idée des liens sociaux sur un territoire évoqué par 
le projet de Lionel.
OSM est autre chose qu'un référentiel de plus, fusse-t-il à l'échelle 
mondiale, c'est, avant tout, une autre manière de s'approprier son 
territoire, de le comprendre, de le décrire avec son propre sémantique 
afin de mieux pouvoir agir dessus, citoyennement. Sur ce plan, il y a un 
gros boulot à faire (en termes de com).
UPCT, me semble-t-il, avait déjà senti (et défendu) cet aspect 
fondamental. Merci à Michel Bondaz d'avoir été un précurseur.

Denis

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Jérémy Garniaux]

Bonjour,

Si ça peut aider, la projection est indiquée dans les MIF/MID (MIF
précisément), troisième ligne en l'ouvrant avec un éditeur de texte :

Version 300
Delimiter  
CoordSys Earth Projection 1, 104
#...(suivi des noms de champs)

Mais il n'est pas conseillé de changer la projection à la main...
La référence des projections (1, 104 par ex) est à trouver dans le
manuel Mapinfo, que je n'ai pas sous la main. 

Jeremy

Le jeudi 10 décembre 2009 à 14:50 +0100, HELFER Denis a écrit :

 Steven Le Roux ste...@le-roux.info a écrit:
  Sur ce sujet, une autre communauté de commune bretonne souhaite
  pousser ses données vectorielles.
 
 Toujours à la pointe ces Bretons
 
  Je regarde ça en détail ce week end car le format des données m'est
  inconnu pour le moment (EDIGEO et MIF/MID) et je n'ai pas la
  projection d'origine, donc il va falloir tatonner.
 
 Dans l'échange EDIGEO, il y a des indications sur la projection utilisée. 
 Normalement c'est dans les fichiers *.GEO
 Exemple (réel de données fournies par la DGI) :
 ***
 BOMT 12:ED0101SE.GEO
 CSET 03:IRV
 
 RTYSA03:GEO
 RIDSA15:GEODESIE_ED0101
 
 RETSA03:MAP
 RENST00:
 RELSA05:LAMB1
 DIMSN01:2
 ALSSN01:2
 UNHST01:m
 
 EOMT 00:
 ***
 ici c'est du Lambert 1  (LAMB1)
 Sinon pour passer d'EDIGEO à MIF/MID, il y a un script perl edi2mif.pl [1] 
 qui fonctionne bien. Il me semble qu'on en a déjà parlé sur cette liste.
 Pour les fanas de Perl, il doit y avoir moyen de passer directement de 
 l'EDIGEO à du OSM (cela permettrait d'éviter une chaîne longue et inutile de 
 changement de formats).
 
 Denis
 
 1 : http://adullact.net/projects/edi2mif/
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pierre Touzard]

Bonsoir,

Où peut-on trouver des informations sur les accords politique BMOOSM ? Y
a t-il eu y une convention ? Quel fût l'acte officialisant ?

OSM France propose t-il (ou réfléchit-il à) des modèles de convention pour
l'accès au cadastre vecteur détenu par le collectivités ?

Il existe nombre de collectivités qui souhaite mettre en place des
conventions de numérisation du plan cadastral sur leur territoire (par
exemple sur la moité d'un département)... 
Dans l'hypothèse où ces mêmes collectivités accepteraient de citer OSM dans
leurs convention... Comment faire concrètement ? 

En somme : dispose-t-on d'exemples, de modèles ?

si la réponse est négative ne faudrait-il pas y réfléchir ?



-- 
View this message in context: 
http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4142273.html
Sent from the French OSM list mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Christian Rogel]

Pieren a écrit :

 C'est tout le problème de l'absence actuelle de représentation d'OSM
 en France. Toutes les démarches qui ont été faites jusqu'à présent
 l'ont été du fait de simples contributeurs et à titre personnel. C'est
 un des enjeux des discussions autour de la création d'une association
 OSM en France.
 D'un autre côté, même avec une association, je ne vois pas très bien
 ce qu'elle pourrait faire dans une convention entre collectivités
 locales et DGI. L'association n'aurait aucun contrôle sur le type de
 licence des données OSM, etc.
 

On ne peut mieux dire. Si accord, il y a, il ne peut intervenir qu'avec 
le gestionnaire de la base de données, ici OSMF.
Les structures locales peuvent avoir seulement un rôle de facilitateur.
Alors qu'une association locale ne pourrait pas passer d'accord, elle 
aurait pour tâche de faire pression pour que, dans le cadre de la future 
loi européenne, les organismes publics admettent qu'ils ne sont pas 
propriétaires des données payées par le contribuable (individu ou 
société) et dont celui a besoin.
L'intérêt général exige qu'il y ait un service collectif de cartographie 
qui dépasse les intérêts de boutique de chacun des détenteurs de bouts 
de données.
De même que la commission d'accès aux documents administratifs encadre 
et autorise la mise à disposition (et pas seulement la consultation) des 
documents administratifs sur demande, la même chose doit être appliquée 
aux données cartographiques basiques et, par nécessité pratique, sous 
une forme numérique.
Le verrou à faire sauter est que certains organismes publics veulent 
encadrer l'usage qui en serait fait, alors qu'on ne doit pas mettre de 
conditions limitatives à un droit des citoyens, sinon ce n'en est pas un.


Christian



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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pierre Touzard]

Bonjour à tous,

Je vois qu'il y a nombre de réactions...

Je précise donc ma vision :


Tout d'abord déconnectons-nous un temps de toutes considérations
politico-ethico-économiques pour nous intéresser à la technique seule

Imaginons que nous ayons accès à la couche bâti dur du cadastre vecteur.
Dans un premier temps cela concernerait la plupart des communes
vectorisées d'une région française...

étape 1 : extraction et assemblage des bâtiments commune par commune...
étape 2 : conversion en WGS84
etape 3 : fusion des polygones contigües pour faire disparaitre les limites
administratives pouvant exister entre des bâtiment. En somme, on passe
d'une couche bâtiments durs à une couche îlots de bâtiments durs
étape 4: pour chaque polygone on supprime tous les attributs et on affecte
un nouvelle attribut source =DGFiP
... Il me semble que nous venons de créer là un produit dérivé ? oui ou
non ?
étape 5: ouverture de la couche SIG dans QGIS et import dans OSM

Ce genre d'import serait-il bénéfique à OSM ? oui ou non ?
La procédure décrite conviendrait-elle ? oui ou non ?
Cela nécessiterait-il un travail préparatoire (interférences avec les zones
déjà mappée) ?


Maintenant revenons à la partie politico-ethico-économique...

Cette perspective nécessiterait-elle une quelconque autorisation ? oui ou
non ?
si oui merci de fournir une réponse claire et argumentée !


NB: La dernière question est volontairement caricaturale... c'est juste pour
pour faire avancer la discussion initiale...
-- 
View this message in context: 
http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4112602.html
Sent from the French OSM list mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Emilie Laffray]

2009/12/4 Pierre Touzard pierretouz...@yahoo.fr


 étape 1 : extraction et assemblage des bâtiments commune par commune...
 étape 2 : conversion en WGS84
 etape 3 : fusion des polygones contigües pour faire disparaitre les limites
 administratives pouvant exister entre des bâtiment. En somme, on passe
 d'une couche bâtiments durs à une couche îlots de bâtiments durs
 étape 4: pour chaque polygone on supprime tous les attributs et on affecte
 un nouvelle attribut source =DGFiP
 ... Il me semble que nous venons de créer là un produit dérivé ? oui ou
 non ?
 étape 5: ouverture de la couche SIG dans QGIS et import dans OSM

 Ce genre d'import serait-il bénéfique à OSM ? oui ou non ?
 La procédure décrite conviendrait-elle ? oui ou non ?
 Cela nécessiterait-il un travail préparatoire (interférences avec les zones
 déjà mappée) ?


Je travaille actuellement sur la vectorisation des données raster que l'on
obtient sur le site du cadastre, donc je vois ce que tu fais. De plus, ce
que tu as fait a déjà été fait par Steven et Francois pour la communauté
urbaine de Brest.

L'import serait bénéfique a OSM.

La conversion en WGS84 est le plus gros problème pour moi actuellement car
je dois deviner quel SRID utiliser pour le georeferencage. Si tu as le bon
SRID pour les données, la encore la conversion dans Postgis se fait tout
seul en quelques lignes.
Concernant l'étape 3, je ne suis pas sure que la fusion soit une bonne chose
en soi. L'autre chose c'est qu'a partir de cette étape je mets tout dans une
base de donnée Postgis. Donc je peux faire une sélection (en théorie) sur le
type facilement. A noter qu'avec les bâtiments, tu peux créer facilement un
landuse residential qui soit correct en quelques lignes de commande SQL.
Mon étape 4 est de justement procéder a un calcul de superposition avec ce
qui existe déjà. Une fois que j'ai obtenu cela, je génère un fichier OSM a
partir d'un fichier SHP généré a partir de la base de donnée.
En aucun cas, je n'utilise une couche SIG. Je trouve cela bien trop lourd et
pas assez flexible, mais bon la c'est vrai que j'ai le biais d'aimer ma base
de donnée, qui me permet de faire des choses très puissantes sans avoir a
coder une usine a gaz.
De plus, je préférerais voir une interface web a la Corine pour l'import
d'une ville plutôt qu'un import massif. Je préfère un import a la mano par
la communauté. Ça permet de donner du travail a des gens qui ne peuvent pas
forcement participer a OSM. Le but du jeu est d'attirer le plus de monde sur
OSM, et de les faire participer. Ce genre d'outil permet de faire cela
justement, et de fidéliser les gens qui y participent au final.

Maintenant, sur les autres considérations, a moins de connaître comment tu
as eus les données et pourquoi, on ne peut pas te répondre. On ne sait pas
les accords que ta société a signé avec les détenteurs du cadastre. Ce n'est
pas a nous de nous justifier sur le plan légal mais plutôt a toi. Déjà,
c'est a toi de savoir si tu as le droit d'utiliser ces données légalement en
premier lieu car c'est toi qui les propose.
Ton ton volontairement caricaturale me gêne énormément, car au final tu n'as
pas répondu a la question par toi même, toi qui est justement en position
d'y répondre. Ce genre d'import ne pose pas de problèmes techniques majeurs
a la base. La discussion technique n'a d'intérêt que si on a l'accord
d'utiliser les données, sinon ça reste du théorique.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Tenshu]

 etape 3 : fusion des polygones contigües pour faire disparaitre les limites
 administratives pouvant exister entre des bâtiment. En somme, on passe
 d'une couche bâtiments durs à une couche îlots de bâtiments durs



Je sais que ça a déjà été débattu, mais je pense que cette étape n'est
absolument pas pertinente.

Si une séparation parcellaire n'est pas toujours équivalente à 2 portions
pertinente d'un même bâtiment, c'est par contre souvent le cas.
Dites moi si je me trompe mais c'est même la majeure partie des cas.

A défaut d'avoir plus d'informations je crois que la séparation telle que
dans le cadastre est largement 'mieux que rien'.

-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Steven Le Roux]

2009/12/4 Pierre Touzard pierretouz...@yahoo.fr


 Bonjour à tous,


Salut

Tu veux du simple et clair :


 Ce genre d'import serait-il bénéfique à OSM ? oui ou non ?


oui = cartographie de la topologie existante. Le batiment en fait parti. +
utile pour mde michu pour l'adressage !


 La procédure décrite conviendrait-elle ? oui ou non ?


Comme le dit Emilie : ça a déjà été fait et c'est décrit ici :
http://wiki.openstreetmap.org/wiki/BMO


 Cela nécessiterait-il un travail préparatoire (interférences avec les zones
 déjà mappée) ?


Dans le cadre d'un import nationale ou suffisament large oui...



 Maintenant revenons à la partie politico-ethico-économique...

 Cette perspective nécessiterait-elle une quelconque autorisation ? oui ou
 non ?



Autorisation déjà acquise. Nous enrichissons ces batiments par des tags :
adresses, type de batiments, BBC ou non etc... type de toiture... donc
produit composite, donc sourcé DGFiP




 si oui merci de fournir une réponse claire et argumentée !


Fait. :)



 NB: La dernière question est volontairement caricaturale... c'est juste
 pour
 pour faire avancer la discussion initiale...
 --


La discution initiale n'a déjà pas lieu d'être... on en a déjà parlé avant,
ça a déjà été fait... on perd notre temps rien que d'ouvrir un 2e thread là
dessus.



-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Emilie Laffray]

2009/12/4 Steven Le Roux ste...@le-roux.info

 La discution initiale n'a déjà pas lieu d'être... on en a déjà parlé avant,
 ça a déjà été fait... on perd notre temps rien que d'ouvrir un 2e thread là
 dessus.

 +1

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pieren]

2009/12/4 Pierre Touzard pierretouz...@yahoo.fr:
 étape 2 : conversion en WGS84

Comme le dit Emilie, cette étape n'est simple que si la projection est
renseignée dans un fichier d'information (un fil récent sur géorezo
[1] semble montrer que cette information n'est pas toujours fiable).

 etape 3 : fusion des polygones contigües pour faire disparaitre les limites
 administratives pouvant exister entre des bâtiment.

Si tu prends uniquement la couche bâti du cadastre, il n'y pas les
limites parcellaires mais uniquement les limites physiques entre
bâtiments non ? Si c'est le cas, pourquoi fusionner et perdre
l'information ? Je comprends ceux qui le font lorsqu'ils tracent à la
main mais supprimer volontairement cette information très utile dans
un import de masse, c'est un crime. Encore une fois, j'attends une
réponse à la première question.

 étape 4: pour chaque polygone on supprime tous les attributs et on affecte
 un nouvelle attribut source =DGFiP

Quels sont les attributs supprimés ? pourquoi ne pas utiliser les
équivalents OSM ou même les recréer dans OSM ? Il n'y aucune raison
que l'attribution de la DGFiP change par rapport aux courriers
échangés pour l'accès au WMS. Il faudrait donc aussi ajouter le
millésime.

 ... Il me semble que nous venons de créer là un produit dérivé ? oui ou
 non ?

La condition pour utiliser les données cadastrales, c'est que ça forme
un produit composite, pas dérivé. Sinon j'ai déjà répondu à cette
question plus haut. Le fait que ce soit une petite quantité ou une
masse de données (voir le titre) n'entre pas en ligne de compte.

 étape 5: ouverture de la couche SIG dans QGIS et import dans OSM

Pas si simple. Comment se passe la fusion avec les données déjà
présentes qui sont parfois mieux fournies que le cadastre (POI,
adresses) ? De plus, QGIS n'est pas forcément le meilleur outil pour
faire l'import, surtout si ça concerne tous les bâtiments d'une
région. Il y a plusieurs scripts disponibles dans le dépôt svn
d'openstreetmap qui font ça très bien (capables de reprendre
automatiquement en cas de surcharge par exemple, merci Yann).

 Ce genre d'import serait-il bénéfique à OSM ? oui ou non ?

Oui, à condition d'en avoir le droit.

 Cette perspective nécessiterait-elle une quelconque autorisation ? oui ou
 non ?
 si oui merci de fournir une réponse claire et argumentée !

Déjà répondu par Denis, Émilie et Steven. Pour Brest, ils ont reçu
l'autorisation de la communauté urbaine de Brest. Si vous disposez de
ces données vectorielles pour d'autres régions, on veut juste savoir
si vous avez le droit d'en faire cet usage. Ca n'est pas à nous de
répondre. Sans une autorisation claire des propriétaires de la donnée
(la DGFiP ou la collectivité locale), inutile d'aller plus loin.

Pieren

[1] http://georezo.net/forum/viewtopic.php?id=63151

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[hamster]

Vincent de Chateau-Thierry a écrit :
 Pieren a écrit :
   
 2009/11/26 Pierre Touzard pierretouz...@yahoo.fr:
   
 
 2) Une question à poser : Est-il pertinent d'importer tous les bâtiments à
 l'identique du cadastre ? personnellement j'opterais plutôt pour une fusion
 des bâtiments contigus.
 
   
 Pourquoi se priver de cette information ? Personnellement, j'essaie
 autant que possible de faire un bâtiment par adresse.
 

ah bon ?
et comment tu fais pour savoir ou est la limite entre les 2 adresses ?
dans le cas d'un immeuble de centre ville ca demande de rentrer dedans 
pour aller voir ou se terminent les differents appartements, et c'est 
des fois pas pareil selon l'etage
il faut savoir de quelle information on parle : si c'est 2 constructions 
visiblement independantes mais qui se touchent alors oui pourquoi s'en 
priver, mais ca demande d'aller voir sur place
si c'est l'information qui est sur le cadastre il y a bien des cas ou le 
trace des parcelles ne corresponds a rien d'autre que le decoupage 
administratif de la propriete du terrain

  

 Si j'ai pu constater sur le terrain que la limite cadastrale divise en 
 fait une seule construction en plusieurs parcelles, alors je ne trace 
 qu'un bâtiment global, en rattachant les adresses à des noeuds en 
 façade. Si je n'ai pas pu vérifier, par défaut je divise le bâti en 
 fonction des limites de parcelles. Dans l'hypothèse d'un import auto, on 
 est selon moi dans cette 2e situation, où il faut préserver la division 
 par parcelles, quitte ensuite après visite sur place à fusionner les 
 polygones pour réunifier un bâtiment.


je suis plutot dans l'option on mappe le terrain, or il se trouve que 
les parcelles c'est pas du terrain mais du decoupage purement administratif
je pense qu'on commet bien plus d'erreurs en representant cette 
abstraction administrative que sont les parcelles qu'en dessinant la 
realite, a savoir dessiner en un seul morceau ce qui est construit en un 
seul morceau

de plus si un jour des gens veulent rajouter des tags pour la couleur du 
toit ou autre il y a la fonction scinder le way qui marche pour les 
polygones en selectionnant 2 points, c'est pas plus complique que de 
fusionner les traces de parcelles

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pieren]

2009/11/30 hamster hams...@suna.fdn.fr:
 ah bon ?
 et comment tu fais pour savoir ou est la limite entre les 2 adresses ?

Pour l'instant, je n'ai fait que tracer des bâtiments à partir de
plans au format image qui ont une meilleure distinction entre
bâtiments comme cela a déjà été relevé par Denis.

 je suis plutot dans l'option on mappe le terrain, or il se trouve que
 les parcelles c'est pas du terrain mais du decoupage purement administratif
 je pense qu'on commet bien plus d'erreurs en representant cette
 abstraction administrative que sont les parcelles qu'en dessinant la
 realite, a savoir dessiner en un seul morceau ce qui est construit en un
 seul morceau

Il faut distinguer les immeubles en un morceau à plusieurs adresses
(et là, les parcelles ne veulent pas dire grand chose) des séries de
bâtiments distincts mais accolés et là, la limite de parcelle veut
dire quelque chose parce qu'elle indique aussi la limite de propriété,
donc du bâtiment. Bien sûr, l'idéal est d'aller sur place mais comme
je l'ai déjà dis avec d'autres, on peut aussi utiliser les images
satellites SANS LES RECOPIER mais en constatant les faits qui y
figurent pour constater les limites de bâti vu du ciel.

 de plus si un jour des gens veulent rajouter des tags pour la couleur du
 toit ou autre il y a la fonction scinder le way qui marche pour les
 polygones en selectionnant 2 points, c'est pas plus complique que de
 fusionner les traces de parcelles

Je signale juste que la question au départ concerne un import de
données cadastrales qui donnent donc sans effort les bâtiments
séparément. Encore une fois, pourtant fusionner ces polygones au
départ si c'est pour les redécouper plus tard ?

Pieren

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[hamster]

Pieren a écrit :
 Je signale juste que la question au départ concerne un import de
 données cadastrales qui donnent donc sans effort les bâtiments
 séparément.

non : ca donne sans effort les parcelles separement, ou alors on parle 
pas de la meme chose
je ne comprends pas comment tu fais la difference entre 2 batiments qui 
ont un mur entier en commun a partir du cadastre, surtout par un procede 
automatique
on est bien d'accord que si c'est 2 batiments qui se touchent juste par 
un coin la question ne se pose pas

  Encore une fois, pourtant fusionner ces polygones au
 départ si c'est pour les redécouper plus tard ?

parce que je prefere rajouter des infos vraies plus tard plutot 
qu'importer des infos fausses maintenant
mais je peux aussi le dire dans l'autre sens : a quoi ca sert de 
rajouter inutilement plein de limites purement administratives si c'est 
pour passer du temps a les fusionner plus tard ?

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pieren]

2009/11/30 hamster hams...@suna.fdn.fr:
 non : ca donne sans effort les parcelles separement, ou alors on parle
 pas de la meme chose

Non, on ne parle pas de la même chose. Le cadastre contient une couche
bâti séparée de la donnée parcellaire.

Pieren

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[hamster]

Pieren a écrit :
 2009/11/30 hamster hams...@suna.fdn.fr:
   
 non : ca donne sans effort les parcelles separement, ou alors on parle
 pas de la meme chose
 

 Non, on ne parle pas de la même chose. Le cadastre contient une couche
 bâti séparée de la donnée parcellaire.

tiens, j'ai du louper quelque chose dans ton magnifique plugin cadastre 
: comment fait-on pour faire afficher cette couche bati pour commencer 
a la mapper a la main en attendant l'import automatique ?

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pieren]

2009/12/1 hamster hams...@suna.fdn.fr:
 tiens, j'ai du louper quelque chose dans ton magnifique plugin cadastre
 : comment fait-on pour faire afficher cette couche bati pour commencer
 a la mapper a la main en attendant l'import automatique ?


Le serveur WMS du site cadastre.gouv.fr ne délivre que des images au
format png. La question de départ de ce fil concernait l'import
automatique à partir de données vectorielles que le public peut
acheter sur le site du cadastre mais que certains professionnels et
surtout les collectivités locales possèdent en brut. Donc ceux qui
possèdent ces données vectorielles  peuvent facilement en extraire la
partie bâti au format vectoriel pour un import automatique (à
condition qu'ils en aient le droit).
Pour le bas peuple comme nous qui n'avons accès qu'au WMS, il faudrait
passer par une reconnaissance de forme basé sur contraste des couleurs
pour ces images en données vectorielles. Il y a eu plusieurs
tentatives dans cette direction (qu'on peut retrouver dans les
archives) mais aucun n'atteint un résultat satisfaisant. Ce qui est
tolérable pour reconnaitre les limites administratives par exemple
l'est beaucoup moins avec des bâtiments qui ont une géométrie simple.
Mais si ça peut aider, je pourrais facilement ajouter une option au
plugin pour qu'il n'affiche que la couche bâti au format image (ou
l'une des 5 ou 6 autres couches). C'est vrai qu'avec cette seule
couche, on pourra peut-être plus facilement distinguer les séparations
entre bâtiments (qui sinon disparaissent derrière les traits du
parcellaire).

Pieren

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Ab_fab]

Bonjour,

Actuellement la seule information que l'on renseigne (en règle générale) est
l'emprise au sol du bâti.
Il y a une proposition pour étendre la description à d'autres éléments tels
que
le nombre d'étages, la forme et le matériau du toit, le matériau de
construction.
http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes (*)

Dans les quartiers des centres urbains, il y a beaucoup de bâtiments et bien
souvent ils sont de même hauteur et de construction similaire (merci
Hausmann) .
Mais ce n'est pas toujours le cas, loin de là.

En fusionnant les parcelles des bâtiments, on se prive de la possibilité de
rentrer avec précision ces infos ultérieurement.
Après vérification de terrain, certaines parcelles mériteront effectivement
d'être fusionnées si le bâtiment qui les compose est uniforme, mais je ne
suis pas pour cette opération de fusion durant un import massif
(*) Je trouve ce genre d'attributs vachement utiles et motivants pour aller
vérifier de visu que le cadastre dit vrai tout en précisant ses
informations.

Si l'import permet de prendre l'air plutôt que se ruiner les yeux à dessiner
des contours à l'écran, +100 pour moi :-)


Le 27 novembre 2009 00:21, Vincent de Chateau-Thierry v...@laposte.net a
écrit :


 Pieren a écrit :
  2009/11/26 Pierre Touzard pierretouz...@yahoo.fr:
 
  2) Une question à poser : Est-il pertinent d'importer tous les bâtiments
 à
  l'identique du cadastre ? personnellement j'opterais plutôt pour une
 fusion
  des bâtiments contigus.
 
 
  Pourquoi se priver de cette information ? Personnellement, j'essaie
  autant que possible de faire un bâtiment par adresse.
 
  Pieren.
 
 Si j'ai pu constater sur le terrain que la limite cadastrale divise en
 fait une seule construction en plusieurs parcelles, alors je ne trace
 qu'un bâtiment global, en rattachant les adresses à des noeuds en
 façade. Si je n'ai pas pu vérifier, par défaut je divise le bâti en
 fonction des limites de parcelles. Dans l'hypothèse d'un import auto, on
 est selon moi dans cette 2e situation, où il faut préserver la division
 par parcelles, quitte ensuite après visite sur place à fusionner les
 polygones pour réunifier un bâtiment.

 ...et bonne nuit,
 vincent

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


-- 

ab_fab

Il n'y a pas de pas perdus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[HELFER Denis]

-Message d'origine-
De : talk-fr-boun...@openstreetmap.org 
[mailto:talk-fr-boun...@openstreetmap.org]de la part de Ab_fab
Envoyé : vendredi 27 novembre 2009 09:40
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Import massif bâtiments cadastre


Bonjour,

Actuellement la seule information que l'on renseigne (en règle générale) est 
l'emprise au sol du bâti.
Il y a une proposition pour étendre la description à d'autres éléments tels que
le nombre d'étages, la forme et le matériau du toit, le matériau de 
construction.
http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes (*)

Dans les quartiers des centres urbains, il y a beaucoup de bâtiments et bien 
souvent ils sont de même hauteur et de construction similaire (merci Hausmann) .
Mais ce n'est pas toujours le cas, loin de là.

Et les services régionaux d'inventaire du patrimoine ont une connaissance (et 
des mégatonnes de dossiers très détaillés) que peu de gens soupçonnent. Leur 
contribution sur ce thème serait d'un apport inestimable. La semaine dernière, 
j'ai fait une présentation d'OSM à mes collègues du service Inventaire et 
Patrimoine qui ont manifesté un intérêt certain pour notre projet. Il y a des 
pistes de travail à creuser encore.

Denis

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Robin PREST]

 *Il y a une proposition pour étendre la description à d'autres éléments
 tels que le nombre d'étages, la forme et le matériau du toit, le matériau de
 construction.*


Si cette donnée existe, vous aller voir le spectre d'OSM 3D venir hanter
cette liste. Pas tant que ça, car le projet existe déjà :D
http://wiki.openstreetmap.org/wiki/OSM-3D
Ca laisse rêveur les possibilités quand même...
[image: 800px-Fehler_Multipolygone.JPG]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Steven Le Roux]

Salut,

C'est ce qui a été fait ici :

http://www.openstreetmap.org/?lat=48.3941lon=-4.4878zoom=14layers=B000FTF



2009/11/26 Pierre Touzard pierretouz...@yahoo.fr


 Bonsoir à tous,

 Voici une question qui me viens à l'esprit:

 La nouvelle version de QGIS (logiciel SIG) intègre désormais un module
 permettant d'éditer les données OSM.
 Ce module permet aussi un import facilité de couche de données issue du
 monde SIG (format shp).

 Il se trouve que je travaille dans une société qui manipule énormément les
 données cadastral vecteur (celles que l'on voit sur cadastres.gouv.fr mais
 en vecteur !).

 Bref les obstacles techniques sont en train de tomber...

 J'aimerais extraire la couche bâtiments du cadastre et l'importer sur
 OSM

 Est-ce compatible avec la philosophie OSM ? En fait cela permettrait de
 gagner du temps pour couvrir des villes à la manière de Grenoble... en
 atténuant très significativement les temps de digitalisation(plugin
 cadastre-fr de JOSM).

 Il faut un travail composite allez-vous me dire...

 Justement: le fait importer massivement tous les bâtiments du cadastre
 (que la couche bâtiments) pour ensuite les taguer comme il faut constitue
 t-il un travail composite ?
 --
 View this message in context:
 http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4072541.html
 Sent from the French OSM list mailing list archive at Nabble.com.

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




-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB ste...@le-roux.info
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Jeremy G]

Salut,

Le procédé m'intéresse aussi (j'utilise QGIS et travaille avec des données
cadastrales). Donc +1 à la question éthique, et plus précisément :
- Est-ce que Brest a été fait après accord du cadastre ou simplement comme
ça ?
- Peut-on se servir de données shape ne provenant pas du WMS ?

Selon la DGFiP :
S'agissant des conditions d'utilisation, il est rappelé que l'ensemble des
utilisateurs sont habilités à faire un usage libre du plan cadastral pour la
réalisation de leurs travaux internes. En revanche, la rediffusion de ces
données n'est autorisée que pour les produits composites, c'est à dire ceux
constitués pour partie seulement du plan cadastral, et sous réserve que
soient clairement indiqués l'origine et le millésime des données cadastrales
utilisées (par exemple source : Direction générales des finances publiques
- année 2008). (1)

Il semble qu'on soit bien dans la notion de produit composite, puisqu'OSM
est un produit composite par définition ?

Merci pour les éclaircissements,

Jérémy

(1)
http://wiki.openstreetmap.org/wiki/Cadastre_Français/Legal#La_réponse_de_la_DGIhttp://wiki.openstreetmap.org/wiki/Cadastre_Fran%C3%A7ais/Legal#La_r%C3%A9ponse_de_la_DGI


Le 26 novembre 2009 19:48, Steven Le Roux ste...@le-roux.info a écrit :

 Salut,

 C'est ce qui a été fait ici :


 http://www.openstreetmap.org/?lat=48.3941lon=-4.4878zoom=14layers=B000FTF



 2009/11/26 Pierre Touzard pierretouz...@yahoo.fr


 Bonsoir à tous,

 Voici une question qui me viens à l'esprit:

 La nouvelle version de QGIS (logiciel SIG) intègre désormais un module
 permettant d'éditer les données OSM.
 Ce module permet aussi un import facilité de couche de données issue du
 monde SIG (format shp).

 Il se trouve que je travaille dans une société qui manipule énormément les
 données cadastral vecteur (celles que l'on voit sur cadastres.gouv.frmais
 en vecteur !).

 Bref les obstacles techniques sont en train de tomber...

 J'aimerais extraire la couche bâtiments du cadastre et l'importer sur
 OSM

 Est-ce compatible avec la philosophie OSM ? En fait cela permettrait de
 gagner du temps pour couvrir des villes à la manière de Grenoble... en
 atténuant très significativement les temps de digitalisation(plugin
 cadastre-fr de JOSM).

 Il faut un travail composite allez-vous me dire...

 Justement: le fait importer massivement tous les bâtiments du cadastre
 (que la couche bâtiments) pour ensuite les taguer comme il faut constitue
 t-il un travail composite ?
 --
 View this message in context:
 http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4072541.html
 Sent from the French OSM list mailing list archive at Nabble.com.

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




 --
 Steven Le Roux
 Jabber-ID : ste...@jabber.fr
 0x39494CCB ste...@le-roux.info
 2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB

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


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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Denis]

Jeremy G a écrit :
 Salut,
 
 Le procédé m'intéresse aussi (j'utilise QGIS et travaille avec des données
 cadastrales). Donc +1 à la question éthique, et plus précisément :
 - Est-ce que Brest a été fait après accord du cadastre ou simplement comme
 ça ?

Il ne faut pas mélanger l'aspect technique (est-ce que QGis est une 
bonne solution technique pour importer des données cadastrales dans OSM 
(au moins la couche bâti, par rapport à d'autres outils -je pose juste 
la question ; je n'ai pas de réponse, mais je suis très intéressé par 
tout retour d'expérience-) et l'aspect légal.

 - Peut-on se servir de données shape ne provenant pas du WMS ?

Cela rejoint le débat sur la commune (et sa comcom) de Saint Médard sur 
Ille et de son import des données cadastrales numérisées sous convention 
avec la DGFip. Il faut juste avoir le détail de la convention pour aller 
plus loin dans la réflexion. Je crois savoir que les conventions les 
plus récentes autorisent les communes et leurs regroupement à faire une 
diffusion libre du produit (PCI vecteur labellisé) co-produit. Il reste 
que c'est une décision de la collectivité, étant entendu que les 
informations cadastrales sont publiques (décret de 2005, jurisprudence 
CADA et rappelé dans l'accord historique de la DGFiP), de placer son 
investissement financier (rien n'est gratuit) sous une licence 
compatible avec celle d'OSM. C'est le pas majeur (et l'exemple à suivre) 
qu'a franchi la Communauté Urbaine de Brest avec son orthophotoplan et 
ses données vecteur à très grande échelle (très précis ;-).

 
 Selon la DGFiP :
 S'agissant des conditions d'utilisation, il est rappelé que l'ensemble des
 utilisateurs sont habilités à faire un usage libre du plan cadastral pour la
 réalisation de leurs travaux internes. En revanche, la rediffusion de ces
 données n'est autorisée que pour les produits composites, c'est à dire ceux
 constitués pour partie seulement du plan cadastral, et sous réserve que
 soient clairement indiqués l'origine et le millésime des données cadastrales
 utilisées (par exemple source : Direction générales des finances publiques
 - année 2008). (1)

Ces conditions sont celles du site diffusant une information 
cartographique (Le Plan Cadastral Informatisé, toujours raster quand il 
arrive dans JOSM). Elles s'appliquent aussi aux bases de données 
labellisées dans le sens où les mêmes informations (seul auteur autorisé 
: le Ministère des Finances) sont soumises aux mêmes conditions.
Donc :
- les informations cadastrales sont librement réutilisables (y compris 
pour OSM) à condition que cette réutilisation ne soit pas une bête copie 
(+attribution d'auteur)
- des données vectorielles ne sont qu'une des formes de cette 
information (penser qu'il faut faire l'appariement entre les deux mondes 
sémantiques très différents)
- non pour importer TOUT le cadastre brute force dans OSM.
- oui pour importer et adapter certaines couches vectorielles (après que 
leurs financeurs aient placé ces données sous licence compatible)

A ceux qui rêveraient d'un partenariat direct en OSM et le Ministère des 
Finances, je répondrais qu'il est prématuré d'envisager une telle 
collaboration à ce niveau (ce n'est pas à exclure non plus). Dans le 
même temps, la coopération avec les collectivités locales qui ont 
digitalisé le Plan Cadastral est d'une actualité brûlante (mais je crois 
que je l'ai déjà dit ,-)

Reste le cas des collectivités qui ont digitalisé un plan cadastral sans 
partenariat avec la DGFiP. Elles sont seules auteur de leurs données 
(pas des informations) et ont toute liberté de diffusion. La différence 
entre un PCI labellisé et non labellisé est mineure pour OSM (mais non 
nulle). Il est trop tôt pour rentrer dans les détails ici.

Denis

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pieren]

2009/11/26 Pierre Touzard pierretouz...@yahoo.fr:
 Justement: le fait importer massivement tous les bâtiments du cadastre
 (que la couche bâtiments) pour ensuite les taguer comme il faut constitue
 t-il un travail composite ?

Question plusieurs fois débattues sur cette liste, voir les archives.
Est-ce que le cadastre fournit le tracé complet des rues ? non, il n'y
a que des vecteurs pour afficher les noms. Est-ce que le cadastre
fournit une classification des routes ? Non, il n'y a pas de primary,
secondary, tertiary, track, service, path. Est-ce que le cadastre
donne les sens interdits, les feux de circulation, les restaurants,
les bureaux de poste, les rues piétonnes, les limitations de vitesse,
etc...  Et après, il y a encore des gens pour demander si OSM est un
produit composite... Le problème de l'import, c'est où fixer la limite
sur ce qui peut être importé ou pas. A plusieurs reprises lors de nos
discussions, un consensus se dégageait pour ne pas importer les
parcelles, la partie la plus importante du cadastre pour la DGI, mais
qui n'est pas une information si vitale pour OSM et qui en plus serait
très difficile à maintenir.

Ca n'est pas un problème technique (voir BMO ([1])) mais une question de droit.

2009/11/26 Denis dhel...@free.fr:
Donc toute personne qui aurait accès aux données vectorielles du
cadastre par le biais de son entreprise pourrait redistribuer ces
données gratuitement, alors que la DGI fait payer au prix fort le
moindre CD ? Ou alors, est-ce au cas par cas, suivant les
conventionnements avec les collectivités locales qui devront donner
leur avis ?

Pieren
[1[] http://wiki.openstreetmap.org/wiki/BMO

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Denis]

Pieren a écrit :

 2009/11/26 Denis dhel...@free.fr:
 Donc toute personne qui aurait accès aux données vectorielles du
 cadastre par le biais de son entreprise pourrait redistribuer ces
 données gratuitement, alors que la DGI fait payer au prix fort le
 moindre CD ? Ou alors, est-ce au cas par cas, suivant les
 conventionnements avec les collectivités locales qui devront donner
 leur avis ?

J'ai accès à des Go de données publiques dans le cadre des missions de 
service public de mon employeur. Puis-je en faire ce que je veux ? Non !
J'ai même eu le cas récent, pour des données cadastrales, où d'un côté 
de ma petite région, les données sont demandées et obtenues (en EDIGEO 
;-) rapidement (et gratuitement) auprès du CDIF local et de l'autre 
côté, une fin de non recevoir pour des d'autres missions tout aussi 
publiques que les premières. L'administration n'est pas toujours simple 
(à comprendre).
Je suis le premier à dire, nul mystère, que les données publiques 
prendront toute leur valeur quand elles seront massivement utilisables 
(et cela passera par une libéralisation de leur licence d'utilisation). 
Nous sommes convaincus que nous devons demander des comptes à nos 
administrations sur la réutilisation de notre investissement (via nos 
contributions à leur fonctionnement). Evidemment, c'est toujours plus 
complexe qu'il n'y paraît au premier abord.

Je n'ai pas le pouvoir, comme licencié d'une donnée, de modifier la 
licence initiale (même si celle-ci est souvent passée au second plan 
quand qu'on reste dans le cercle confiné des entités habilitées à 
manipuler ces informations).

Si OSM -nous, citoyens- n'arrive pas à interpeller ceux (à commencer par 
nos plus proches) qui prennent des décisions à notre place (en notre 
nom), nous finirons par n'être qu'une entreprise de dessin et de 
coloriage, parmi d'autres.

Si je suis convié à un goûter et que mon hôte me présente un gâteau qui 
me fait saliver, je ne vais pas pour autant me jeter dessus comme un 
malpropre sans y avoir été invité au préalable. Nous sommes des fourmis, 
mais nous ne sommes pas des bêtes, non ?

Denis

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[Pierre Touzard]

J'adhère entièrement à la vision de Denis.
Le contexte montre que nous sommes loin d'être les seuls à partager ces
opinions...

Si OSM -nous, citoyens- n'arrive pas à interpeller ceux (à commencer par 
nos plus proches) qui prennent des décisions à notre place (en notre 
nom), nous finirons par n'être qu'une entreprise de dessin et de 
coloriage, parmi d'autres.

C'est malheureux mais crevant de vérité !

...

Pour recentrer le débat :

1) Importer massivement les bâtiments d'une commune disponible en vecteur
est techniquement faisable, moyennant un accès en bonne et due forme à la
donnée ie si cela est acceptable au vue des convention de numérisation
(format EDIGEO).

2) Une question à poser : Est-il pertinent d'importer tous les bâtiments à
l'identique du cadastre ? personnellement j'opterais plutôt pour une fusion
des bâtiments contigus.




Denis-3 wrote:
 
 J'ai accès à des Go de données publiques dans le cadre des missions de 
 service public de mon employeur. Puis-je en faire ce que je veux ? Non !
 J'ai même eu le cas récent, pour des données cadastrales, où d'un côté 
 de ma petite région, les données sont demandées et obtenues (en EDIGEO 
 ;-) rapidement (et gratuitement) auprès du CDIF local et de l'autre 
 côté, une fin de non recevoir pour des d'autres missions tout aussi 
 publiques que les premières. L'administration n'est pas toujours simple 
 (à comprendre).
 Je suis le premier à dire, nul mystère, que les données publiques 
 prendront toute leur valeur quand elles seront massivement utilisables 
 (et cela passera par une libéralisation de leur licence d'utilisation). 
 Nous sommes convaincus que nous devons demander des comptes à nos 
 administrations sur la réutilisation de notre investissement (via nos 
 contributions à leur fonctionnement). Evidemment, c'est toujours plus 
 complexe qu'il n'y paraît au premier abord.
 
 Je n'ai pas le pouvoir, comme licencié d'une donnée, de modifier la 
 licence initiale (même si celle-ci est souvent passée au second plan 
 quand qu'on reste dans le cercle confiné des entités habilitées à 
 manipuler ces informations).
 
 Si OSM -nous, citoyens- n'arrive pas à interpeller ceux (à commencer par 
 nos plus proches) qui prennent des décisions à notre place (en notre 
 nom), nous finirons par n'être qu'une entreprise de dessin et de 
 coloriage, parmi d'autres.
 
 Si je suis convié à un goûter et que mon hôte me présente un gâteau qui 
 me fait saliver, je ne vais pas pour autant me jeter dessus comme un 
 malpropre sans y avoir été invité au préalable. Nous sommes des fourmis, 
 mais nous ne sommes pas des bêtes, non ?
 
 Denis
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 

-- 
View this message in context: 
http://n2.nabble.com/Import-massif-batiments-cadastre-tp4072541p4073379.html
Sent from the French OSM list mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Import massif bâtiments cadastre

[g.d]

Wow,
suis heureux de ne pas être seul dans la jungle !

trop long
---

Le 26 nov. 09 à 23:20, Pierre Touzard a écrit :

 J'adhère entièrement à la vision de Denis.
 Le contexte montre que nous sommes loin d'être les seuls à partager  
 ces
 opinions...

 Si OSM -nous, citoyens- n'arrive pas à interpeller ceux (à  
 commencer par
 nos plus proches) qui prennent des décisions à notre place (en notre
 nom), nous finirons par n'être qu'une entreprise de dessin et de
 coloriage, parmi d'autres.

 C'est malheureux mais crevant de vérité !


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

Re: [OSM-talk-fr] import massif planté avec bulk_u pload.py

[wouldsmina]

tu peux supprimer tout mes changement du 10 mais stp?
merci,

Le 11 mai 2009 00:11, Pierre Mauduit pierre.maud...@gmail.com a écrit :

 Le dimanche 10 mai 2009 à 19:02 +0200, wouldsmina a écrit :
  bonjour à tous,
 
  j'ai essayé d'importer les limites administratives du jura mais le
  script en python
 
 http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload.pya
  planté

 Suite au lancement du script de revert, je me suis aperçu que le gros
 paté avait disparu sur le serveur de Sylvain, j'ai donc arrété le
 massacre après le revert du changeset #1141098 ne souhaitant pas être
 responsable de suppressions de données valides ; s'il y a besoin tout de
 même de faire le revert sur les autres, faites-moi signe.

 Bonne nuit,

 --
 Pierre


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

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

Re: [OSM-talk-fr] import massif planté avec bulk_u pload.py

[Pieren]

2009/5/10 wouldsmina wouldsm...@gmail.com:

Ce qui est curieux, c'est le résultat de ce qui est déjà dans la base.
C'est comme si les nodes étaient mélangés dans les ways de plusieurs
communes.
Il faudrait tester le script bulk sur une seule commune et une relation.
Mais avant de recommencer quoique ce soit, il faut attendre que les
données déjà transmises soient nettoyées. Il se fait tard et ça sera
probablement pour demain (sauf s'il y a des noctambules pour s'en
charger).

Pieren

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

Re: [OSM-talk-fr] import massif planté avec bulk_u pload.py

[Pierre Mauduit]

Re,

 Mais avant de recommencer quoique ce soit, il faut attendre que les
 données déjà transmises soient nettoyées. Il se fait tard et ça sera
 probablement pour demain (sauf s'il y a des noctambules pour s'en
 charger).


J'ai lancé le script sur les changesets problématiques. Mais je vais
sans doute laisser tourner le PC et m'assurer que tout s'est bien passé
demain.

Bonne nuit,

-- 
Pierre



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

Re: [OSM-talk-fr] import massif planté avec bulk_u pload.py

[Pierre Mauduit]

Le dimanche 10 mai 2009 à 19:02 +0200, wouldsmina a écrit :
 bonjour à tous,
 
 j'ai essayé d'importer les limites administratives du jura mais le
 script en python
 http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload.py
  a planté

Suite au lancement du script de revert, je me suis aperçu que le gros
paté avait disparu sur le serveur de Sylvain, j'ai donc arrété le
massacre après le revert du changeset #1141098 ne souhaitant pas être
responsable de suppressions de données valides ; s'il y a besoin tout de
même de faire le revert sur les autres, faites-moi signe.

Bonne nuit,

-- 
Pierre


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